ARINC 661 - An Introduction / Tutorial

The Who, What, Why and How of ARINC 661!

ARINC 661 arose from a need in the avionics industry.  Aircraft have become increasingly complex, with multiple systems from multiple suppliers all requiring a man-machine-interface with the pilot and crew.  Rather than fitting in more and more dedicated screens, knobs and buttons, multi-purpose display systems were produced, so many systems could be controlled by via one physical box.  

Historically each system had a separate interface with the display system, conforming to its own protocol or bus-messaging.  Unfortunately with this approach the display system becomes a “bottleneck” system that needs to be changed and recertified every time an aircraft system is upgraded.  

The ARINC 661 standard addresses a necessity to allow multiple systems to interact with a display system, in a safety critical environment in such a way that changes to systems do not require a recertification of the display system.

Commercial airframe manufacturers (Airbus and Boeing) led the way to produce an open industry wide ARINC standard, through support for an industry-wide, expert-led committee.  The aim was to produce a standard to be used by all system developers contributing to major new airframe projects.

The core concept within the standard is that the components that make up a user interface can be defined during system design and “loaded” into a cockpit display system to be present at runtime (the uploading of Definition Files).   Furthermore the standard states that the design can be fragmented into parts, e.g. a part per system that requires a Man-Machine-Interface.

Some Terms

CDS – Cockpit Display System the hardware that drives the “glass” in the cockpit and software that loads definition files and interacts with other systems using ARINC 661 Messages.

UA – User Application, ARINC 661 term for all other systems, conceptually considered to be “users” of a display “server”.

System Architecture

ARINC 661 defines an unambiguous standard for two aspects of a CDS:

  1. DF file – how to define layers, widgets and their design time and run time modifiable properties, such that the CDS can load the definition and take it as the user interface to be driven at run-time
  2. ARINC 661 Messaging Protocol – the message structures (bytes, byte order, data types and meaning) needed to instruct the user interface.

It should be noted that the protocol is just that, it defines what the message structure is, but it does not prescribe a means of transport (how the bytes get there and are known to have arrived).  So the physical connection could be copper or fibre running any safety critical real-time communications layer that supports the required bandwidth, e.g. AFDX or ARINC 629.

Figure 1- Overview of ARINC 661 CDS / UA Architecture


A typical deployment will in reality be made up from multiple user applications and possibly multiple CDSs.  There are no restrictions on the topology; a UA may connect to multiple CDSs, a CDS may server multiple UAs.

One Protocol to Rule Them All

The aim of ARINC 661 is to minimise the impact on the user interface redevelopment and certification cost in response to inevitable system changes and deployment variations.  In order to achieve this all systems (UAs) need to “speak” ARINC 661 when interacting with the CDS.  How UAs communicate amongst themselves is not affected.

This is a stringent requirement that necessitates that the ARINC 661 protocol is capable of supporting all of the user interface requirements of existing systems and systems developed in the future.  Major airframe manufacturers, User Application suppliers, CDS developers and ARINC 661 Tool Vendors all work together within the ARINC 661 committee to ensure industry needs are continuously met.  

The standard should be considered as extremely stable.  That core of the standard is widely adopted and unchanged (except for clarification purposes) over the last few years.

The Basic Anatomy of an ARINC 661 Display

ARINC 661 states the CDS has three parts to its configuration that combine to build any display requirements that may be required:

  • Window Configuration – how the display(s) are partitioned into rectangular physical areas
  • Widget Library – defines the types of things that can be displayed and how they work
  • Definition Files – defines what is actually displayed

Window Configuration

Each display unit managed by the CDS is partitioned into fixed sized rectangular “windows” that cannot overlap.  Each window defines a physical part of the display surface.  Windows visibility is managed by the CDS.  Windows may display multiple layers, these layers may be connected to different UAs, and hence it is possible for multiple systems to display their data together in the same physical screen space.

Widget Library

The widget library is loaded into the CDS (and is not part of the core CDS software/kernel).  It defines the implementations of a set of widget-types (screen components).  The ARINC 661 document defines a standard set of widget types that are designed to meet most display requirements.  It is possible for a particular deployment to extend the widget types defined (known as adding extended widgets).

Widget Definition Set Part


Widget Type

A widget description, defined in terms of its design time and run time properties and any events it may raise.  Example of a widget type is a “check button”. 

Widget Library

Collection of widget-type implementations, loaded by the CDS.

The ARINC 661 standard defines nearly 80 different types of widget, some of which can be instantly recognised as common user interface features (e.g. button, combo-box, and check-button) others are specific to the specialist requirements for managing navigation and tactical maps.

Not all widgets have a visual representation, some just have functionality that affects the display in other ways.  E.g. by defining how descendant widgets are laid out.

The ARINC 661 standard collects widget-types into categories, this grouping helps identify a widget’s primary purpose, some widget types belong to multiple categories.

Widget Type Category



Used to design the hierarchical nature of widgets, containers contain child widgets.  Examples include: BasicContainer, Panel

Dynamic motion

Widgets whose location or size can change at run-time.   Examples include container widgets (Basic Container) and Graphical Representation widgets (GPLine)

Graphical Representation

Widgets that have a graphical representation i.e. result in pixels being rendered on the display. E.g. Graphical primitives such as line, rectangle (known as GPLine and GPRectangle) and some containers e.g. Panel and others.


Accept interaction from crew members, and trigger an event (message) from the CDS to the UA.  E.g. CheckButton

Map Management

For controlling dynamic widgets within maps, e.g. Map_Horz which renders information supplied in a geographical coordinate system.

Text String

Widgets that display text.  E.g. Label

UA Validation

Widgets that raise events and may provide feedback whilst the UA validates the input.  E.g. ComboBox


Special widgets with no graphical representation, which extend functionality or provide a means to solve common technical difficulties.  Examples are FocusIn, FocusOut widgets that add automatic focus change behaviour.   Also the Connector widget that enables a layer to contain child layers from other UAs.

Definition Files – The Display Definition

A definition file describes how many instances of each widget type are created, along with their hierarchy and design time property values (e.g. position, colour, enablement, etc).

DF File Part


Definition File

A binary file in the ARINC 661 format that holds information about the user interface structure that is to be supported by the CDS.  A CDS can load multiple definitions files.


A canvas that can be turned on or off for display.  A screen can show multiple layers at once in different regions.  Layers may overlap one another.  A definition file is likely to contain multiple layer definitions.  Layers are connected to User Applications.

Hierarchy of Widget Instances

A layer may contain multiple widgets.  Some widgets are containers and can contain child widgets.  A widget hierarchy is a commonly used UI definition technique, where by layout is managed and properties such as Visibility and Enablement cascade down through the widget tree to descendant widgets.

What Does All This Physically Mean?

The figure below shows graphically an ARINC 661 display solution once the different configurations are defined and loaded.

Figure 2- Strict rules determine how screen area is controlled - simple concept that provides clear boundaries for certification purposes.

Closer Look at a Widget-Type definition

Each widget type in the standard ARINC 661 widget set is described using a consistent series of documentation sections.  This makes the document easier to read and widget definitions easier to compare and contrast.


Widget Definition Documentation Section



Lists which widget categories the widget type belongs to. So readers can Instantly determine if the widget has a graphical representation or not (for instance).


Brief description defining the purpose of the widget.


Provides additional information about its intended use, including when this widget type should be selected instead of a similar widget type and hints as to how a UA may typically interact with it.


Typically used to define limitations on parent/child widget types. 


Defines the properties of the widget type and a short description for each property’s purpose.  Each property is labelled as one of the following:
D – Can only be set at Design Time (e.g. the instance identifier)
DR – Can be set at design time (initial value) and overridden at run time (e.g. Visible parameters)
R – Occasionally some parameters are only runtime modifiable, with no initial value defined at design time.

Creation Structure

Defines the parameter order, data type, size in bytes and any limitations on data values (e.g. enumerate choices).  Defines how the widget instances of this type will be defined within the uploaded definition file.

Event Structures

Defines the structure of any ARINC 661 events raised by the widget type (interactive widgets only).

Runtime Modifiable Parameters

For each parameter that is run-time modifiable, the identifier (constant) to be used in ARINC 661 set parameter messages is defined.

“Look” is separated from “Function”

ARINC 661 specifies how widgets behave and whether or not they have a graphical representation, ARINC 661 explicitly avoids making any form of recommendation on how each widget type should look when rendered on the display.

This can make the standard appear a little confusing as it is useful to describe widgets in terms of their physical appearance. ARINC 661 does provide some design-time and run-time modifiable parameters to affect a widget’s appearance.  E.g. size, colour, and style-set.  Each widget type’s physical appearance is loaded along with its implementation and so it will be consistent everywhere it is displayed by the CDS, for all user applications across all layers.

The style set property is a special property applied to widgets with a graphical representation.  It is a numeric property that by index and lookup table or by bit-field enables a CDS to define alternate appearances for a widget type for alternate scenarios.  For example all “Confirm” buttons may need a different appearance from all “Cancel” buttons.  The button widget type can be used for both cases with different style-set values.

What Does ARINC 661 Mean for Certification?

It is not surprising that as ARINC 661 was borne from a need to manage costs, it has a positive impact on system accreditation to DO178-C or equivalent.  A certified CDS can handle any valid definition file, so as user interface requirements change no recertification of the CDS is required.  Widgets are a defined managed set with their appearance separated from their logic, so again tweaks to appearance should mean minimal recertification, with the knowledge that changes to a widget type will affect all instances of that type.

Widget libraries can be re-used across multiple projects, improving user-interface consistency across a suite of systems whilst eliminating re-certification for these components.

Additional benefits arise because definition files and their layers within can be re-used on other programmes.  Also UAs are tied to layers within specific display windows, this means that the display solution can support different classes of certification for different functional areas, minimising the pull-up affect where a system is over-certified because it shares processing with other systems at display time.

Does ARINC 661 have Limitations?

As with all solutions there are limitations, ARINC 661 displays are constrained by the three system elements:

  1. Limitations of the CDS – e.g. a CDS will be able to manage a certain number of layers, widgets, etc.  The CDS will also have limitation in terms of how much screen real-estate can be updated at a defined rate.

  2. Bandwidth of communications.  The ARINC 661 protocol requires significantly more bytes to be shared with the CDS than a non ARINC 661 solution.

  3. Limitations of the UA – a user application needs to do significantly more work in order to interact correctly with the user interface when compared with historical non ARINC 661 solutions.  When porting existing systems using pre-certified hardware it is essential that this additional loading is taken into account.

  4. Combined limitation effect is also observable.  The lag between user interaction and user observing a response is dependent upon the performance of all three elements (above) combined.

A CDS supplier will declare their limitations, market forces ensure that a CDS is capable of supporting what is required of it.

Bandwidth also need not be a problem as long as it is considered early on in the solution architecture design.

What Common Difficulties are Associated with ARINC 661?

Common Difficulties with ARINC 661 include:

Steep learning curve – CDS layer design and UA developers both need to understand a fair amount about ARINC 661 and the standard set of widgets to develop optimised displays.

Code-Bloat on the UA Side – There is guidance in the ARINC 661 standard for UA development, but it is quite limited.  Traditional software development for ARINC 661 is very likely to lead to excessive risk and cost for complex systems.  This can be mitigated by applying small special ARINC 661 adaptations to the development process and by using an “Abstraction Layer” that hides ARINC 661 concerns from display interaction development.

Over Confidence – the ARINC 661 standard allows for flexibility and is itself not overly complex, but in reality difficulties arise when making key design decisions and applying the standard to moderate and large scale system interactions.  This is best mitigated by utilising specialist development tools that enforce good practice and prevent common problems.

Development Tool-Suite

Specialist development tools are needed both for the CDS layer and widget design / development and also for the specialised User Application to CDS interaction.  FSS have partnered with specialist graphics tool vendor Presagis to supply the complete ARINC 661 development tool suite as a COTS solution.  The tool-suite is made up from three components:

VAPS-XT 661 – CDS side - Design layers, create widgets, and automatically build definition files, with a DO178 certification pack.  Create designs quickly, test them on supplied CDS Kernel.

UA2 - UA side – Develop the interaction between the core system and the display, by extending your preferred model based development tool and process, complete with a path to DO178 certification.  Develop interactions with easy to use behaviours, leading to elegant scalable solutions.

UA Emulator – UA and CDS Side – Build ARINC 661 protocol messages for a loaded definition file, prove CDS and UA designs, automate the unit testing of widgets and layers.  Analyse message traffic to understand which system is causing faults to occur.


ARINC 661 should be considered as a mature and necessary technology for any safety critical situation where systems interact with displays, especially where requirements or systems are likely to change over a delivered system’s development and usage lifetime.  Major airframe manufacturers have invested heavily in order to see real returns in terms of both cost savings and project risk reduction.  Other industry sectors are beginning to follow this lead, for example ARINC 661 has been used within military systems including rotary wing and land-vehicles.

ARINC 661 has some peculiarities, but mature specialist tools are available to keep developers and designers on a sensible path leading to successful delivery.

Notes on the Author

Rob Harwood-Smith is an active member of the ARINC 661 committee, with a particular interest in the User Application side of ARINC 661.  Rob is a Computer Software Architect and has been involved with helping others deliver efficient UA solutions for several years.

Other Resources

An introduction to the ARINC 661 standard in also on Wikipedia.