ARINC661 Introduction Tutorial

Ref: FSS/UA
2
/WP/0001
Revision #1, March 2013
ARINC 661 An Introduction / Tutorial
Page 1 of 9
Copyright Flexible Software Solutions Ltd. All rights reserved.
Abstract
This mini tutorial provides a brief introduction to ARINC 661 standard, including its purpose, benefits,
key constituent parts and common pitfalls. The tutorial explains the key reasons why ARINC 661 has
become widely adopted, and introduces the principle technical concepts and potential difficulties.
Citations to this paper are welcome, as are online links and references.
Copyright Statement
Copyright 2013, Flexible Software Solutions Ltd. This document is protected by international copyright law. No part of this
document may be distributed, by way of trade or otherwise, be lent, resold, hired out or otherwise circulated without the
written consent of Flexible Software Solutions Ltd, Cale House, Wincanton, Somerset, BA9 9FE, UK. It shall not be repackaged,
or distributed in a different form. If distributed with the publishers permission the conditions shall be imposed on the
subsequent purchaser.
Flexible software Solutions Ltd DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED.
Contents
The Who, What, Why and How of ARINC 661! ....................................................................................... 2
Some Terms ............................................................................................................................................. 2
System Architecture ................................................................................................................................ 3
One Protocol to Rule Them All ................................................................................................................ 3
The Basic Anatomy of an ARINC 661 Display .......................................................................................... 4
Window Configuration ........................................................................................................................ 4
Widget Library ..................................................................................................................................... 4
Definition Files The Display Definition.............................................................................................. 5
What Does All This Physically Mean? ...................................................................................................... 6
Closer Look at a Widget-Type definition ................................................................................................. 6
Look is separated from Function ...................................................................................................... 7
What Does ARINC 661 Mean for Certification? ...................................................................................... 7
Does ARINC 661 have Limitations? ......................................................................................................... 7
What Common Difficulties are Associated with ARINC 661? .................................................................. 8
Development Tool-Suite .......................................................................................................................... 8
Summary.................................................................................................................................................. 8
Notes on the Author ................................................................................................................................ 9
Comments, Suggestions or Corrections? ............................................................................................ 9

Ref: FSS/UA
2
/WP/0001
Page 2 of 9
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.

Ref: FSS/UA
2
/WP/0001
Page 3 of 9
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.

Ref: FSS/UA
2
/WP/0001
Page 4 of 9
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 Description
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.

Ref: FSS/UA
2
/WP/0001
Page 5 of 9
The ARINC 661 standard collects widget-types into categories, this grouping helps identify a widgets
primary purpose, some widget types belong to multiple categories.
Widget Type Category Description
Container 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.
Interactive 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
Utility 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 Description
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.
Layer 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.

Ref: FSS/UA
2
/WP/0001
Page 6 of 9
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
Doc. Section
Purpose
Categories The widget categories that the widget type belongs to. So readers can
Instantly determine if the widget has a graphical representation or not (for
instance).
Description Brief description defining the purpose of the widget
Commentary 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.
Restriction Typically used to define limitations on parent/child widget types.
Parameters Defines the properties of the widget type and a short description for each
propertys 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.
Ref: FSS/UA
2
/WP/0001
Page 7 of 9
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 widgets appearance. E.g. size, colour, and style-set. Each widget types 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 way 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.
Ref: FSS/UA
2
/WP/0001
Page 8 of 9
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 is 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. We have partnered with 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.
UA
2
- 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.
Summary
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 systems 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.

Ref: FSS/UA
2
/WP/0001
Page 9 of 9
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.

Comments, Suggestions or Corrections?
We aim to provide informative and valuable information in an accessible way. Help us improve our
content by providing feedback; please get in touch via the contact form on the website
www.uasquared.co.uk .

ARINC661 Introduction Tutorial

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ARINC661 Introduction Tutorial

Uploaded by

Copyright:

Available Formats

Ref: FSS/UA

You might also like