Cockpit Display System Interfaces To User Systems: Arinc Specification 661-2
Cockpit Display System Interfaces To User Systems: Arinc Specification 661-2
AN DOCUMENT
Prepared by
AIRLINES ELECTRONIC ENGINEERING COMMITTEE
Published by
AERONAUTICAL RADIO, INC.
2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401
This document is based on material submitted by various
participants during the drafting process. Neither AEEC nor ARINC
has made any determination whether these materials could be
subject to valid claims of patent, copyright or other proprietary rights
by third parties, and no representation or warranty, express or
implied, is made in this regard. Any use of or reliance on this
document shall constitute an acceptance thereof “as is” and be
subject to this disclaimer.
©2005 BY
AERONAUTICAL RADIO, INC.
2551 RIVA ROAD ANNAPOLIS, MARYLAND
21401-7436 USA
Aeronautical Radio, Inc. (ARINC) was incorporated in 1929 by four fledgling airlines in the
United States as a privately-owned company dedicated to serving the communications needs of
the air transport industry. Today, the major U.S. airlines remain the Company’s principal
shareholders. Other shareholders include a number of non-U.S. airlines and other aircraft
operators.
ARINC sponsors aviation industry committees and participates in related industry activities that
benefit aviation at large by providing technical leadership and guidance and frequency
management. These activities directly support airline goals: promote safety, efficiency,
regularity, and cost-effectiveness in aircraft operations.
a) ARINC Characteristics – Define the form, fit, function, and interfaces of avionics and
other airline electronic equipment. ARINC Characteristics indicate to prospective
manufacturers of airline electronic equipment the considered and coordinated
opinion of the airline technical community concerning the requisites of new
equipment including standardized physical and electrical characteristics to foster
interchangeability and competition.
b) ARINC Specifications – Are principally used to define either the physical packaging
or mounting of avionics equipment, data communication standards, or a high-level
computer language.
The release of an ARINC Standard does not obligate any airline or ARINC to purchase
equipment so described, nor does it establish or indicate recognition or the existence of an
operational requirement for such equipment, nor does it constitute endorsement of any
manufacturer’s product designed or built to meet the ARINC Standard.
In order to facilitate the continuous product improvement of this ARINC Standard, two items are
included in the back of this volume:
An Errata Report solicits any corrections to the text or diagrams in this ARINC Standard.
ii
ARINC REPORT 661
TABLE OF CONTENTS
3.3.22.2.1.12 Filled_Poly_Start...............................................................................101
3.3.22.2.1.12.1 Fill Style Index Values.......................................................................101
3.3.22.2.1.13 Symbol_Oval ....................................................................................101
3.3.22.2.1.14 Item_Synchronization .......................................................................102
3.3.22.2.2 A661_ParameterStructure_BufferOfItems.............................................103
3.3.22.3 MapHorz ItemList Interactive Items............................................................104
3.3.23 MapLegacy.....................................................................................................107
3.3.24 MapHorz_Source............................................................................................108
3.3.25 MapHorz.........................................................................................................111
3.3.26 MaskContainer ...............................................................................................114
3.3.27 Panel ..............................................................................................................116
3.3.28 PicturePushButton..........................................................................................117
3.3.29 PictureToggleButton .......................................................................................120
3.3.30 PopUpPanel ...................................................................................................124
3.3.31 PopUpMenu....................................................................................................126
3.3.31.1 PopUp Specific A661_ParameterStructure ................................................128
3.3.32 PopUpMenuButton .........................................................................................129
3.3.33 PushButton.....................................................................................................132
3.3.34 RadioBox........................................................................................................135
3.3.35 RotationContainer...........................................................................................136
3.3.36 ScrollPanel .....................................................................................................137
3.3.37 ScrollList......................................................................................................... 141
3.3.37.1 ScrollList Specific A661_ParameterStructure.............................................145
3.3.38 Symbol ...........................................................................................................146
3.3.39 TabbedPanel ..................................................................................................147
3.3.40 TabbedPanelGroup ........................................................................................150
3.3.41 ToggleButton ..................................................................................................152
3.3.42 TranslationContainer ......................................................................................154
3.4 Widget Library Expansion ........................................................................................155
3.4.1 MapGrid .............................................................................................................. 155
3.4.1.1 MapGrid A661_ParameterStructure Specifics............................................159
3.4.1.2 Fill Style Index Values................................................................................160
3.4.2 ExternalSource....................................................................................................161
3.4.3 MapVert .............................................................................................................. 163
3.4.4 MapVert_Source .................................................................................................165
3.4.5 MapVert_ItemList ................................................................................................169
3.4.5.1 MapVert_ItemList Standard Items Description ........................................... 171
3.4.5.2 MapVert_ItemList A661_ParameterStructure Specifics .............................172
3.4.5.2.1 Item Structures ..........................................................................................172
vi
ARINC REPORT 661
TABLE OF CONTENTS
APPENDICES
A Glossary .................................................................................................................. 251
B Acronyms and Abbreviations .............................................................................................. 255
C Example of a Definition File .....................................................................................257
D Example of “In/Out” Widget Management Using Styleset Parameter.......................273
E Map Management Tutorial .......................................................................................274
ix
ARINC SPECIFICATION 661 - Page 1
1.0 INTRODUCTION
This document defines a standard Cockpit Display System (CDS) interface intended
for all types of aircraft installations. The primary objective is to minimize the cost to
the airlines, directly or indirectly by accomplishing the following:
• Minimize the cost of acquiring new avionic systems to the extent it is driven
by the cost of CDS development
• Minimize the cost of adding new display function to the cockpit during the life
of an aircraft
• Minimize the cost of managing hardware obsolescence in an area of rapidly
evolving technology
• Introduce interactivity to the cockpit, thus providing a basis for airframe
manufacturers to standardize the Human Machine Interface (HMI) in the
cockpit
This document defines two external interfaces between the CDS and the aircraft
systems. The first is the interface between the avionics equipment (user systems)
and the display system graphics generators. The second is a means by which
symbology and its related behavior is defined. A user application is defined as a
system that transmits data to the CDS, which, in turn can be displayed as visual
graphical information to the flight deck crew. A user application can also include
software or hardware that receives input from interactive graphics managed by the
CDS.
The CDS provides graphical and interactive services to user applications within the
flight deck environment. When combined with data from user applications, it should
display graphical images to the flight deck crew.
This document defines an interface between the CDS and user applications (UA).
The application that controls the interface is defined to be within the CDS.
This document does not specify the “look and feel” of any graphical information.
This document refers to user application data formats that are specified in existing
ARINC 700-series documents:
ARINC Characteristic 735A: Traffic Alert and Collision Avoidance System (TCAS)
Communication between user applications and the cockpit display system may be
implemented over a physical data bus defined in system-level standards, such as:
ARINC SPECIFICATION 661 - Page 2
1.0 INTRODUCTION
1.3 Interoperability
1.3.1 General
One of the primary objectives of this document is to define interface protocols that
can be met by any equipment manufacturer. This level of interface standardization is
different from a typical form, fit, and function standard.
This document emphasizes the need for standardized communication between the
CDS and user applications. This approach is expected to facilitate the development
of standardized subsystems that can easily interface with the CDS.
COMMENTARY
Avionics user systems should connect to the cockpit display system using interfaces
based upon industry standards. This allows flexibility in the installation with the wide
variety of display systems.
The desire for interoperability makes it necessary to standardize input and output
interface parameters. The CDS interfaces should be capable of exchanging data in
the form of input/output messages as defined in this Specification.
This Specification defines a set of logical interfaces that support change containment
and preserve investment across both aircraft types and hardware generations.
COMMENTARY
1.3.3 Modularity
COMMENTARY
User application developers should consider the role of a Cursor Control Device
(CCD) in their equipment design. Application software should be structured in a
manner that allows addition or modification of ARINC 661 input in general and
cursor-based commands in particular. Software should be capable of adapting the
HMI to fit different cockpit philosophies. This is expected to evolve as airline crews
gain experience with existing and evolving levels of interactivity.
The CDS is a significant portion of the flight deck crew interface. Therefore, the
equipment design should contribute positively to overall aircraft system performance,
operational integrity and availability goals for all types of aircraft operations.
1.5 Reliability
The airlines desire reliability in all phases in the design, production, installation and
operation of a display system.
COMMENTARY
The vast majority of military and government standards are usually written in terms
of “shall” and “shall not.” However, it is often difficult to describe airline operator
preferences that have grown out of experience over time. For this reason, this
Specification is written to express airline desires in the form of guidance material.
ARINC SPECIFICATION 661 - Page 4
1.0 INTRODUCTION
Designers should interpret this document in terms of the “need” for specific design
practices rather than practices that “must” be met under all circumstances.
ARINC 661 display equipment should meet all applicable regulatory requirements.
This Specification should not and does not define the specific requirements that an
equipment manufacturer must follow to be assured of approval. Such information
should be obtained from the appropriate regulatory authority.
The latest versions of the following documents apply to the development of a CDS:
1.9 Applicability
The CDS architecture should be robust with sufficient integrity, availability, reliability,
and capacity to support any or all of the display types listed below. Also, it should
enable growth to support other features that may be required in the future, as
constrained only by what will physically fit in the cockpit. This CDS is not intended for
cabin use.
2.1 Introduction
This section describes the concept of operation for the standard protocol used
between avionic equipment User Applications (UA) and the Cockpit Display
System (CDS). This approach segregates the interactive event management and
rendering details from the functional context displayed. The interface defined in this
standard relies on a basic set of graphical user interface objects, hereafter referred
to as “widgets.”
The list of widgets is referred to as the ARINC 661 Human Machine Interface (HMI)
Widget Library. It is described in detail in Section 3.2, HMI Widget Library. In
general, these widgets correspond to a displayable entity. Some of these widgets
are “interactive widgets” because they support crew member interaction using
cursor control devices and keyboards. Crew member actions on interactive widgets
are generally associated with event reports sent to the UA. The non-interactive
widgets do not have any associated event.
The CDS should manage the actual rendering of the widgets as well as monitoring
the flight deck crew interaction via display system input devices.
The UA should specify through the Definition File (DF), the characteristics of all the
instances of each widget they use in the initial design or are expected to use. This
is described in detail in Section 4.1.1, Definition File and User Application Layer
Definition (UALD). These widgets are allocated inside the CDS.
Characteristics and capabilities are the focus of this document, not the
implementation of these capabilities.
The general approach for the widget interface is to segregate the UA functional
description from the “look and feel” of HMI pages. The “look and feel” description
refers to graphical characteristics such as color and border properties.
UAs should manage the widget interface in order to illustrate their functional state.
Consequently, they should only manage functional states of widgets. UAs have no
need to directly interact with “look and feel” characteristics.
The “look and feel” characteristics of a widget are linked with its functional
characteristics. Thus, UAs may have to use a reference to a set of “look and feel”
references in order to reflect their functional context. This service is provided by
ARINC SPECIFICATION 661 - Page 6
2.0 CONCEPT OF OPERATION
The definition phase consists of loading and interpreting Definition Files (DF) in the
CDS.
The DF specifies the creation of widgets that describe User Application (UA)
interface pages.
The interpretation of the DF by the CDS results in the creation (instantiation and first
setting of all parameters) of widgets.
All widgets should be created at this definition time to enable deterministic allocation
of memory. The necessary memory size should be reserved at definition time for the
allocation of the widgets. Items should be specified at run-time inside their container
widget. Refer to Section 3.2.8, Map Management.
Some parameters can only be set at definition time. Among these parameters are all
the parameters which have an impact on the memory size allocation.
The definition phase should be closed for one DF before the beginning of the run-
time data exchange for widgets defined inside this DF (run-time phase for this DF).
COMMENTARY
Defining the end of the definition phase and the beginning of the run-
time phase is beyond the scope of this document. It is CDS
integrator’s choice to implement one global definition phase or an
individual definition phase for each DF.
The run-time phase consists of dynamic data transfers between UA and CDS using
ARINC 661 run-time commands. These exchanges cover the following needs:
From UA to CDS:
• Update the run-time widget parameters
• Request to the CDS for change on entities managed by the CDS, for
example layer visibility and direct focus motion
From CDS to UA:
• Notification of event occurrence for application event processing
• CDS configuration command, for example, notification of application layer
activation
2.2.3.1 Initialization
The CDS is the master of display configurations. The CDS determines the formats to
be displayed and the UA Layers that will appear. Therefore, a UA should not
transmit any data to the CDS before the CDS has notified the UA that its layer is
ACTIVE (refer to Section 4 for such notification format).
In some conditions, the CDS may loose its image of the widget parameters as the
UA has set them. In this event, the CDS can transmit a request for Layer Re-
initialization. The UA should then update, as necessary, the layer widget parameters
AND request the visibility of the layer. The CDS will not display the layer before this
request is received in a message block.
External conditions may lead the CDS to remove a layer from the display. In such a
case, the CDS may notify the UA that the layer is INACTIVE. Upon such a
notification, the UA should stop its update of the layer widget parameters.
A CDS conforms to this standard when it implements all ARINC 661 mechanisms, all
standardized widgets and potentially other widgets, as necessary.
The ARINC 661 library should evolve in a manner that is compatible with the library
defined herein. For example, if optional parameters were to be added to an existing
widget, default values should be defined such that existing equipment can continue
to use the older data block format. A new WidgetType ID should be created, defined,
and used to indicate that the new size and format definition parameter block is in
use.
Window
Display
(managed
Unit
by the CDS ) Layer
(owned by one
Widget
User Application)
environment constraints. Each format on a Display Unit (DU), shown in Figure 2.3-1,
consists in a set of windows, defined by the current configuration of the CDS. A
window is subdivided in layers. These layers are connected to the user applications
and provide an area to display their widgets.
Windows are owned and managed by the CDS. In particular the CDS manages the
visibility of the window. The UA may have no knowledge of the window set-up.
Therefore, this section is provided as guidance and not considered a requirement for
the interface between UA and CDS. Windows have the following characteristics:
• A format image rendered to a display unit surface is constructed from one or
more windows
• The windows included in a format image of a DU are fully defined in the
configuration definition. The window visibility is managed by the CDS according
to the current configuration
• A window defines a rectangular physical area of the display surface
• A window may not be resized
• Windows cannot overlap each other
• A window consists of one or more layers
A layer is the highest level entity of the CDS that is known by the UA. From the UA
point of view, the Layer is the highest level container in the hierarchical structure of
the UA widgets. From the CDS point of view, the layer is one graphical layer
associated with one application inside a window. The definition of layer layout within
a window is beyond the scope of this standard.
Layers provide the mechanism to combine information from several UA inside one
window.
COMMENTARY
In the hierarchical structure of the DU format image definition, the layers are
containers just under the window level.
One ARINC 661 Layer is associated with one UALD. Thus, each layer has only one
owner, that is, the owner of its associated UALD. A layer contains the hierarchical
structure of widgets defined inside its associated UALD.
COMMENTARY
The UA has only the knowledge of its layer, not the knowledge of the
containing window, which is defined by current CDS configuration.
A layer has two properties: Active/Inactive and Visible/ Invisible. For definition of
commands to manage these properties, refer to Section 4.4.3.2, Request/Notification
from CDS to UA.
2.3.2.4.1 Visibility
All objects within a layer should become invisible when the layer becomes invisible
by control of the layer visibility parameter. This does not affect the current value of
each widget visibility parameter.
2.3.2.4.2 Activity
The activity of the layer is controlled by the CDS. When a layer is active, the CDS
should to update the data from the UA that owns the layer, even if the layer is not
visible. Refer to Section 4.4.3, ARINC 661 Request/Notification for
A661_REQ_LAYER_ACTIVE.
When a layer becomes inactive, its visibility is turned off by the CDS. When the layer
becomes active, it is the responsibility of the UA to turn on the visibility of its layer.
Also, when a layer becomes active, the UA should reinitialize the data of its layer
COMMENTARY
When the layer is inactive, the CDS has only to consider the
A661_REQ_LAYER_ACTIVE request command from the UA owning
the layer.
Context management covers the notion of correlation between the data exchanged
and the data displayed at a given time.
The CDS sends the current context number of the layer containing the interacted
widget inside the block structure.
ARINC SPECIFICATION 661 - Page 12
2.0 CONCEPT OF OPERATION
The initial value of the context number is set inside the layer definition block (UALD).
Context number allows the UA to manage the internal state of its display in the CDS.
The CDS controls the configuration of the cockpit by defining the following:
• The correct window to go on the specific DU
• The correct application layer to go in the specific window. The CDS notifies
the UA that a window containing layers of this UA is displayed and the UA
has to be ready for widget management through notification
A661_NOTE_LAYER_IS_ACTIVE
A UA can send the CDS a request to display one of its layers. The CDS may accept
or reject this request depending on the configuration logic that is implemented at that
time. Refer to Section 4.4.3, ARINC 661 Request/Notification for
A661_REQ_LAYER_ACTIVE.
y +
z x
Figure 2.3.4 - Graphic references for widget positioning
2.3.4.1 Origins
All origins are in the lower left-hand corner of the object. Origin of widgets within
containers is relative to the immediate container.
Any exception to these provisions will be clearly stated in the detailed description of
the widgets.
2.3.4.2 Angles
All angles are measured in degrees. All rotation is around the Z-axis. The ZERO
degree is along the X-axis in the positive direction. The positive direction of rotation
is in the counter-clockwise direction from the X-axis. When specifying an arc, the arc
becomes a complete circle when the StartAngle and EndAngle represent the
minimum and maximum possible values of fr(180).
Any exception to these provisions will be clearly stated in the detailed description of
the widgets.
ARINC SPECIFICATION 661 - Page 13
2.0 CONCEPT OF OPERATION
All screen units should be measured in units of millimeters with a resolution of 0.01
millimeters. Therefore, the position and size of widgets are expressed with a
resolution of 0.01 millimeters. Widget position parameters are signed integer and
widget size parameters are unsigned integer. Refer to Section 3.2, HMI Widget
Library Summary. Any exception to these provisions is clearly stated in the detailed
description of the widgets.
The cursor is controlled by the CDS. The cursor shape is defined by the CDS. The
cursor shape is an element of the “look and feel” of the cockpit and is managed in a
homogeneous way throughout the different formats. The cursor shape depends on
the type of the widget that holds the cursor (e.g., button, text editor) and the current
state of this widget (e.g., editing mode). Nevertheless, some information related to
the cursor may be exchanged between the CDS and the UAs.
Two key terms are most important to the understanding of the cursor management in
ARINC 661. They are respectively: Focus and Highlight.
• An interactive widget is focused when it receives the events triggered by a
crew member through non-CCD input devices (such as keyboard).
• An interactive widget is highlighted when the cursor passes over its
interactive area. Depending on the implementation, the click may select
and/or focus the widget.
Focus and highlight are defined as two independent characteristics of an object;
however relationship between them is implementation dependent. Focus and
Highlight may change the graphical look of a widget.
Another example is the ability to inform the CDS at definition time of widget
navigation order, which supports CDS management of focus navigation. Refer to
Section 3.1.3.5, Parameters Relative to Focus Navigation.
COMMENTARY
The CDS provides the ability to perform the first four of these tasks within itself,
drastically reducing the processing load on the user system, if used properly.
COMMENTARY
System integrators and designers are reminded that the flight deck is
not an office desk-top environment. Thus, common desk-top practices
such as “double click” may be difficult to implement successfully.
Turbulence may produce an unintended double click. Data
transmission rates may make it difficult for the display system to
recognize a double click. Therefore, if a double click feature is used in
the system design, the CCD should bear the responsibility for
recognizing this situation and transmit it as a discrete event to the
display system.
ARINC SPECIFICATION 661 – Page 15
3.0 WIDGET LIBRARY
A widget is defined with respect to the UA to which it belongs. Widget identifiers are
assigned and managed by the UA. A widget identifier, referred to as [WidgetIdent], is
unique in one User Application Layer Definition (UALD).
Since the CDS manages layers and their priorities, the CDS needs to know at
definition time to which layer a widget belongs. Therefore, the CDS also needs a
relative [LayerIdent] from the UA. A [LayerIdent] referenced by the “User Application
A” could be identical to a [LayerIdent] referenced by the “User Application B.”
Internally the CDS resolves its internal Layer Identification by using the [User
Application Ident].
At definition time, the interface between CDS and UA should uniquely define widgets
by the combination: [UserApplicationIdent].[LayerIdent].[WidgetIdent]
COMMENTARY
State level 4 is the visual representation. In the ARINC 661 CDS interface, the
complete definition of the visual representations might freeze the widget behavior
internal to the CDS. To avoid this, visual representation should be part of the aircraft
original equipment manufacturers (OEM) specification and implemented by the CDS
supplier in the CDS Widget Library.
A UA should not have any direct access to the visual representations. Therefore,
visual presentations do not have to be defined within the ARINC 661 interface
protocol. Only the ARINC 661 parameter effects on graphical representation should
be described in the ARINC 661 interface. The style guide defined by the OEM
should describe the “look and feel” and thus, provide necessary information to UAs
for their HMI interface design.
Both CDS and the owner UA of a widget can manage the inner states of a widget.
For instance, considering a CheckButton:
• Upon selection by a crew member, the CDS will change the widget inner state
from SELECTED to UNSELECTED or from UNSELECTED to SELECTED.
• The UA may change the inner state to initialize or refresh the interface reasons
Therefore, a conflict situation may occur that is based on the fact that inner states of
an interactive widget are generally managed by the CDS. When the CDS changes
the state of a widget based upon crew member interaction, it sends an event to
inform the UA of the interaction. In this case, the widget is considered as an IN
widget. Interactions from the crew member enter the IN widget.
ARINC SPECIFICATION 661 – Page 17
3.0 WIDGET LIBRARY
W id g e t s ta te s
V is ib le In v is ib le S ta te le v e l 1
In n e r s ta te 1 In n e r sta te n S ta te le v e l 2
S ta te le v e l 3
E n a b le D is a b le E n a b le
D is a b le
N o rm a l F o cu s S ta te le v e l 4
N o rm a l F ocus
But the inner state is not supposed to reflect a functional context of the UA. This
means that the inner state should not be used to display the fact that the UA has
taken into account the interaction. If the UA wants to display its functional context
though the interactive widget, the widget is considered as an OUT widget. The
widget is used to provide functional information to the crew member. This
information should be covered by “StyleSet” parameter.
The CDS has the responsibility to provide a graphical feedback upon a crew
member interaction through the inner state. The UA has the responsibility to provide
a functional feedback on crewmember interaction. If the UA wants to display this
functional feedback on the widget itself, it should use the “StyleSet” parameter.
If inner states are used for both command and functional context, their management
by both CDS and UA will lead to conflicts known as a “race condition.”. However, the
UA will have to change inner states of its widgets, for initialization or refresh of its
interface. The UA should take into account the probability of “race condition” for
example, turning off and then on the visibility (or interactivity) of the widgets after
refresh of their inner states.
Different types of race conditions have been identified for managing an inner state,
for example:
• Command from a UA arrived just before an interaction from a crew member in
the CDS
ARINC SPECIFICATION 661 - Page 18
3.0 WIDGET LIBRARY
The CDS must take into account the UA command, where the UA is the
master of widget management.
COMMENTARY
This section includes tables that identify the parameters commonly used by all
widgets of the ARINC 661 library.
A661_TRUE:
• If all its parent are visible, the widget will be rendered.
• If one or all its parents are invisible, the widget will not be rendered,
whatever the value of its visible parameter.
Enable A661_FALSE:
The widget will not be interactive.
A661_TRUE:
• If all its parent are enabled, the widget will be interactive.
• If one or all its parents are disabled, the widget will not be
interactive, whatever the value of its Enable parameter.
An invisible widget is not interactive, independent of the value of its Enable
parameter.
A661_TRUE: anonymous.
Widget can not be modified at run-time by UA. CDS behavior when a UA
attempts to SetParameter on an anonymous widget is undefined.
Aircraft OEM (or CDS supplier) defines the list of StyleSet values.
The PosX, PosY, SizeX and SizeY parameters define a clipping area for the widget.
Graphical characteristics must not be rendered outside this area.
This area defines the static area of the widget. For widget containing a “Pop Up part”
such as ComboBox, only the static part is constrained by these parameters.
ARINC SPECIFICATION 661 – Page 21
3.0 WIDGET LIBRARY
Management of directional motion of the focus, e.g., through arrow keys, is internal
to CDS, and therefore does not require interface level parameters.
However, it is possible for the UA to specify a “logical” navigation order through the
use of a given key (for example, tabulation). This can be done using the
“NextFocusedWidget” parameter.
A661_TRUE:
Move automatically the focus after a crew member validation to the
next widget according to the NextFocusedWidget parameter
Widgets notify User Applications of events caused by crew actions. More precisely,
when the human operator uses the CDS to act on an interactive widget, and the
action generates an event, the CDS notifies the UA owning the layer that contains
the widget, according to the structure defined in Table 4.5.4.2-3.
The events that each widget can generate are listed in tables that appear with the
widget definition, generally shown between the Creation Structure Table and the
Runtime Modifiable Parameters Table for that widget.
ComboBoxEdit Like ComboBox, ComboBoxEdit provides a means to select one item in a list of
items. This widget is composed of a static part displaying the selected item and
a pop up part displaying possible items.
EditBoxMultiLine EditBoxMultiLine is a text edit box for displaying text across several lines in a
scrolling area.
ExternalSource The function of the ExternalSource widget is to specify to the CDS where an
external input should appear on the display. For example, an external input
may be a video signal input or a bitmap image.
MapGrid MapGrid provides a means for conveying arrays of data to the CDS that are
rendered as area fills. The intended use is for filling areas on background
layers of the NAV window with colors and/or patterns that indicate terrain
topography, precipitation intensity, or other irregular, dynamic data.
MapVert The MapVert widget is the counterpart of the MapHorz widget for a vertical
display made of a slice presentation. It is based on Cartesian coordinate
system.
MapVert_ItemList The MapVert_ItemList is equivalent to the MapHorz_ItemList for vertical
displays. A MapVert_ItemList contains a list of Items to be drawn.
MapVert_Source The MapVert_Source is the equivalent of the MapHorz_Source for vertical
displays. The MapVert_Source widget is a specialized container. It contains
some MapVert_ItemList widgets to display Items expressed in a common
coordinate system.
MenuBar A MenuBar is a widget containing PushButtons, PicturePushButtons and
PopUpMenuButtons. It implements specific behaviors to move from one button
to another.
WIDGET EXPANSION SUPPLEMENT 2
SelectionListButton The SelectionListButton allows a crew member to select one entry within a list.
This widget is composed of a fixed label and a pop up part displaying the
ScrollList of items.
Table 3.2.2-1 describes the categories of widgets in the Widget Library. Table 3.2.2-
2 defines the widget classifications. These categories are not exclusive, and a
widget may belong to several categories.
Map Graphical
Widget Manage- Dynamic Represen- Text
Categories/Widgets Container ment Motion tation string Interactive
WIDGET
EXPANSION
SUPPLEMENT 1
3.4.1 MapGrid X X
3.4.2 ExternalSource X
3.4.3 MapVert X X
3.4.4 MapVert_Source X X X
3.4.5 MapVert_ItemList X X X X
3.4.6 EditBoxMultiLine X X X
3.4.7 ComboBoxEdit X X X
3.4.8 MenuBar X X
WIDGET
EXPANSION
SUPPLEMENT 2
3.5.1 MutuallyExclusive X
Container
3.5.2 ProxyButton X
3.5.3 WatchdogContainer X
3.5.4 Slider X X
3.5.5 PictureAnimated X
3.5.6 SymbolAnimated X X
3.5.7 SelectionListButton X X X
3.2.3 Container
All objects within a Container become invisible when the Container becomes
invisible, as controlled by the Container visible parameter. This should not
automatically affect the current value of each widget parameters. The UA is
responsible for insuring the coherence of its HMI, for instance the management of
EditBoxText inner state. When a container becomes invisible, a contained EditBox
can not stay in its EDIT inner state.
All objects within a container become non-interactive when the Container becomes
non-interactive, controlled by the Container enable parameter. This will not
automatically affect the current value of each widget parameters.
Widgets placed within Container widgets have their coordinates referenced to the
PosX, PosY reference point of the Container. If the Container has no reference
point, widgets placed within the Container have their coordinates referenced to the
PosX, PosY of the first parent containing a reference point.
Table 3.2.3.1 describes the possible children of Container widgets. Although the
layer is not a widget, it has been listed with the Container because of its capability to
be the parent of widgets.
ARINC SPECIFICATION 661 - Page 28
3.0 WIDGET LIBRARY
MutuallyExclusiveContainer
Parents
TranslationContainer
WatchdogContainer
TabbedPanelGroup
RotationContainer
BlinkingContainer
MapHorz_Source
MapVert_Source
BasicContainer
MaskContainer
Children
TabbedPanel
PopUpPanel
ScrollPanel
RadioBox
MenuBar
MapHorz
MapVert
Layer
Panel
ActiveArea X X X X X X X X
BasicContainer X X X X X X X X
BlinkingContainer X X X X X X X X X X X
BufferFormat X
CheckButton X X X X X X X X X
ComboBox X X X X X X X X
Connector X X X X X
CursorPosOverlay X X X X X X X X
EditBoxMasked X X X X X X X X
EditBoxNumeric X X X X X X X X
EditBoxText X X X X X X X X
GpArcCircle X X X X X X X X X X X X
GpArcEllipse X X X X X X X X X X X X
GpCrown X X X X X X X X X X X X
GpLine X X X X X X X X X X X X
GpLinePolar X X X X X X X X X X X X
GpRectangle X X X X X X X X X X X X
GpTriangle X X X X X X X X X X X X
Label X X X X X X X X X X X X
LabelComplex X X X X X X X X
MapHorz X X X X X X X X
MapHorz_ItemList X
MapHorz_Source X X X
MapLegacy X
MaskContainer X X X X X X X X X X
Panel X X X X X X X X
Picture X X X X X X X X
PicturePushButton X X X X X X X X X
PictureToggleButton X X X X X X X X X
PopUpMenu X X X X X X X X
PopUpMenuButton X X X X X X X X X
PopUpPanel X X X X X X X
PushButton X X X X X X X X X
RadioBox X X X X X X X X
RotationContainer X X X X X X X X X X X X
ScrollList X X X X X X X X
ARINC SPECIFICATION 661 – Page 29
3.0 WIDGET LIBRARY
MutuallyExclusiveContainer
Parents
TranslationContainer
WatchdogContainer
TabbedPanelGroup
RotationContainer
BlinkingContainer
MapHorz_Source
MapVert_Source
BasicContainer
MaskContainer
Children
TabbedPanel
PopUpPanel
ScrollPanel
RadioBox
MenuBar
MapHorz
MapVert
Layer
Panel
ScrollPanel X X X X X X X X
Symbol X X X X X X X X X X X X
TabbedPanel X X
TabbedPanelGroup X X X X X X X X
ToggleButton X X X X X X X X X
TranslationContainer X X X X X X X X X X X X
WIDGET EXPANSION
SUPPLEMENT 1
ComboBoxEdit X X X X X X X X
EditBoxMultiLine X X X X X X X X
ExternalSource X X X X X X X X X
MapGrid X X
MapVert X X X X X X X X
MapVert_ItemList X
MapVert_Source X X X
MenuBar X X X X X X X
WIDGET EXPANSION
SUPPLEMENT 2
MutuallyExclusive X X X X X X X X
Container
ProxyButton X X X X X X X X X
WatchdogContainer X X X X X X X X
Slider X X X X X X X X
PictureAnimated X X X X X X X X
SymbolAnimated X X X X X X X X X X X
SelectionListButton X X X X X X X X
Some widgets contain a string of text (digits, characters, and related symbols). This
section describes the available character set for concatenation into a text string.
ARINC SPECIFICATION 661 - Page 30
3.0 WIDGET LIBRARY
It also describes the escape sequences principles. The escape capabilities are only
available for the following widgets:
• ComplexLabel
• ScrollList
The escape sequences may be embedded in a text string to allow special formatting
to occur. The default graphic properties for the text are defined through the
“DefaultStyleText” parameter.
For widgets containing a text string, the “MaxStringLength” parameter defines the
maximum size of the string; the size is expressed in bytes. This size includes the
NULL character that ends the string. For strings containing escape sequences, this
size includes all characters, plus the escape sequences, plus the NULL character
that ends the string. If several NULL characters end the string (for padding), only the
first one is counted inside this length.
Table 3.2.5.1-1 defines the characters available for text strings inside widgets. The
characters in this table are representative of the shapes. It is not intended to define a
font.
Control characters
Hex Char Description
h00 NULL Null character, character for ending a text string.
h0A LF Line Feed
h0D CR Carriage Return
h1B ESC Escape Character, character beginning all escape sequences.
ARINC SPECIFICATION 661 – Page 31
3.0 WIDGET LIBRARY
Txxx : describes a type of element. It represents a set of text values (code or string).
Concatenation of strings -
Concatenation of sets -
If Kyyy = '0' and Txxx = {‘a’, ‘b’, ‘c’} then Kyyy⊗Txxx = {‘0a’, ‘0b’, ‘0c’}
Table 3.2.5.3-1 lists the available change style capabilities through escape
sequence.
ARINC SPECIFICATION 661 – Page 33
3.0 WIDGET LIBRARY
All escape sequences begin with an “ESC” character, shown in Table 3.2.5.5-1,
Escape Sequences Description. An Escape Identifier follows the ESC character
(values from h40 to h41) and any specific parameters required by the sequence
(designated by Tvalue). Some escape sequence will apply to the following
characters, for instance TForeColor, while some escape sequences will apply
between the start and end sequences, for instance TVideoInv.
Where:
P1: is a hex value from 0 to 255 representing the integer number of times to repeat
the set of characters embedded between the escape sequences:
“ESC⊗KRepeat_B⊗P1” and “ESC⊗KRepeat_E”
3.2.6 Interactive
Interactive widgets are widgets that have the ability to send an event to their UA. An
interactive widget has an Event Structure table attached. Some interactions on these
widgets induce an event transmitted to the UA. These widgets will implement
different graphical representations according to their state. Refer to Section 3.1.2,
Widget States.
UAs have the ability to move dynamic motion widgets at run-time. The parameters
PosX, PosY are modifiable at run-time for a dynamic motion widget.
There are two types of map: Horizonal and Vertical. In both cases interaction
between widgets composing a Map is similar. Following widgets are considered as a
part of Map Management group:
For more detailed information about specific widget refer to the corresponding
paragraph in Section 3.3. Widgets as well as a set of predefined symbols are defined
at definition time. Number and position of symbols vary at runtime.
Horizontal maps have been used in avionics systems for a considerable amont of
time. More recently, vertical maps have been introduced. For this reason more in
depth analysis is performed for the horizontal map.
COMMENTARY
The UA, which provides MapHorz_ItemList to the CDS, is called a Map User
Application. To allow display of the MapHorz_ItemLists in the display area, the Map
User Application also provides to the CDS characteristics its MapHorz_ItemLists
coordinate system through a widget called MapHorz_Source.
One UA is responsible for passing to the CDS, required reference information for the
CDS to perform the merger. In this way, this UA federates all MapHorz_Source data
to enable CDS to perform the merger. This application is called the master
application. The master application provides reference information to the CDS
through a widget called MapHorz widget.
COMMENTARY
Different kinds of UAs could be developed to merge data. The description of such
UAs is beyond the scope of this document.
The MapHorz_Source parent can only be the MapHorz widget or the layer. The layer
only contains the MapHorz_Source (one or several). One MapHorz_Source can be
shared between several MapHorz widgets by using the Connector widget.
The master application manages the visibility of MapHorz_Source from other layers
through the connector widget. Indeed the Connector widget has a visibility
parameter.
MapHorz_Source 1
Map User Application 1
MapHorz_ItemList11 MapHorz_ItemList12
MapHorz_Source 2
Map User Application 2
MapHorz_ItemList21 MapGrid
LEGEND:
: Layer
: Tree of Widgets inside one layer
: Owner of the Layer : Connection of one layer to another layer
To define the parameters for MapHorz and MapHorz_Source, the system integrator
should review the possible Map User Applications and the kind of display a master
application may require. Several examples of master applications are described in
the Appendix E, Map Management Tutorial.
ARINC SPECIFICATION 661 – Page 39
3.0 WIDGET LIBRARY
The level 1 and 2 drawing priority are defined statically. The level 3 drawing priority,
which is the drawing priority for the item, is defined dynamically at run-time.
COMMENTARY
Some widgets have been defined without graphical representation neither interactive
or container capability. This widget has specific functionality in order to extend or
optimize the ARINC 661 defined principle:
• BufferFormat
• Connector
This section describes the characteristics and the interface of ARINC 661widgets.
For each widget the definition is divided into parts as follows:
• Definition section
• Widget parameters table
• Creation structure table: CreateParameterBuffer
• Event Structure table
• Run-time modifiable parameter tables
Specific sections are described as follows:
1. This section states the categories of the widget, functional description of the
widget and any restrictions to ARINC 661 principles.
2. This section presents the Parameters Table which describes all parameters of
the object. These parameters are divided into two categories: “Commonly used
parameters” with a reduced description and “Specific parameters” with a
complete description. For “commonly used parameter” full descriptions, refer to
Section 3.1.3. Also, for “commonly used parameters”, additional information and
differences from the norm are underlined.
For each parameter, the following information is presented:
• Name of the parameter
• Possible modifications of parameter by the UA (“change” column)
o D: parameter set at definition time only through A661_CMD_CREATE
command
o DR : parameter set at definition time through A661_CMD_CREATE and
modifiable at run time through A661_CMD_SET_PARAMETER command
o R : parameter modifiable only at run time through
A661_CMD_SET_PARAMETER command
• Description of the parameter
This section describes the format of the exchanges at definition-time, the Create
command, as well as at run-time, Widget Event notifications and SetParameter
commands for each widget. This description is completed by the fourth section.
The coding format is Big Endian. The types are defined by Table 3.3-1. Fields in the
table appear on the bus in the order they are listed.
ARINC SPECIFICATION 661 – Page 41
3.0 WIDGET LIBRARY
The parameter order in this table may be different from the order in the Widget
parameter table. Indeed, the Widget parameter table describes parameter functional
aspect, while the Creation structure table describes the parameter buffer coding
aspect.
4. This section presents the “Event Notification Structure” which describes the
structure of the events associated with the widget. It describes the events that
are able to be sent to the UA by the CDS initiated by a crew member
interaction.
ARINC SPECIFICATION 661 - Page 42
3.0 WIDGET LIBRARY
5. This section describes the table of parameters modifiable at run time. This
table refers to some parameterStructure. This table describes the accessible
commands to the UA that manages the widget at run-time.
3.3.1 ActiveArea
Categories:
Graphical representation
Interactive
Description:
The ActiveArea is transparent rectangular widget. The ActiveArea may have
a graphical representation when this widget is highlight or when it has the
focus. A selection of this widget by a crew member initiates an event
notification sent to the owner UA of the widget.
Restriction:
None
Table 3.3.1-3 defines the specific event sent by the ActiveArea to the owner
application.
3.3.2 BasicContainer
Categories:
Container
Description:
The BasicContainer has no graphical representation. Its purpose is to group children
widgets and to provide a means for managing the visibility and the interactivity of this
set of widgets. The contained widgets are positioned with respect to the PosX, PosY
of the BasicContainer. It has no clipping capabilities. The position of the
BasicContainer can be changed at run-time.
ARINC SPECIFICATION 661 - Page 44
3.0 WIDGET LIBRARY
COMMENTARY
Restriction:
N/A
3.3.3 BlinkingContainer
Categories:
Container
Description:
A BlinkingContainer is intended to apply blinking behavior to a group of widgets.
Restriction:
N/A
3.3.4 BufferFormat
Categories:
None
Description:
The objective of this widget is to provide a means for grouping data from different
widgets (but one layer) in one buffer to reduce overhead. For example, rather than
sending <layer id><widget id><parameter id><value><layer id><widget
id><parameter id><value><layer id><widget id><parameter id><value><layer
id><widget id><parameter id><value>, a supplier can instead define the structure:
The buffer structure is fixed at definition time through the BufferStructure parameter.
The maximum size of the buffer of values is a function of the number and the nature
of the parameters. This buffer structure contains a set of parameter modifiable at
run-time. The CDS will perform a set on each parameter identified in the structure.
The widgets referenced in this BufferFormat widget must be defined in the Definition
File before the BufferFormat widget. Uses for the BufferFormat include initialization
of a layer, and refresh of a large number of widgets at the same time.
Restrictions:
• The BufferFormat can only be the child of a layer
• The BufferFormat can not contain “Definition Only” parameters
• The BufferFormat can not contain parameters which are used inside one of the
following structure
A661_ParameterStructure_Buffer
A661_ParameterStructure_BufferOfItems
A661_ParameterStructure_EnableArray
A661_ParameterStructure_EntryPopUpArray
A661_ParameterStructure_StringArray
Indeed, this list corresponds to variable size parameters.
• The BufferFormat can only contain parameters which are used inside one of the
following structure
A661_ParameterStructure_1Byte
A661_ParameterStructure_2Bytes
A661_ParameterStructure_4Bytes
ARINC SPECIFICATION 661 – Page 47
3.0 WIDGET LIBRARY
A661_ParameterStructure_String
A661_ParameterStructure_8Bytes
Variable-size structures can not be used inside the Buffer parameter of the
BufferFormat. The Buffer parameter of the BufferFormat can only be composed of
simple parameter values. One exception is the String, which is preceded by two
bytes describing the size of the string in bytes (including the NULL character
terminating the string).
3.3.4.1 A661_ParameterStructure_Buffer
The string parameter is defined with the following structure and an alignment on 16
bits:
• 1 * 2Bytes (StringLength) + StringLength * 1Byte + PAD (0 or 8 bits unusedPad
to align on 16 bits)
• The stringLength is expressed in Bytes, it describes the number of characters in
the string (including the NULL ending the string)
32 bits boundary
Unused Pad
3.3.5 CheckButton
Categories:
• Graphical representation
• Interactive
• Text string
Description:
A CheckButton allows the crew member to select or not select an option.
Restriction:
N/A
The specific event sent by the CheckButton to the owner application is defined in
Table 3.3.5-3.
3.3.6 ComboBox
Categories:
• Graphical representation
• Interactive
• Text string
Description:
The ComboBox allows a crew member to select one entry within a list. Only the
current choice is displayed in the ComboBox area. The number of the current
selected entry is held in the SelectedEntry parameter. The complete list of possible
Entries is held in a string array (parameter EntryList). The list is displayed upon crew
member selection. For example, click on the arrow button associated with the
Selected Entry.
The pop-up part of the ComboBox is displayed on top of its containing window and is
affected by clipping area of its containing window.
COMMENTARY
Restriction:
N/A
ARINC SPECIFICATION 661 – Page 52
3.0 WIDGET LIBARARY
The specific event sent by the ComboBox to the owner application is defined by
Table 3.3.6-3.
3.3.7 Connector
Categories:
None
Description:
The purpose this widget is to connect a layer to the container of a different layer.
Examples of the use of the Connector widget include TabbedPanelGroup and
MapHorz, both of which mix data from several UAs. The action of the Connector
widget is functionally like a call to a library routine, or similar reference to a
preceding definition. The Connector widget allows another UA to get an image of the
referenced widgets. The Connector widget does not imply ownership, copying of the
data, or write access. All events associated with the image are handled by the
owning application.
Restriction:
The Connector widget capability across physical display surfaces is dependent on
system architecture.
Each layer has one priority defined by the current configuration, it does not inherit
the priority of its parent layer. In this way, L3 will not inherit the priority of L1 nor L2.
Indeed, one UA, for instance, the owner of the L3, can not draw in the graphical
layer of another UA in L1 or L2.
The connected layer rendering is affected by the properties of the Container of the
connector including: Position, Clipping area, Visible, Enable. Thus, the connected
layer has an origin that is defined with respect to the origin of Connector widget
parent.
COMMENTARY
3.3.8 CursorPosOverlay
Categories:
Interactive
Description:
A CursorPosOverlay widget consists of a defined area of the display. The
distinguishing characteristic of a CursorPosOverlay is that the reportable event is the
current cursor pointer position relative to the CursorPosOverlay. The event is
reported on upon selection by a crewmember with a click or keyboard selection.
Restriction:
N/A
The specific event sent by the CursorPosOverlay to the owner application is defined
in Table 3.3.8-3.
ARINC SPECIFICAGTION 661 – Page 57
3.0 WIDGET LIBRARY
3.3.9 EditBoxMasked
Categories:
• Graphical representation
• Interactive
• Text string
Description:
The Masked edit box is an extension of the Text edit box. The difference with the
basic Text edit box is that some characters are not modifiable by the crew member.
The characters that are not able to be modified are specified by the UA by setting
the “alpha mask” parameter and the “numeric mask” parameters to 0.
If a character is only numerical [0..9] , the masks for this character are 1 for numeric
mask and 0 for alpha mask. If a character is only alphabetic ie. All the printable
characters defined in Table 3.2.5.3-1 - Available Character Set excepted [0..9] and
SPACE, the masks for this character are 0 for numeric mask and 1 for alpha mask.If
a character is alpha-numeric, the masks for this character are 1 for numeric mask
and 1 for alpha mask. The size of this string is limited to 32 characters.
COMMENTARY
A661_EDB_ALL_CHANGE
CDS will report the edit mode opening
A661_EVT_EDITBOX_OPENED
CDS will report each update from the crew member while in edit
mode
(A661_EVT_STRING_CHANGE)
CDS will report the value change after crew member validation
(A661_EVT_STRING_CONFIRMED)
CDS will report the value if the crew member aborts the edit
(A661_EVT_STRING_CHANGE_ABORTED)
A661_EDB_OPEN_CLOSE
CDS will report the edit mode opening
A661_EVT_EDITBOX_OPENED
CDS will report the value change after crew member validation
(A661_EVT_STRING_CONFIRMED)
CDS will report the value if the crew member aborts the edit
(A661_EVT_STRING_CHANGE_ABORTED)
3.3.10 EditBoxNumeric
Categories:
• Graphical representation
• Interactive
• Text string
Description:
The EditBoxNumeric widget enables editing a numeric value. A crew member can
modify the numeric value using input devices. Since a numeric value is used, the
CDS is able to increment the value. The widget can receive a number of incremental
values or a numeric key value.
COMMENTARY
Examples:
3.3.11 EditBoxText
Categories:
• Graphical representation
• Interactive
• Text string
Description:
A EditBoxText widget enables displaying a string, which can be modified by a crew-
member.
The CDS is responsible to perform the following changes of state:
From NORMAL to EDIT
ARINC SPECIFICAGTION 661 – Page 67
3.0 WIDGET LIBRARY
COMMENTARY
3.3.12 GpArcEllipse
Categories:
• Graphical Representation
• Dynamic motion
Description:
The graphical primitive GpArcEllipse widget enables the definition of an arc. The arc
may be a portion of an ellipse or circle. The arc is defined by a bounding box where
a rectangle is specified and the ellipse is drawn touching the rectangle. When the
bounding box is a square, the arc will be a circle. The major and minor axes of the
ellipse are implicitly along the cardinal directions of the bounding box.
UNFILLED FILLED
ARC ARC
Restriction:
None
3.3.13 GpArcCircle
Categories:
• Graphical Representation
• Dynamic motion
Description:
The graphical primitive GpArcCircle widget enables the definition of a circular arc.
The circle is defined by a center and radius.
Restriction:
none
3.3.14 GpCrown
Categories:
• Graphical Representation
• Dynamic motion
Description:
The graphical primitive GpCrown widget enables the definition of a circular filled
region. The circle is defined by a center and two radii. The filled area is the area
between the radii.
Restriction:
None
3.3.15 GpLine
Categories:
• Graphical Representation
• Dynamic motion
Description:
The graphical primitive GpLine widget enables the definition of a line. The line is
defined in rectangular coordinates by two pairs of X,Y coordinates that define the
end points of the line.
Restriction:
None
3.3.16 GpLinePolar
Categories:
• Graphical Representation
• Dynamic motion
Description:
The graphical primitive GpLinePolar widget enables the definition of a line. The line
is defined by polar coordinates with an X,Y coordinate start position, a line length,
and a draw angle.
Restriction:
None
3.3.17 GpRectangle
Categories:
• Graphical Representation
• Dynamic motion
Description:
The graphical primitive GpRectangle widget enables the definition of a rectangle.
The primitive defines the start position and the width and height of the rectangle.
Restriction:
None
3.3.18 GpTriangle
Categories:
• Graphical Representation
• Dynamic motion
Description:
The graphical primitive GpTriangle widget enables the definition of a triangle. The
primitive defines the three XY coordinate pairs that specify three points of the
triangle.
Restriction:
None
3.3.19 Picture
Categories:
Graphical representation
Description:
A Picture widget is a reference to an image available in the CDS. The Picture
reference can be modified by the UA. Unlike symbols, a picture can not move or
rotate.
Restriction:
N/A
3.3.20 Label
Categories:
• Graphical representation
• Dynamic Motion
• Text string
Description:
A Label widget consists of a non-editable text field at a defined display location. If
the label is anonymous, it is not editable (i.e., it can not be modified at runtime by the
UA). If it is not anonymous, it can be modified by the UA. However, a label can not
be modified by a crew member.
Restriction:
None
ARINC SPECIFICATION 661 – Page 86
3.0 WIDGET LIBRARY
3.3.21 LabelComplex
Categories:
• Graphical representation
• Text string
Description:
A LabelComplex widget consists of a non-editable text field at a defined display
location. If the LabelComplex is anonymous, it is not editable (i.e., it can not be
modified at runtime by the UA). If it is not anonymous, it can be modified by the UA.
However, a LabelComplex can not be modified by a crew member.
The text string can embedded escape sequences, refer to Section 3.2.5.5, Escape
Sequences Description.
Restriction:
N/A
ARINC SPECIFICATION 661 – Page 89
3.0 WIDGET LIBRARY
3.3.22 MapHorz_ItemList
Categories:
• Map management
• Graphical Representation
• Interactive
• Text string
Description:
A MapHorz_ItemList widget represents a group of related graphics. Examples of the
use of the MapHorz_ItemList widget is the creation of flight plan, map background
symbols, TCAS intruders, etc.
Insert and delete operations are not allowed on the list. However, one specific type
of Item is NOT_USED. The Item with the NOT_USED type will be ignored, i.e., is
they will have no effect on the processing of following items.
Restriction:
A MapHorz_ItemList must be in a MapHorz_Source container.
MapHorz_ItemList Parameters are defined in Table 3.3.22-1.
ARINC SPECIFICATION 661 – Page 92
3.0 WIDGET LIBRARY
Legend Relative
Relative Relative
Symbol_Generic
Legend_Anchor Symbol_Generic
05
Symbol_Generic
Legend Legend
Real world Relative
coordinate Legend_Anchor
055 NW134
Relative
Legend_Anchor
All the structures include the same format: three fields for the first 4-byte word. One
field is not used on all Items, however it is maintained for consistency.
3.3.22.2.1.1 Item_Style
3.3.22.2.1.2 Legend_Anchor
3.3.22.2.1.4 Line_Start
3.3.22.2.1.5 Line_Segment
3.3.22.2.1.6 Line_Arc
Inbound course
Inbound course
Radius <0
Radius <0
(left)
(left)
To specify a complete circle, set the CourseChange to the negative LSB represented
by fr(180) or 0xFFFFFFFF.
3.3.22.2.1.7 Not_Used
3.3.22.2.1.8 Symbol_Generic
3.3.22.2.1.9 Symbol_Circle
3.3.22.2.1.10 Symbol_Rotated
3.3.22.2.1.11 Symbol_Runway
3.3.22.2.1.12 Filled_Poly_Start
There are restrictions on the polygons to be filled. In particular, the number of line
segments is limited to three segments (triangle) or four segments (quadrilateral). The
vertices must be specified in counter-clockwise order. The polygon must be convex.
If any error is found in the polygon definition, the CDS should send an
A661_ERR_SET_ABORTED exception event. The airframe manufacturer/system
integrator free data field may include, for example, the ItemIndex to identify the error.
A Fill Style Index is an unsigned 8-bit value that is used to select a graphic
representation (fill style) from a pre-defined table for use in filling an area on a layer.
Because fill styles depend heavily on CDS hardware capabilities, and because they
are look-and-feel related, they are not further defined in this specification.
COMMENTARY
The actual fill styles used will depend on both the CDS hardware
capability and the supplier/airframe manufacturer/system
integrator/customer preference for look-and-feel. A fill style may be a
solid color fill, a patterned fill, an alpha blend, or other visual attribute.
3.3.22.2.1.13 Symbol_Oval
3.3.22.2.1.14 Item_Synchronization
This item has been defined to attach to a symbology frame data that expressed the
symbology computation context or the rendering context. The functional data is
attached to the symbolgy frame though A661 in order to avoid synchronization issue
between the symbology frame and the computation contextual information (e.g.
mode, range; MRP, etc).
For illustration, considering the case of a master application having the responsibility
to turn on/off the visibility of the connector on a user application symbology layer,
when the Mode/Range context is correct/incorrect.
Due to different ways for data transmission, and potential delay on symbology
projection before displaying, a de-synchronization may exist between the symbology
displaying and the check by the Master application of the functional context used by
the User Application. This de-synchronization has a potential effect on the display.
3.3.22.2.2 A661_ParameterStructure_BufferOfItems
This section describes how display applications can specify interactive map items.
The CDS highlights interactive items on the map that are close to the cursor. If the
user depresses the select button while the interactive item is highlighted, an event is
sent by the CDS to the UA. This section covers both MapVert and MapHorz
interactive items.
The interactive items available are a subset of those listed in Table 3.3.22.1-1. The
constant values for the interactive map items have the same lower seven bits as
those listed in Table 3.3.22.1-1 with the eighth bit set. The interactive map items are
listed below with their constant values listed inTable 4.6-11.
LINE_ARC_INTERACTIVE
LINE_SEGMENT_INTERACTIVE
LINE_START_INTERACTIVE
SYMBOL_CIRCLE_INTERACTIVE
SYMBOL_GENERIC_INTERACTIVE
SYMBOL_ROTATED_INTERACTIVE
SYMBOL_RUNWAY_INTERACTIVE
FILLED_POLY_START_INTERACTIVE
SYMBOL_OVAL_INTERACTIVE
Recommended Behavior:
For line sequences that consist of more than one segment, the application can
choose whether highlighting and event reporting is based on individual segments or
the entire sequence.
Figure 3.3.22.3-1 shows a very long line, and for this example it is assumed that the
application splits the line into four segments. This could serve the purpose of helping
the CDS draw an accurate image of a great-circle line.
Table 3.3.22.3-1: Map Item List Example for Highlighting and Event Reporting
of Individual Segments
Ind Item Type Data
ex
1 Symbol_Generic Coordinates of SFO, waypoint symbol
2 Legend String “SFO”
3 Symbol_Generic Coordinates of FFM, waypoint symbol
4 Legend String “FFM”
5 Line_Start Coordinates of FFM
6 Line_Segment_Interactive Coordinates of Point 1
7 Line_Segment_Interactive Coordinates of Point 2
8 Line_Segment_Interactive Coordinates of Point 3
9 Line_Segment_Interactive Coordinates of FFM
When the cursor is within highlighting distance of a line segment, only that segment
is highlighted (Figure 2). If the pilot clicks on a segment, the
A661_EVT_SELECTION event that is sent to the application carries the item index
of the segment that was highlighted at the time of the click (item 8 in
Table 3.3.22.3-1).
(Point 2)
(Point 3)
(Point 1)
SFO FFM
If the application would like to treat the sequence of line segments as a single entity
(that just happens to be drawn as separate lines), it may want the entire sequence to
be highlighted whenever the cursor is within highlighting distance of any of the line
segments, as shown in Figure 3.3.22.3-3 below:
(Point 2)
(Point 3)
(Point 1)
SFO FFM
As far as event reporting (upon a mouse click) goes, the application can ask the
CDS to do one of two things:
1. to send the item index of the individual segment that was highlighted at the time
of the click, or
2. to send the item index of the LINE_START_INTERACTIVE item (i.e. the same
item regardless of which of its line segments was clicked on).
The application makes this choice by using the LINE_SEGMENT_INTERACTIVE
item type if it wants event information for the individual segment, as opposed to the
LINE_SEGMENT item type if it wants an event for the overall line sequence. In
either case, the line begins with a map item of type LINE_START_INTERACTIVE.
Table 3.3.22.3-2 below shows an example of a line where event reporting is based
on the line segment. A click with the cursor as shown in Figure 3.3.22.3-3 would
store an item index of 8 in the event structure, as was the case in the previous
example (Table 3.3.22.3-1):
Table 3.3.22.3-2 - Map Item List Example for Highlighting Entire Sequence With
Event Reporting of Individual Line Segments
Index Item Type Data
1 Symbol_Generic Coordinates of SFO, waypoint symbol
2 Legend String “SFO”
3 Symbol_Generic Coordinates of FFM, waypoint symbol
4 Legend String “FFM”
5 Line_Start_Interactive Coordinates of FFM
6 Line_Segment_Interactive Coordinates of Point 1
7 Line_Segment_Interactive Coordinates of Point 2
8 Line_Segment_Interactive Coordinates of Point 3
9 Line_Segment_Interactive Coordinates of FFM
The example in Table 3.3.22.3-3 does not look any different to the pilot. However,
when a click on any of the flight plan segment occurs, the item index field in the
event message is set to 5 (the index of the LINE_START_INTERACTIVE item)
regardless of the particular segment that was clicked on:
Table 3.3.22.3-3 - Map Item List Example for Highlighting and Event Reporting
Based on the Entire Line Sequence
Index Item Type Data
1 Symbol_Generic Coordinates of SFO, waypoint symbol
2 Legend String “SFO”
3 Symbol_Generic Coordinates of FFM, waypoint symbol
4 Legend String “FFM”
5 Line_Start_Interactive Coordinates of FFM
6 Line_Segment Coordinates of Point 1
7 Line_Segment Coordinates of Point 2
8 Line_Segment Coordinates of Point 3
9 Line_Segment Coordinates of FFM
ARINC SPECIFICATION 661 – Page 107
3.0 WIDGET LIBRARY
The following table (Table 3.3.22.3-4) summarizes the CDS behavior. For each line
segment, its type (interactive or non-interactive) as well as the type of the beginning
of the current line (interactive or non-interactive) determines the highlighting and
event behavior.
Note: Straight lines were used in the examples. The concept applies to arcs
(LINE_ARC and LINE_ARC_INTERACTIVE) the same way.
3.3.23 MapLegacy
Categories:
• Map management
• Graphical Representation
Description:
The MapLegacy widget provides a means for the CDS to be compatible with legacy
data formats used with display systems prior to the introduction of ARINC 661. The
purpose is to define the means by which the visibility of this kind of data will be
managed in relation with other Map UAs. The format of the data and the link to
transmit the data depends on the legacy type. Therefore, the data buffer should not
be sent through ARINC 661 commands. The CDS and UAs that exchange this type
of widget should define together how the CDS processes this data. The MapLegacy
is not an interactive widget.
Restriction:
A MapLegacy should be in a MapHorz_Source container.
3.3.24 MapHorz_Source
Categories:
• Map management
• Container
• Interactive
Description:
The MapHorz_Source widget is a specialized container. It contains some
MapHorz_ItemList widgets to display Items expressed in a common coordinate
system.
Restriction:
The MapHorz_Source should be directly under a MapHorz or a Layer widget. When
directly attached to a Layer, the layer should not be attached to a window displayed
alone.
ARINC SPECIFICATION 661 – Page 109
3.0 WIDGET LIBRARY
3.3.25 MapHorz
Categories:
• Container
• Map management
Description:
A MapHorz widget consists of a rectangular region on the display, which contains
reference information to enable the display of map features in the cockpit. The
MapHorz widget enables multiple sources of information with different coordinate
systems to be merged into a composite map image.
MapHorz provides information for resolving coordinate system disparities among the
map sources. MapHorz also has the responsibility for containing multiple map
sources such that the data is merged properly into a composite representation.
Restriction:
None
ARINC SPECIFICATION 661 – Page 112
3.0 WIDGET LIBRARY
Commentary: For the ND, PRP is the aircraft position for ARC and
ROSE mode. For PLAN mode the PRP is a waypoint of the FPLN. In
mode PLAN, the PRP can be populated by the FMS through the ND.
Equivalence between “MapHorz coordinate system” and “MapHorz Screen Coordinate system”
Screen Reference DR X and Y Position of the PRP on the screen. This position is expressed
Point X in MapHorz Screen Coordinate System refer to (X Pos, Y Pos)
Screen Reference DR
Point Y
Range DR Geo-referenced range
ScreenRange DR Distance in screen unit (0.01 mm) equivalent to range
3.3.26 MaskContainer
Categories:
Container
Description:
A MaskContainer widget applies a mask to a group of widgets to implement non-
rectangular clipping. A mask should be referenced and placed by the Container.
Widgets placed within this Container will be affected by the referenced mask.
Restriction:
None
3.3.27 Panel
Categories:
• Container
• Graphical representation
Description:
A Panel widget groups several widgets together in a rectangular area with clipping
capabilities. Widgets placed within a Panel widget have their coordinates referenced
to the PosX, PosY reference point of the Panel.
Restriction:
None
3.3.28 PicturePushButton
Categories:
• Interactive
• Graphical representation
• Text string
Description:
A PicturePushButton widget is a PushButton including a picture and possibly a
string.
Restriction:
None
ARINC SPECIFICATION 661 – Page 118
3.0 WIDGET LIBRARY
3.3.29 PictureToggleButton
Categories:
• Graphical representation
• Interactive
• Text string
Description:
A PictureToggleButton widget is a button with two stable states with a picture and
possibly text.
Restriction:
Nnone
ARINC SPECIFICATION 661 – Page 121
3.0 WIDGET LIBRARY
3.3.30 PopUpPanel
Categories:
• Container
• Graphical representation
• Interactive
Description:
PopUpPanel widgets should be displayed on the top of other layer, but it is
affected by clipping area of its parents.
Restriction:
PopUpPanel Parameters are defined in Table 3.3.30-1.
The specific event sent by the PopUpPanel to the owner application is defined in
Table 3.3.30-3.
3.3.31 PopUpMenu
Categories:
• Graphical representation
• Interactive
• Text string
Description:
The PopUpMenu widget should be displayed on the top of other layer, but it is
affected by clipping area of its parents. PopUpMenu is not a Container.
PopUpMenu invisibility should be managed by the CDS using logic defined by the
airframe manufacturer/system integrator. The UA or CDS can define the position of
the Container according to the OpeningMode value.
Restriction:
None
The specific event sent by the PopUpMenu to the owner application is defined in
Table 3.3.31-3.
EntryIndex 8
Enable 8 A661_FALSE
A661_TRUE
Picture 16
StringLength 16
String 8 * string Followed by zero, one, two or three NULL
length + PAD character(s) to be 32 bits aligned.
3.3.32 PopUpMenuButton
Categories:
• Graphical representation
• Nteractive
• Text string
Description:
The PopUpButton widget contains a Button widget that displays a PopUpMenu,
which is internal to the CDS.
This widget contains a PopUpMenu widget. The UA has the responsibility to define
the position of the PopUpMenu.
Restriction:
None
3.3.33 PushButton
Categories:
• Graphical representation
• Interactive
• Text string
Description:
A PushButton widget is a momentary switched Button, which enables the crew to
launch an action.
A PushButton has only one inner state, so there is no need for an inner state
parameter.
ARINC SPECIFICATION 661 - Page 133
3.0 WIDGET LIBRARY
Restriction:
None
This event indicates to the UA that a crew member has interacted with the widget.
3.3.34 RadioBox
Categories:
Container
Description:
A RadioBox widget manages the visibility and the interactivity of a group of Buttons
(CheckButtons or ToggleButtons). It enables a crew member to select one Button
out of “n” exclusive ones. At a given time one item maximum can be SELECTED.
A selection of a selected item by a crew member is without effect. Never the less,
the UA can deselect the selected item (through setParameter command) to create
a RadioBox without selection. The Buttons contained in the RadioBox should be
individually defined with the RadioBox as a parent widget. RadioBox does not have
any graphical representation.
Restriction:
The children of the RadioBox will be positioned relative to the parent of the
RadioBox. A RadioBox has only children types:
1. ToggleButton
2. PictureToggleButton
3. CheckButton
Only one type can be used in a given RadioBox at a time. The CDS assures that
internal state of the children is consistent (no more than one is selected) at all
times, including when the user changes the state of the children.
3.3.35 RotationContainer
Categories:
Container
Description:
A RotationContainer widget applies a rotation transformation to a group of widgets.
Widgets placed within RotationContainer have their coordinates referenced to the
first parent with a PosX, PosY reference point.
Restriction:
For RotationContainer restriction refer to Table 3.2.3.1 for children/parents.
RotationContainerParameters are defined in Table 3.3.35-1.
Table 3.3.35-1 - RotationContainerParameters
Parameters Change Description
Commonly used parameters
WidgetType D A661_ROTATION_CONTAINER
WidgetIdent D Unique identifier of the widget.
ParentIdent D Identifier of the immediate container of the widget.
Visible DR Visibility of the widget
Specific parameters
CenterX DR X position of the center of the rotation
CenterY DR Y position of the center of the rotation
RotationAngle DR Rotation angle to be applied to the children widgets
ARINC SPECIFICATION 661 - Page 137
3.0 WIDGET LIBRARY
3.3.36 ScrollPanel
Categories:
• Container
• Graphical representation
Description:
A scroll container is composed of two elements:
Frame, at fixed location. This location is the position of the widget (as already
known), defined by the parameters PosX, PosY, SizeX, SizeY.
Sheet, larger than the Frame, at a variable location with respect to the Frame. This
location is defined by the variables FrameX, FrameY, SizeXsheet, SizeYsheet.
Note that X/Y coordinates of the sheet are called FrameX and FrameY.
Indeed, the sheet X/Y coordinates should in fact be interpreted as the offset of the
sheet relative to the frame according to standard coordinate system, shown in
Figure 3.3.36.
The CDS should provide scroll controls (scroll bars and/or scroll buttons, according
to the airframe manufacturer/system integrator style guide). Typically, this is based
on the relative size of the frame and the sheet. For instance, if X size of the frame
is smaller than the X size of the sheet, the CDS should set a horizontal scroll
control. Two parameters are available to allow the UA to choose from a variety of
positions according to the airframe manufacturer/system integrator style guide.
Restriction: The reference position for the children of the ScrollPanel is the FrameX
and FrameY.
ARINC SPECIFICATION 661 - Page 139
3.0 WIDGET LIBRARY
3.3.37 ScrollList
Categories:
• Graphical Representation
• Interactive
• Text string
Description:
A ScrollList widget enables the display of a list of entries and selection of one entry
from among this list. Entries are text strings, possibly including escape sequences.
This is specified through the DefaultStyleText Definition Time Only parameter, if
set to null, all labels can be considered by the CDS as being like normal Labels. As
a consequence of the use of escape sequences, one entry in the ScrollList can
correspond to several lines. The size of the selection area is determined by
graphical parameters (size of widget, number of entries), and not by the text. The
UA should verify that the text fits in the selection area. Scroll controls are provided
by the CDS. For example, these controls could allow for scrolling by single items or
by page. The type of scroll controls provided are CDS OEM dependent.
ARINC SPECIFICATION 661 - Page 142
3.0 WIDGET LIBRARY
With the ScrollList widget the UA can maintain a large list of items external to CDS
and provide a subset to the ScrollList widget. The subset managed by the
ScrollList includes the items that are visable and can also include data within the
immediate vicinity of the viewable area to provide for rapid scrolling. When the UA
updates the ScrollList, the UA has to modify the FirstVisibleEntry if it wants to keep
visible the same items in the list. In this case, ShiftFirstVisibleEntry parameter
allows UA to shift the visible part of the list by the functional difference between the
previous list and the new list sent. In the figure 3.3.37-1, the ShiftFirstVisibleEntry
is used to update the scrollList:
This result can also be reached by setting the FirstVisibleEntry. Indeed, the UA
knows the FirstVisibleEntry through the event notification. Nevertheless as the
crew member can scroll continuously, at the time the update list command will be
interpreted by the CDS, the FirstVisibleEntry may have changed with respect to the
time the UA has computed the command. In this case, the scrollList update will
induce a change of the functional list part visible at screen. For this reason, the UA
should avoid setting FirstVisibleEntry when the user is able to scroll.
Restriction:
SelectedEntry, FirstVisibleEntry and FirstAccessibleEntry assume the first Entry
index to be 1. SelectedEntry is 0, it is interpreted as none.
ARINC SPECIFICATION 661 - Page 143
3.0 WIDGET LIBRARY
EntryIndex 168
Enable 8 A661_FALSE
A661_TRUE
UnusedPad 8 0
String 8 * string Followed by zero, one, two or three NULL
length + character(s) to be 32 bits aligned
PAD
3.3.38 Symbol
Categories:
• Graphical Representation
• Dynamic Motion
Description:
The Symbol widget is similar to the Label widget, except it does not have a Max-
String-Length parameter and the string parameter is replaced by a Symbol-
Reference parameter (outside reference).
Restriction:
None
3.3.39 TabbedPanel
Categories:
• Container
• Graphical Representation
• Text string
Description:
The TabbedPanel widget is functionally composed of a Panel associated with a
Button. This widget can be created only inside a TabbedPanelGroup widget. The
size of the panel part of the TabbedPanel widget is identical for all the
TabbedPanel inside a TabbedPanelGroup and is therefore described by the
TabbedPanelGroup widget. Connectors can be used to move the definition of the
TabbedPanel to a different definition file so that the owning application can control
the parameters of the TabbedPanel.
ARINC SPECIFICATION 661 - Page 148
3.0 WIDGET LIBRARY
Restriction:
The TabbedPanel widget should only be used under a TabbedPanelGroup or a
Layer. When directly attached to a layer, this layer should not be attached to a
window to be displayed alone.
COMMENTARY
3.3.40 TabbedPanelGroup
Categories:
• Container
• Graphical representation
• Interactive
Description:
A TabbedPanelGroup widget groups several TabbedPanel widgets. A
TabbedPanelGroup enables the UA or a crew member to select one of the
TabbedPanel widgets for display. All of the Panels inside the TabbedPanel widgets
occupy the same display space, and only one may be displayed at a time. This
TabbedPanel is the one referenced by the “Active TabbedPanel ID”.
Restriction:
A TabbedPanelGroup can only contain TabbedPanel or Connector widgets.
If TabPosition is Right/Left:
TRUE: CDS defines the button size according to the StyleSet
FALSE: The CDS use the maximum of the sizes defined
inside the TabbedPanel
ActiveTabbedPanelID DR Identifier of the active TabbedPanel
ARINC SPECIFICATION 661 - Page 151
3.0 WIDGET LIBRARY
3.3.41 ToggleButton
Categories:
• Graphical representation
• Interactive
• Text string
Description:
A ToggleButton widget is a two, stable-states Button with text.
Restriction:
None
3.3.42 TranslationContainer
Categories:
Container
Description:
A TranslationContainer widget applies a translation transformation to a group of
widgets. Widgets placed within TranslationContainer have their coordinates
referenced to the first parent with a PosX, PosY reference point.
Restriction:
For TranslationContainer restriction refer to Table 3.2.3.1 regarding
children/parents.
Specific parameters
TranslationX DR X Translation of the child widgets
TranslationY DR Y Translation of the child widgets
ARINC SPECIFICATION 661 - Page 155
3.0 WIDGET LIBRARY
This section was added in Supplement 1. It introduces new widgets to ARINC 661.
3.4.1 MapGrid
Categories:
• Map Management
• Graphical Representation
Description:
MapGrid provides a means for conveying arrays of data to the CDS that are
rendered as area fills. The intended use is for filling areas on background layers of
the NAV window with colors and/or patterns that indicate terrain topography,
precipitation intensity, or other irregular, dynamic data.
The fill is defined by the number of cells in the horizontal and vertical, the size of
each cell in nautical miles or equivalent, the offset of the grid’s (0,0) cell from the
display origin, and the Fill Style Index for each cell. Distances are described in
real-world units, which decouples the UA from the specific display technology. The
entire area defined by each cell boundary is to be filled with the color or pattern or
other graphical attribute as selected by the Fill Style Index. Typically, slightly more
data is supplied than is displayed. The amount of excess depends on several
factors:
ARINC SPECIFICATION 661 - Page 156
3.0 WIDGET LIBRARY
The UA may need to update the MapGrid color data periodically. Since the array
may be large relative to the bandwidth available, provision is made for just a few
(or one) rows or columns at a time. The UA can change the size of a cell, in real-
world units, at run-time to support a balance between range and resolution. The
size of a MapGrid array, in cells, is fixed at Definition Time.
Restriction:
A MapGrid must be in a MapHorz_Source or MapVert_Source containers.
Support for the various MapData Format Values (table 3.3.24-2b) and
MapVert_MapData Format Values (table 3.4.4-2b) depends on the implementation.
MapHorz_Source:
A661_MDF_LAT_LONG: See table 3.3.24-2b.
A661_MDF_DIST_DIST: See table 3.3.24-2b.
A661_MDF_BRG_DIST_ACHDG: See table 3.3.24-2b.
MapVert_Source:
A661_MDF_X_DIST See table 3.4.4-2b
A661_MDF_RELATIVE See table 3.4.4-2b
A661_MDF_ABSOLUTE See table 3.4.4-2b
IncrementY DR Size of each individual cell in the Y axis, in the real-world units defined
by the containing Map Source. Support for the various Map Source Data
Formats depends on the implementation.
MapHorz_Source:
A661_MDF_LAT_LONG: See table 3.3.24-2b.
A661_MDF_DIST_DIST: See table 3.3.24-2b.
A661_MDF_BRG_DIST_ACHDG: See table 3.3.24-2b.
A661_MDF_LEGACY See table 3.3.24-2b.
MapVert_Source:
A661_MDF_Y_ALT See table 3.4.4-2b.
A661_MDF_RELATIVE See table 3.4.4-2b
A661_MDF_ABSOLUTE See table 3.4.4-2b
All the data in the buffer must use the same origin/orientation values. Even though
the buffer can be filled line-at-a-time, over time, all the lines are displayed
simultaneously, and must be internally consistent.
StepX, StepY, and RowMajor typically are constants chosen to work efficiently with
the hardware. By listing them specifically in the message, sender and receiver
communicate and check their assumptions. If a CDS implementation has
restrictions on StartIndexX/Y or NumColumns/NumRows or
StepX/StepY/RowMajor values as noted in the descriptions above, and a UA
violates those restrictions, the CDS must return an Error Notification Structure (see
Section 4.4.2)
The ControlFlag parameter serves two purposes. In the normal case, it must be set
to zero. When the least significant bit is set, it indicates the entire buffer should be
cleared to a Fill Style Index of zero BEFORE this line of data is stored. This allows
the UA to blank the display quickly when required. The meaning of Fill Style Index
zero is not defined here (may be all black, all white, or something else, depending
on flight deck design).
When ControlFlag bit 1 is set, this indicates that the buffer update will be
“complete” AFTER this line of data is stored. This may have a variety of effects.
For example, if double buffering is implemented, it allows the CDS to know when to
swap buffers. Or, if motion compensation is implemented, it allows the CDS to
know that a new frame of data aligned to the current orientation is ready to be sent.
User applications should set this flag whenever these sort of action would be
appropriate.
The initial state of the buffer before any user data are sent is defined to be
“cleared”, that is, set to all zero Fill Style Indices. After that, the CDS is not to
“clear” the buffer except on specific command (i.e. NOT in response to a “buffer
complete” flag). This implies that double-buffering must implement a front-to-back
copy on swap.
A Fill Style Index is an unsigned 8-bit value that is used to select a graphic
representation (fill style) from a pre-defined table for use in filling an area on a
layer. Because fill styles depend heavily on CDS hardware capabilities, and
because they are “look-and-feel”, they are not further defined in this specification.
COMMENTARY
The actual fill styles used will depend on both the CDS hardware
capability and the supplier/airframe manufacturer/system integrator/
customer preference for look-and-feel. A fill style may be a solid
color fill, as is typical of late-1990’s weather radar displays, or it may
be a patterned fill, as is typical of late-1990’s terrain displays, or it
may incorporate alpha (transparency) level or other visual attributes
of which modern graphics hardware is capable.
3.4.2 ExternalSource
Categories:
None
Description:
The function of the ExternalSource widget is to specify to the CDS where an
external input should appear on the display. For example, an external input may be
a video signal input or a bitmap image. Note that if a UA wants to display video on
the CDS, video input processing provisions are necessary in the CDS. The
existence of this widget in this standard does not guarantee that it will be possible
to display a video or a bitmap image. The following points must be clearly
understood:
• The integrator and the CDS supplier define how an external input stream is
to be sent and processed by the display
• The integrator knows the limitations of the CDS for processing of these
input streams. For instance, the CDS may not re-size or rotate video signal
received
Note: the ExternalSource widget is unique in the sense that it is
necessary for the UA supplier and the integrator to define the
specific method to bring video to the display.
Restriction:
None
3.4.3 MapVert
Categories:
• Container
• Map Management
Description:
The MapVert widget is the counterpart of the MapHorz widget for a vertical display
made of a slice presentation. It is based on Cartesian coordinate system. Typically
the horizontal axis will be distance in nautical miles and the vertical axis will be
height in feet. The UA master of the vertical display will have to create such a
widget and through it, provide the following information to the CDS:
• The location of the widget in the window
• The size of the widget
• The geographic correspondence of this size. From there, real world
distance be converted in screen distance on both axes
• Position of a reference point both in screen coordinate and Geographic
coordinates. From there the CDS can interpret absolute or relative
coordinates for Items. For example, on the horizontal axis, the reference
point is 30 mm from origin of widget, 30Nm in geographic coordinates.
Knowing the distance equivalence, the CDS can position either an Item at
45Nm absolute or 15Nm relative to the reference point
Restriction:
None
3.4.4 MapVert_Source
Categories:
• Map management
• Container
• Interactive
Description:
The MapVert_Source is the equivalent of the MapHorz_Source for vertical
displays. The MapVert_Source widget is a specialized container. It contains some
MapVert_ItemList widgets to display Items expressed in a common coordinate
system. The MapDataFormat (X or Y) parameters allow a UA to transmit its data
either in as absolute values or relative to the Reference Point.
Restriction:
The MapVert_Source should be directly under a MapVert widget or a Layer widget.
When directly attached to a Layer, the layer should not be attached to a window
displayed alone.
ARINC SPECIFICATION 661 - Page 166
3.0 WIDGET LIBRARY
Note: Type refers to the data type of the X and Y parameters in the
children of the MapVert_Source.
ARINC SPECIFICATION 661 - Page 168
3.0 WIDGET LIBRARY
3.4.5 MapVert_ItemList
Categories:
• Map management
• Graphical Representation
• Interactive
Text string Description:
The MapVert_ItemList is equivalent to the MapHorz_ItemList for vertical displays.
A MapVert_ItemList contains a list of Items to be drawn. This list is of fixed size
specified through the maximum number of Items. The type of each Item inside the
MapVert_ItemList can be modified at run-time, which makes the list dynamic. A set
of parameters is associated with each type of Item (refer to Section 3.3.22.2.1,
Item Structure).
Insert and delete operations are not allowed on the list. However, one specific type
of Item is NOT_USED. The Item with the NOT_USED type will be ignored, i.e., is
they will have no effect on the processing of following items.
Section 3.4.5.1 describes the standardized items and their functionality. Section
3.4.5.2 describes the A661_ParameterStructure to address the Items.
Restriction:
A MapVert_ItemList must be in a MapVert_Source container.
ARINC SPECIFICATION 661 - Page 170
3.0 WIDGET LIBRARY
All the structures include the same format, three fields for the first 4-byte word.
One field is not used on all Items, however it is maintained for consistency.
3.4.5.2.1.1 Item_Style
3.4.5.2.1.2 Legend_Anchor
3.4.5.2.1.4 Line_Start
3.4.5.2.1.5 Line_Segment
3.4.5.2.1.6 Not_Used
3.4.5.2.1.7 Symbol_Generic
3.4.5.2.1.8 Symbol_Runway
3.4.5.2.1.9 Filled_Poly_Start
There are restrictions on the polygons to be filled. The number of line segments is
limited to three segments (triangle) or four segments (quadrilateral). The vertices
are specified in counter-clockwise order. The polygon must be convex.
If any error is found in the polygon definition, the CDS should send an
A661_ERR_SET_ABORTED exception event. The airframe manufacturer/system
integrator free data field may include the ItemIndex, etc., to identify the error
further.
3.4.5.2.1.10 Item_Synchronization
3.4.5.2.1.11 Symbol_Rotated
3.4.5.2.2 A661_ParameterStructure_BufferOfItems
MapVert interactive items operate the same as Map_Horz interactive items. See
section 3.3.22.3 for more information on interactive map items.
ARINC SPECIFICATION 661 - Page 177
3.0 WIDGET LIBRARY
3.4.6 EditBoxMultiLine
Categories:
• Graphical representation
• Interactive
• ASCII Text
Description:
EditBoxMultiLine is a text edit box for displaying text across several lines in a
scrolling area. The text string can be modified by the crew. When the
EditBoxMultiLine is in edit mode, the CDS only reports the confirmed text string
(after a crew member validation). The purpose of this widget is to allow free text
edit and perform automatic line feed and scroll management.
COMMENTARY
A661_EDB_ALL_CHANGE
CDS will report the edit mode opening
ARINC SPECIFICATION 661 - Page 178
3.0 WIDGET LIBRARY
CDS will report each update from the crew member while in
edit mode
(A661_EVT_STRING_CHANGE)
CDS will report the value change after crew member validation
(A661_EVT_STRING_CONFIRMED)
CDS will report the value if the crew member aborts the edit
(A661_EVT_STRING_CHANGE_ABORTED)
A661_EDB_OPEN_CLOSE
CDS will report the edit mode opening
A661_EVT_EDITBOX_OPENED
CDS will report the value change after crew member validation
(A661_EVT_STRING_CONFIRMED)
CDS will report the value if the crew member aborts the edit
(A661_EVT_STRING_CHANGE_ABORTED)
EntryValidation R Indicator of entry validity, parameter used to display
feedback/state/Information error in case of invalid selection in
the EditBox.
True (valid)
False (invalid)
MaxStringLength D Maximum length of the entire text included the first NULL
character ended the string (in bytes), MaxStringLength > 1.
LabelString DR Text of the edit box
Alignment D Justification of the label text within the edit box area
CENTER
LEFT
RIGHT
VerticalScroll D Position of scroll controls, absent/left/right/bottom/top
StartCursorPos DR Start position of the cursor in field when entering in edit
ARINC SPECIFICATION 661 - Page 179
3.0 WIDGET LIBRARY
The specific event sent by the EditBoxMultiLine to the owner application is defined
in Tables 3.4.6-3, 3.4.6-4, 3.4.6-5 and 3.4.6-6.
3.4.7 ComboBoxEdit
Categories:
• Graphical representation
• Interactive
• ASCII Text
Description:
Like ComboBox, ComboBoxEdit provides a means to select one item in a list of
items. This widget is composed of a static part displaying the selected item and a
pop up part displaying possible items. The number of the current selected entry is
held in the SelectedEntry parameter. The complete list of possible Entries is held in
a string array (parameter EntryList). The list is displayed upon crew member
selection. For example, click on the arrow button associated to the Selected Entry.
Moreover, ComboBoxEdit allows the crew to enter the static part a new item.
When ComboBoxEdit is in edit mode, the CDS may report all modification done on
the edited string and the final confirmed string, or only report the confirmed string
(after a crew member validation). This option may be set by the UA through the
“ReportAllChanges” parameter. If ReportAllChanges is True and, after having
entered a text, the crewmember finally aborts the edit, the CDS should send a
specific event to the UA with the former validated LabelString as parameter of the
event.
The pop-up part of the ComboBoxEdit is displayed on top of its containing window
and is affected by the clipping area of its containing window.
COMMENTARY
Restriction:
N/A
N/A means that this parameter is only used as an event value. It is never set by the
UA (not at definition time nor at runtime).
ARINC SPECIFICATION 661 - Page 183
3.0 WIDGET LIBRARY
The specific events sent by the ComboBoxEdit to the owner application are:
3.4.8 MenuBar
Categories:
Container
Description:
A MenuBar is a widget containing PushButtons, PicturePushButtons and
PopUpMenuButtons. It implements specific behaviors to move from one button to
another.
COMMENTARY
Restriction:
A MenuBar has only children types:
• PushButton
• PicturePushButton
• PopupMenuButton
MenuBar parameters are defined in Table 3.4.8-1.
This section was added in Supplement 2. It introduces new widgets to ARINC 661.
3.5.1 MutuallyExclusiveContainer
Categories:
Container
Description:
The MutuallyExclusiveContainer has no graphical representation. Its purpose is to
group children widgets and to provide a means for managing the exclusive display
of the children. The operation of the MutuallyExclusiveContainer is very similar to
that of the BasicContainer except that only one child of the
MutuallyExclusiveContainer can be visible. All of the children of a BasicContainer
can be visible.
The contained widgets are positioned with respect to the PosX and PosY of the
MutuallyExclusiveContainer. The MutuallyExclusiveContainer does not have
clipping capabilities.
3.5.2 ProxyButton
Categories:
Interactive
Description:
The ProxyButton directs a physical button press as a select event to the target
widget. If the target widget is visible and enabled at the time of the physical button
press, it will respond in the same way as if the user had selected the widget. The
CDS will supply a list of unique identifiers for the selection keys available in the
system. A common use for this feature is a bezel line select soft key. If the target
widget ID is 0 then the select event is sent directly to the UA.
Cursor Control
Device
Button Press
Select Select
Select
Physical
Button Proxy Widget Button Widget
Button ID #3 ID #5
Link Button Link ID #5
ID #3
ARINC 661 UALD
A661_EVT_SELECTION
User
Application
Button Press
Select
A661_EVT_SELECTION
Physical Proxy
Button
Button ID #3 ID #0
Link Button
ID #3
ARINC 661 UALD
User
Application
Restrictions:
• The result of assigning more than one ProxyButton widget to a single key
will cause events to be sent to multiple widgets when that key is pressed
• If an undefined target widget ID is set the A661_ERR_SET_ABORTED
may be sent to the application
• If the ProxyButton is in a container or layer that is disabled or not visible
then the ProxyButton is disabled. When the ProxyButton is disabled, the
ProxyButton will not pass events from physical buttons
ARINC SPECIFICATION 661 - Page 191
3.0 WIDGET LIBRARY
This event indicates to the UA that a crew member has interacted with the widget.
3.5.3 WatchdogContainer
Categories:
Container
Description
The WatchdogContainer widget is a non-graphical container widget stimulated,
during normal operation, by the UA at a periodic rate. One or more widgets must
be placed into the container and the ShowIfFailIdent must be set to either zero or
the value of one of the widgets in the container. During normal operation, all of the
widgets within this container, except for the widget referenced with the
ShowIfFailIdent, are evaluated for display. If the UA fails to stimulate the Refresh
parameter in the Watchdog Container widget for FailCountLimit periods then the
watchdog is considered expired causing an event to be sent back to the UA and
causing the CDS to display the widget referenced by ShowIfFailIdent.
This widget is useful when used in combination with the BufferFormat widget to
assure that a data set is updated at a specific rate. The BufferFormat contains a
set of functionally related parameters and the “Refresh” parameter for a Watchdog
widget. If the BufferFormat is updated at the period defined by “TimePeriod” then
the timer is satisfied and no action is taken. If the “Refresh” is not set to true for
FailCountLimit periods, the timer expires and two actions are taken by the CDS:
• An event is sent back to the UA indicating that the timer has expired
• The Widget referenced by ShowIfFailIdent is evaluated for display. If the
Visible parameter of the child widget is True then the widget is displayed
If the UA starts setting the “Refresh” to true for “ValidCountLimit” periods, the
Watchdog is satisfied. When the Watchdog is satisfied the following actions are
taken by the CDS:
• An event is sent back to the UA indicating the watchdog is satisfied
• The widget referenced by ShowIfRefreshIdent is evaluated for display. If
the Visible parameter of the child widget is True then the widget is
displayed
The timer of a watchdog that is a child of another watchdog is still updated
regardless of the state of the parent watchdog.
ARINC SPECIFICATION 661 - Page 193
3.0 WIDGET LIBRARY
In the example below, the first picture shows a buffer format updating the
watchdog timer to display widget #12. The Refresh parameter is included in the
buffer format. The bottom picture shows the case when the buffer format is no
longer received by the CDS. In this case the fail indication in Widget #24 is
displayed.
UALD
BufferFormat
Watchdog
Param Param
1 2
... Refresh
ShowIf
Refresh FailIdent
#24
UALD
BufferFormat
Param Param Watchdog
1 2
... Refresh
ShowIf
Refresh FailIdent
#24
BasicContainer with
Watchdog is not refreshed by UA. Widget parameters that are
#24 referenced by ShowIfFailIdent is set by BufferFormat Fail Indication
evalutated for display by the CDS.
In the above example, the UA must set Refresh once every 50ms for the timer to
be satisfied. There are two inner states associated with the watchdog. They are
WatchdogExpired and WatchdogNormal. The CDS should evaluate the refresh
and timer counts once every 50ms as follows:
• When the state is W makes the ShowIfFailIdent widget visible. Every 50ms
(the TimePeriod) the CDS checks to see if the refresh has been updated by
the UA in the last 50ms. If the refresh is updated for 2 consecutive cycles
(100ms) then the CDS transitions to the WatchdogNormal state.
• When the state is WatchdogNormal. In the WatchdogNormal state the CDS
evaluates the other widgets for display. Every 50ms (the TimePeriod) the
CDS checks to see if Refresh has been updated by the UA in the last
50ms. If the refresh is not updated for 3 consecutive cycles (150ms) then
the CDS transitions to the WatchdogExpired state.atchdogExpired – In the
WatchdogExpired state the CDS.
The figure below shows a state transition diagram for the Watchdog Container.
With TimePeriod equal to 50ms, this State Transition Diagram would be evaluated
once every 50ms by the CDS. For the labels on the transitions the condition above
the line determines whether the transition is taken and the statement under the line
is the action taken if the transition occurs.
Watchdog
Normal
3.5.4 Slider
Categories:
• Graphical Representation
• Interactive
Description:
The mapping of the value-range to the slider depends on the orientation, for
example when the slider is horizontal the value-range can either be LEFT TO
RIGHT or RIGHT TO LEFT. The Orientation specifies direction of increasing
values.
When the UA sets the Value to something that is not a multiple of the LSB value
the behavior is implementation dependent
3.5.5 PictureAnimated
Categories:
Graphical representation
Description:
A PictureAnimated is a reference to a set of images available in the CDS. By
displaying this set of pictures successively at a frequency defined as a parameter
of the widget, the CDS performs an animation. It is possible to define if the
animation is performed only once then stopped or if it is an infinite loop. The UA
can stop the loop animation. The animation always stops on the first picture of the
list.
Restriction:
N/A
3.5.6 SymbolAnimated
Categories:
Graphical representation
Description
The SymbolAnimated widget is similar to the Symbol widget. It places vector
symbols predefined in the CDS at a specified location on the display. However, the
Symbol widget is static unless the controlling application changes widget
parameters, while the SymbolAnimated widget is animated by providing the ability
to automatically display a sequence of symbol references, rotation angles and
relative movements.
AnimationFlag allows the controlling application to start and stop the animation.
When the widget becomes visible and AnimationFlag is set to A661_DONT_RUN,
the first symbol reference, orientation, and movement parameters are used to
display the symbol. If AnimationFlag is A661_RUN_ONCE or A661_RUN when the
widget is set to visible, the animation begins. A661_RUN_ONCE will start the
animation and have the CDS stop it automatically once the animation sequence
has been completely displayed – to start over, AnimationFlag must be set to
A661_RUN_ONCE again. To show the animation continuously, AnimationFlag
should be set to A661_RUN and remain this value until the animation should stop,
at which time the value should be reset to A661_DONT_RUN.
3.5.7 SelectionListButton
Categories:
• Graphical representation
• Interactive
• Text string
Description:
The SelectionListButton is the same as the ComboBox except that a constant
LabelString is displayed instead of the selected value.
The SelectionListButton allows a crew member to select one entry within a list. A
fixed LabelString is displayed in the SelectionListButton area. The number of the
current selected entry is held in the SelectedEntry parameter. The complete list of
possible Entries is held in a string array (parameter EntryList). The list is displayed
upon crew member selection, for example, click on the arrow button associated
with the Selected Entry.
COMMENTARY
Restriction:
N/A
ARINC SPECIFICATION 661 - Page 205
3.0 WIDGET LIBRARY
4.1 Introduction
This section defines the type, content and format for ARINC 661 data to be
exchanged between a User Application (UA) and the Cockpit Display System (CDS).
This includes the type, content and format of the data. At definition time, a Definition
File (DF) is sent from UAs to the CDS. At run-time, messages are exchanged
between UAs and CDS.
One DF contains User Application Layer Definitions (UALDs) from one UA. The
UALD describes data shared between one UA and the CDS, as depicted in
Figure 4.1.
The DF header and footer are OEM dependent. The data between header and footer
are defined in this specification, and are composed of UALDs, using a block
structure defined later in this section. Each block (i.e., each UALD) contains the
definition of exactly one layer. Support for multiple blocks in a file is OEM dependent.
Each UA displaying data inside the CDS is associated with at least one layer. The
UALD describes the hierarchical structure of the UA widgets inside one layer as well
as the specific ARINC 661 interface parameters of these widgets. The format of a
block is described in Sections 3.0 and 4.5. The hierarchical structure of the widgets
is insured by the use of “ParentIdent” parameter in each widget definition.
For each type of widget, all parameters must have a CDS default value. If a
parameter is not set in the UALD, the CDS default value will be used. This will
happen in the case of run-time-only parameters, or in the case where a CDS library
definition has been updated to incorporate new parameters, but an older UALD is
not updated.
On one side, Figure 4-1 shows widgets “owned” by the UA (primarily, defines their
IDs) for display of information on CDS. This is the definition of the static graphical
part of the UA interface for one layer.
On the other side, Figure 4-1 shows that the CDS interprets the UALD data to
allocate and construct the hierarchical tree of widgets in conjunction with the CDS
widget library.
At run-time the CDS and UA exchange ARINC 661 messages to manage the widget
parameters, and thus their graphical representation.
The DF describes shared data. Therefore, one main objective of this specification is
to standardize the DF data and format shared between the UA and the CDS. The
graphical part of the application interface (DF) must be loaded into the CDS. This DF
describes only data, and is therefore interpreted by the CDS to be associated with
the CDS graphical capacities.
To limit the impact of one UA modification on the CDS, the data format loaded into
CDS should be independent from the CDS. Besides, as a growth potential, a data
ARINC SPECIFICATION 661 - Page 209
4.0 COMMUNICATION PROTOCOL
format independent from the CDS should provide the capability to UAs to download
their Definition Files (DF) into the CDS.
The format for the DF, allowing both data loading and downloading, is a standard
non-executable binary format.
Graphic Tool
for graphic interface definition
COMMENTARY
4.3.2 Issues
This Specification defines the principle of error notification to provide the tools to
manage errors in a command. Nevertheless it is outside the scope of this document
to define the recovery action on an error notification. The aircraft OEM should
specify only error recording in built-in test equipment (BITE), or some recovery
mechanism to implement specific errors.
The error notifications with commands in this specification are described in the Table
4.4.2. In addition to the error notification defined in response to an incorrect
command, the CDS should send an error notification to notify an overload.
ARINC SPECIFICATION 661 – Page 212
4.0 COMMUNICATION PROTOCOL
Because the level of CDS is the higher application, there is no need for exceptions
on commands from CDS to UA.
ARINC SPECIFICATION 661 - Page 213
4.0 COMMUNICATION PROTOCOL
Request from the UA to the CDS, described in Table 4.4.3.1, may or may not be
accepted by the CDS. This request should be sent to the CDS through
A661_CMD_UA_REQUEST command.
4.5.1 Notation
The structures detailed in Tables 4.5.3.1-2 and 4.5.4.1-1 are built so that a single
datum (excluding arrays) is never encoded across two 32-bit words. This simple
rule is emphasized for better understanding of the structure details.
According to A665, the data file will be a binary file with the extension XXX.LUP.
The 665 header file has the extension: XXX.LUH. The header file defines which
data file(s) are to be loaded.
It is recommended that only 1 data file be attached to the A665 header of a DF. In
this case the “Number of Data Files” (in A665 header) would be 1.
A Definition File (DF) may hold several User Application Layer Definitions (UALD)
from one UA, and also zero or more symbol definitions. The loadable entity is the
DF. Table 4.5.3.2-1 describes the structure of one DF.
A661_Reinitialize_Layer_Data_ Size
Structure Type (bits) Description
A661_NOTE_REINIT_LAYER_DATA ushort 16 Start keyword for opening the
reinitialize layer data structure.
UnusedPad N/A 16 0
ARINC SPECIFICATION 661 – Page 221
4.0 COMMUNICATION PROTOCOL
Section 3.0, Widget Library, provides a description for each widget that includes a
table of parameters modifiable at run-time. These tables contain the name of a
A661_ParameterStructure, which should be applied to set this parameter. This
section provides details of these structures.
4.5.45.1 A661_ParameterStructure_1Byte
4.5.4.5.2 A661_ParameterStructure_2Bytes
4.5.4.5.3 A661_ParameterStructure_4Bytes
4.5.4.5.4 A661_ParameterStructure_String
4.5.4.5.5 A661_ParameterStructure_StringArray
4.5.4.5.6 A661_StringArray_CellStructure
4.5.4.5.7 A661_ParameterStructure_EnableArray
4.5.4.5.8 A661_ParameterStructure_8Bytes
4.5.4.5.9 A661_ParameterStructure_BufferOfItems
4.5.4.5.10 A661_ParameterStructure_Buffer
4.5.4.5.11 A661_ParameterStructure_EntryPopUpArray
The following tables define numeric values associated with the ARINC 661
keywords:
A661_NOT_USED 0x00
A661_ITEM_STYLE 0x20
A661_LEGEND 0x21
A661_LEGEND_ANCHOR 0x22
A661_LEGEND_POP_UP 0x23
A661_LINE_ARC 0x24
A661_LINE_SEGMENT 0x25
A661_LINE_START 0x26
A661_SYMBOL_CIRCLE 0x27
A661_SYMBOL_GENERIC 0x28
A661_SYMBOL_ROTATED 0x29
A661_SYMBOL_RUNWAY 0x2A
A661_FILLED_POLY_START 0x2B
A661_SYMBOL_OVAL 0x2C
A661_BOTTOM_CENTER 0x30
A661_BOTTOM_LEFT 0x31
A661_BOTTOM_RIGHT 0x32
A661_TOP_CENTER 0x33
A661_TOP_LEFT 0x34
A661_TOP_RIGHT 0x35
A661_BOTTOM_TO_TOP 0x40
A661_LEFT_TO_RIGHT 0x41
A661_RIGHT_TO_LEFT 0x42
A661_TOP_TO_BOTTOM 0x43
A661_ITEM_SYNCHRONIZATION 0X51
ARINC SPECIFICATION 661 – Page 231
4.0 COMMUNICATION PROTOCOL
A661_LINE_ARC_INTERACTIVE 0xA4
A661_LINE_SEGMENT_INTERACTIVE 0xA5
A661_LINE_START_INTERACTIVE 0xA6
A661_SYMBOL_CIRCLE_INTERACTIVE 0xA7
A661_SYMBOL_GENERIC_INTERACTIVE 0xA8
A661_SYMBOL_ROTATED_INTERACTIVE 0xA9
A661_SYMBOL_RUNWAY_INTERACTIVE 0xAA
A661_FILLED_POLY_START_INTERACTIVE 0xAB
A661_SYMBOL_OVAL_INTERACTIVE 0xAC
A661_EDB_CHANGE_CONFIRMED 0x00
A661_EDB_ALL_CHANGE 0x01
A661_EDB_OPEN_CLOSE 0x02
On 16 bits
A661_STYLE_SET_DEFAULT 0x0000
ARINC SPECIFICATION 661 – Page 232
5.0 SYMBOL GRAPHICAL DEFINITION
5.1 Overview
The following scheme should be used to find the appropriate symbol for a given
symbol id number:
• If a Symbol with matching ID is found in the DF, use it
• Otherwise, use the predefined symbol with that id
In the case of the SYMBOL_GENERIC and SYMBOL_ROTATED map items, the
legend anchor command of a symbol defines the first legend position.
This section describes the Symbol Definition Commands that are used within the
Symbol Definition Structure to specify the graphical appearance of the symbol.
• See Section 4.5.3 for the format of the Definition Time structure in general,
and the Symbol Definitions Structure in particular
symbol_definition ::=
symbol_representation
[ FOCUS_Command symbol_representation ]
[ HIGHLIGHT_Command symbol_representation ]
symbol_representation ::=
{ symbol_attribute_command | symbol_graphic_primitive_command } +
The symbol attribute commands and symbol graphic primitive commands are
described in sections 5.2.2 and 5.2.3 respectively.
ARINC SPECIFICATION 661 – Page 233
5.0 SYMBOL GRAPHICAL DEFINITION
5.2.1.1 Focus
The FOCUS command identifies the beginning of the definition of the focus
representation of the symbol.
Field Name Type Size (bits) Description
SymbolCommandType ushort 16 A661_SYMBOL_DEFN_FOCUS
UnusedPad N/A 16
5.2.1.2 Highlight
The HIGHLIGHT command identifies the beginning of the definition of the highlight
representation of the symbol.
Field Name Type Size (bits) Description
SymbolCommandType ushort 16 A661_SYMBOL_DEFN_HIGHLIGHT
UnusedPad N/A 16
Symbol Attribute Setting Commands set graphical attributes (Color, Linestyle, Font,
Halo) that affect Graphic Primitive Commands.
The StyleSet and/or Color and/or Halo properties of the widget or Map Item that
references the symbol determine the initial attribute settings of each of the
representations of the symbol. Attribute setting commands (if any) made within a
representation of the symbol definition override those initial defaults. The attribute
setting commands made within a symbol definition only apply within the context of
that symbol: these settings cannot affect subsequent widgets (including other
symbols) or map items.
The SET_COLOR command sets the current color index, affecting the color of lines,
boundary lines and fills. It is an index into the same color table referenced by color
index properties of Gp widgets.
Field Name Type Size (bits) Description
SymbolCommandType ushort 16 A661_SYMBOL_DEFN _SET_COLOR
ColorIndex uchar 8 Index into a CDS-defined color table.
UnusedPad N/A 8
The SET_LINE_STYLE command sets (non-color) attributes that effect line (and line
segment) drawing: for example pattern and width. The style is an index into a line
style table stored on the CDS. Linestyle modulation is reset with every
SET_LINE_STYLE command.
Field Name Type Size (bits) Description
SymbolCommandType ushort 16 A661_SYMBOL_DEFN _SET_LINE_STYLE
Style ushort 16 Index into a CDS-defined line style table.
ARINC SPECIFICATION 661 – Page 234
5.0 SYMBOL GRAPHICAL DEFINITION
The SET_FONT command sets the current font to the given font index.
Field Name Type Size (bits) Description
SymbolCommandType ushort 16 A661_SYMBOL_DEFN _SET_FONT
Font uchar 8 Index into a CDS-defined font table.
UnusedPad N/A 8
This section describes symbol commands to define the graphic primitives that make
up a symbol.
All coordinate, height, width and radius arguments are in units of hundredths of mm.
All angles are in degrees and follow the rules specified in section 2.3.4.2, Angles.
The (0,0) position of the symbol represents the part of the symbol that will be placed
at the widget or map item’s position. Symbols are sensitive to rotation and/or
translations that are applied by ancestor widgets.
The LEGEND_ANCHOR command explicitly sets the anchor position for the legend
attached to the symbol representation. If there is more than one Legend Anchor
command, the behavior is OEM-dependent. If there is no LEGEND_ANCHOR
command within a symbol representation, the legend anchor position is (0,0). The
LEGEND_ANCHOR command does not correspond to any Gp widget.
Field Name Type Size (bits) Description
SymbolCommandType ushort 16 A661_SYMBOL_DEFN_LEGEND_ANCHOR
UnusedPad N/A 16
PosX long 32 The X position.
PosY long 32 The Y position.
The ARC_ELLIPSE command draws the same shape as the GpArcEllipse widget.
As in the GpArcEllipse widget, the ARC_ ELLIPSE becomes a complete ellipse or
circle when the StartAngle and EndAngle represent the minimum and maximum
ARINC SPECIFICATION 661 – Page 235
5.0 SYMBOL GRAPHICAL DEFINITION
possible values of a 32-bit fr(180), corresponding to –180 degrees and slightly less
than +180 degrees respectively.
The ARC_ ELLIPSE is drawn using the current color (in both the filled and unfilled
cases). If it is unfilled, the outline is drawn using the current linestyle.
Field Name Type Size (bits) Description
SymbolCommandType ushort 16 A661_SYMBOL_DEFN_ARC_ELLIPSE
Filled uchar 8 A661_TRUE
A661_FALSE
UnusedPad N/A 8
PosX long 32 The X start position of the bounding box
(lower left corner).
PosY long 32 The Y start position of the bounding box
(lower left corner).
SizeX ulong 32 The maximum width the ARC_ELLIPSE can
have (if its StartAngle and EndAngle defines
a full ellipse).
SizeY ulong 32 The maximum height the ARC_ELLIPSE can
have (if its StartAngle and EndAngle defines
a full ellipse).
StartAngle fr(180) 32 The angle (referenced from the center
position) that defines the start of the
ARC_ELLIPSE.
EndAngle fr(180) 32 The angle (referenced from the center
position) that defines the end of the
ARC_ELLIPSE.
The ARC_CIRCLE command draws the same shape as the GpArcCircle widget.
The following figure illustrates the two ARC_CIRCLE command cases, depending on
the Filled setting. The small circles are for reference purposes and indicate the circle
centers (they don’t actually get drawn). The ARC_CIRCLE is drawn using the current
color (in both the filled and unfilled cases). If it is unfilled, the outline is drawn using
the current linestyle.
ARINC SPECIFICATION 661 – Page 236
5.0 SYMBOL GRAPHICAL DEFINITION
5.2.3.4 Crown
A crown can be filled or unfilled (outlined). The following diagram shows an outlined
crown. The crown is drawn using the current color (in both the filled and unfilled
cases). If it is outlined, the outline is drawn using the current linestyle.
The CROWN command draws the same shape as the GpCrown widget.
5.2.3.5 Line
The LINE command draws a line between the two positions specified. The LINE is
drawn using the current color and linestyle. The LINE command draws the same
shape as the GpLine widget.
ARINC SPECIFICATION 661 – Page 237
5.0 SYMBOL GRAPHICAL DEFINITION
5.2.3.7 Polyline
The following figure shows an example of how an unclosed polyline defined using
vertices (V0 .. V5) could be defined. (When drawn, the polyline will not show the
(V0..V5) labels).
5.2.3.8 Rectangle
5.2.3.9 Triangle
The following figure shows how the Vertices (V0 ..V6) of a triangle fan define a filled
shape formed out of triangles. When drawn, a triangle fan does not draw the lines or
vertex labels shown in this figure. In this case it defines a concave polygon:
ARINC SPECIFICATION 661 – Page 239
5.0 SYMBOL GRAPHICAL DEFINITION
The following figure shows how the Vertices (V0 ..V5) of a triangle strip define a filled
shape formed out of triangles. When drawn, a triangle fan does not draw the lines or
vertex labels shown in this figure.
5.2.3.12 Text
The TEXT command defines a fixed text string that is part of symbol and is drawn
using the current font. The first character of the text string is placed at the specified
position and subsequent characters are drawn to the right. It is drawn using the
current color. The effect of current linestyle on Text for a particular font is OEM-
dependent. The TEXT command does not correspond to any Gp widget.
Field Name Type Size (bits) Description
SymbolCommandType ushort 16 A661_SYMBOL_DEFN _TEXT
Alignment uchar 8 specifies the alignment of the text with
respect to PosX and PosY.
TOP_LEFT
TOP_CENTER
TOP_RIGHT
LEFT
CENTER
RIGHT
BOTTOM_LEFT
BOTTOM_CENTER
BOTTOM_RIGHT
UnusedPad N/A 8
PosX long 32 The X position.
PosY long 32 The Y position.
RotationAngle fr(180) 32 Specifies rotation of text with respect to
PosX and PosY.
StringText string 8 * string length Null-terminated string, followed by zero,
+ pad one, two or three extra NULL for 32 bit
alignment.
ARINC SPECIFICATION 661 - Page 241
6.0 XML DEFINITION FILE SPECIFICATION
6.1 Introduction
This section describes how an ARINC 661 definition file is defined in XML format. It
is assumed that the reader is familiar with XML [1] and ARINC 661 widgets.
Since the XML DF can contain more information than a binary DF, a round-trip
conversion from an XML DF to a binary DF and back again could lose information.
The XML DF grammar description provided defines the core grammar subset. It
does not describe the full grammar because it is expected that OEM-specific XML
elements will also be added.
Contents:
6.2 Description
The following table describes a table format that is used in the remainder of this
section to describe each XML element:
ARINC SPECIFICATION 661 – Page 242
6.0 XML DEFINITION FILE SPECIFICATION
The following XML fragment gives an example of how model XML elements are
used to define properties. In it a model XML element specifies the parameter values
of a CheckButton widget:
<a661_widget name="CKB_CHOICE" type="A661_CHECK_BUTTON">
<model>
<prop name="WidgetId" value="2"/>
<prop name="Visible" value="A661_TRUE"/>
<prop name="Enable" value="A661_TRUE"/>
<prop name="CheckButtonState" value="A661_UNSELECTED"/>
<prop name="StyleSet" value="1"/>
<prop name="PosX" value="100"/>
<prop name="PosY" value="100"/>
<prop name="SizeX" value="3000"/>
<prop name="SizeY" value="900"/>
<prop name="FocusIndex" value="0"/>
<prop name="AutomaticFocusMotion" value="A661_FALSE"/>
<prop name="LabelSring" value="SELECT"/>
<prop name="MaxStringLength" value="7"/>
<prop name="Alignment" value="A661_LEFT"/>
<prop name="PicturePosition" value="A661_LEFT"/>
</model>
</a661_widget>
The following table describes the a661_df element, which is the root element of the
XML data. The following parts of this element provide information that is not found in
the binary DF:
name XML attribute.
XML Element a661_df
Description This is the root object of the XML data. It defines the entire DF.
XML Attributes • name (optional, string): this is the name of the DF. It
corresponds to the name of the file (not including file extension).
• library_version (required, unsigned char): this gives the
implementation dependent library version of the DF as found in
the binary DF header. Refer to section 4.5.3.2.
• supp_version (required, unsigned char): this gives the
supplement version of the DF as found in the binary DF header.
Refer to section 4.5.3.2.
Contains (in order) 1. A model element.
2. An optional symboltable element
3. One or more a661_layer elements
Properties • ApplicationId (unsigned short) : this is the identification number of
the user application associated with this DF. This information is
found in the binary DF header. Refer to section 4.5.3.2.
ARINC SPECIFICATION 661 - Page 243
6.0 XML DEFINITION FILE SPECIFICATION
This section describes XML elements related to Symbol Graphical Definitions that
are defined locally within the DF (see section 5 for more information on this topic).
XML Element symboltable
Description Defines a table of Symbol Graphical Definitions that are stored within the
DF.
XML Attributes None
Contains One or more symboldefn elements.
Properties None.
The following table describes the symboldefn XML element. The following parts of
this element provide information that is not found in the binary DF:
• name XML attribute.
XML Element symboldefn
Description Defines the graphical representation of a symbol.
XML Attributes name (optional) : a name for the symbol definition. This name might be
referenced elsewhere in the XML file instead of a numeric symbol id value.
Contains (in order) a required model element
required stdrepr element.
an optional focusrepr element
an optional highlightrepr element
Properties Id : an unsigned short value giving the id number of the symbol.
The following table describes the symboldefncmd XML element. The following
parts of this element provide information that is not found in the binary DF:
• name XML attribute.
XML Element symboldefncmd
Description Defines a symbol graphical definition command.
XML Attributes • name (optional) : this gives the symbol definition command
object a name. This name would be purely for descriptive
purposes, and would not be referenced elsewhere in the XML
file.
• type (required) : this gives the type of symbol graphical
definition command (e.g.
A661_SYMBOL_DEFN_ARC_ELLIPSE). Refer to section 5 for
the legal symbol graphical definition command types.
The following table describes the a661_layer XML element. The following aspects
of this element provide information that is not found in the binary DF:
• name XML Attribute
• Height property
• Width property
The following table describes the a661_widget XML element. The following aspects
of this element provide information that is not found in the binary DF:
6.2.3 Properties
If an object has a property, but its value is not specified within the model block, an
OEM-specific default value of that property should be used instead.
ARINC SPECIFICATION 661 – Page 246
6.0 XML DEFINITION FILE SPECIFICATION
This section describes the grammar in DTD format. In practice, the actual DTD used
may be a superset of this grammar, with OEM-specific XML elements added.
<!ELEMENT a661_df ( model, (symboltable)?, (a661_layer)+ )>
<!ATTLIST a661_df
name CDATA #IMPLIED
library_version CDATA #REQUIRED
supp_version CDATA #REQUIRED>
<!ATTLIST symboldefn
name CDATA #IMPLIED>
<!ATTLIST symboldefncmd
name CDATA #IMPLIED
type CDATA #REQUIRED>
<!ATTLIST a661_layer
name CDATA #IMPLIED>
<!ATTLIST a661_widget
name CDATA #IMPLIED
type CDATA #REQUIRED>
<!-- property value: the "name" attribute gives the name of the property.
-->
<!ATTLIST prop
name CDATA #REQUIRED
value CDATA #REQUIRED>
<!ATTLIST arrayprop
name CDATA #REQUIRED>
ARINC SPECIFICATION 661 – Page 250
6.0 XML DEFINITION FILE SPECIFICATION
<!-- structure field values: the "name" attribute gives the name
of the field.
field ........ the value is simple.
arrayfield ... the value is an array.
structfield .. the value is a structure.
-->
<!ATTLIST field
name CDATA #REQUIRED
value CDATA #REQUIRED>
<!ATTLIST arrayfield
name CDATA #REQUIRED>
<!ATTLIST structfield
name CDATA #REQUIRED>
-->
<!ATTLIST entry
value CDATA #REQUIRED>
<!ATTLIST xyentry
x CDATA #REQUIRED
y CDATA #REQUIRED>
6.4 References
1. "eXtensible Markup Language (XML)", a technical recommendation standard of the W3C. W3C
Consortium (www.w3c.org) , release 1.0, February 10th 1998
2. "XML Schema", a technical recommendation standard of the W3C Consortium (www.w3c.org) ,
release 1.0, May 2nd 2001
ARINC SPECIFICATION 661 – Page 251
APPENDIX A
GLOSSARY
Active Layer
When a layer is active, the CDS updates widget parameters of this layer (refer to
Section 2.3.2.4 – Layer Activity/Visibility Management).
Cursor
Visual indicator of the point of crew input on the screen.
Definition phase
Consists in loading of DF in the CDS, which specify the creation of widgets in order
to describe user application’s interface layouts. The instantiation (creation plus first
setting of all parameters) of widgets inside the CDS is part of the definition phase.
This will occur before the beginning of the run-time phase.
Disabled
State of an interactive widget when it does not react to crew-member activation.
Display
A non-specific term, generally meaning “thing you look at.” As a noun, “display”
refers to a physical assembly of metal and glass (Display Head), or to the pattern of
colored dots that appear on that glass (Format). As a verb, “display” refers to the act
of deciding which of those colored dots to light (render) or, loosely, to providing the
parameters necessary to be able to render.
Display Head
A physical assembly that can generate patterns of colored dots (raster) or lines
(stroke).
Event
Notification sent by the CDS to a UA to indicate a crew member interaction has
occurred on a widget owned by that UA.
Focus
State of a widget in which this widget receives the events triggered by a crew
member through a keyboard or other device, such as rotary wheels, except for the
cursor control device.
ARINC SPECIFICATION 661 - Page 252
APPENDIX A
GLOSSARY
Format
Format image rendered to the whole display unit surface. A format is constructed
from one or more windows
Highlight
A widget is highlighted when the cursor over-flies its interactive area. A click with the
cursor control device on an highlighted widget will bring the focus on this widget
(refer to Focus). Depending on the OEM choice, the click may also select the widget.
Inner state
Specific states of a widget. This state level represents the core of the widget
behavior as well as its functional objectives. Examples of inner states :
For a basic PushButton, there is one inner state.
For a CheckButton, there are two inner states, which are ‘SELECTED’ and
‘UNSELECTED’
Interactive
Category of widgets that can generate events in response to crew member activity
on input device(s).
Layer
Layers provide the mechanism to combine graphical information from several UAs
inside one window. For example, layers of the ND image include compass rose, map
with interactive way-points, TCAS information, terrain or weather display. A layer is
connected to a unique UA, whereas a UA can use several layers.
A layer is the higher level entity of the CDS that is known by the UA. From the UA
point of view, the Layer is the high level container in the hierarchical structure of the
UA widgets. From the CDS point of view, the layer is one graphical layer associated
with one UA inside a window. The layer layout within a window is beyond the scope
of this standard. Refer to Section 2.3.2, Layer Definition.
Mask
A graphical representation (a picture, typically a bitmap) used to implement non-
rectangular clipping. The exact format is CDS-specific. Typically, a Mask is a Picture
made up of only Black and Transparent elements.
Normal
Normal visual representation of the widget when it is visible, enabled, and not
selected.
Picture
A fixed image, stored in the CDS, referenced by an index, not rotatable.
ARINC SPECIFICATION 661 – Page 253
APPENDIX A
GLOSSARY
Race condition
Race condition occurs when there is a cross of messages between the CDS and a
UA concerning dynamic widgets. It can lead to some inconsistency between the UA
context and the CDS display.
Reference to …
The index or ID of something that has been loaded into the CDS.
Render
The act of combining software-code instructions, uploaded symbols and parameters
into a pattern of colored dots or lines on a display head.
Run-time phase
The run-time phase consists of dynamic data transfers between UAs and CDS using
ARINC 661 run-time commands.
Style guide
The style guide defined by the OEM should describe the Look & Feel (common
graphical characteristics and consistent behavior) inside the cockpit, and thus,
provide necessary information to UAs for their HMI interface design.
Symbol
A rotatable image, stored in the CDS, referenced by an index.
Visual representation
A widget is characterized by its inner states. One inner state covers several
graphical representations. The visual representation “state” is managed internal to
the CDS.
An example of visual representations for a Button follows:
Highlighted:
ON
Normal:
ON
Widget
Graphical-user interface, object between a crew member and the UAs. Widgets
belong to a Widget Library inside the CDS. A widget may (or not) be interactive (i.e.
ARINC SPECIFICATION 661 - Page 254
APPENDIX A
GLOSSARY
Window
A window defines a rectangular physical area of the display surface. A window
consists of one or more layers and is controlled by the CDS.
ARINC SPECIFICATION 661 – Page 255
APPENDIX B
ACRONYMS AND ABBREVIATIONS
DF Definition File
DU Display Unit
FM Flight Management
I/O Input/Output
ND Navigation Display
UA User Application
2D Two Dimensional
3D Three Dimensional
ARINC SPECIFICATION 661 – Page 257
APPENDIX C
EXAMPLE OF A DEFINITION FILE
The following UA example controls the cabin temperature using two interfaces:
1. The UA is connected to the aircraft environment with:
a. one input: a cabin temperature sensor
b. one output: an actuator for the heater system and cooler system
2. The UA is connected to the CDS with a ARINC 661 interface to display the
following format in a DU window:
Buttons increment or decrement a selected temperature for the cabin, indicated by the
small green pointer. The current cabin temperature is indicated by both the white arrow
and the digital readout.
The digital readout and its unit string are ARINC 661 labels (A661_LABEL).
All drawings are clipped inside an ARINC 661 panel container (A661_PANEL).
ARINC SPECIFICATION 661 – Page 258
APPENDIX C
EXAMPLE OF A DEFINITION FILE
Each widget is a node in a hierarchical structure defined in the DF. The tree for
Example C.1is:
end if
if ((selectedCabinTemp > minValue) and (BUTTON_PRESSED.id = DecreaseSelectTemp)) then
decrease(selectedCabinTemp);
end if
Actuator.heaterCommand = PIDcontroller (selectedCabinTemp);
angleValue = selectedCabinTemp * scaleFactor + offset;
setParameter(TemperatureSelectedPointer, RotationAngle, angleValue);
cockpitTemp = Sensor.cabinTemp
if IsValid(cockpitTemp) = True then
angleValue = cockpitTemp * scaleFactor + offset;
end if
setParameter(TemperatureIndicatedPointer, Visible, A661_TRUE);
setParameter(IncreaseSelectTemp, Enable, A661_TRUE);
setParameter(DecreaseSelectTemp, Enable, A661_TRUE);
else
setParameter(IndicatedTempDRO, LabelString, “---”);
setParameter(IndicatedTempDRO, StyleSet, A661_STYLE_SET_WARNING);
setParameter(TemperatureIndicatedPointer, Visible, A661_FALSE);
beginBlock();
setParameter(IncreaseSelectTemp, Enable, A661_FALSE);
setParameter(DecreaseSelectTemp, Enable, A661_FALSE);
endBlock();
end if
# Word 2
00000024 # BLOCK SIZE (= 36 bytes, words 1 – 9)
# Word 3
CA02 # A661_CMD_SET_PARAMETER
000C # COMMAND SIZE (= 12 bytes, words 3 - 5)
# Word 4
0000 # UNUSED PAD
4566 # WIDGET ID (IncreaseSelectTemp)
# Word 5
B180 # PARAMETER ID (A661_ENABLE)
0000 # VALUE (A661_FALSE)
# Word 6
CA02 # A661_CMD_SET_PARAMETER
000C # COMMAND SIZE (= 12 bytes, words 6 – 8)
# Word 7
0000 # UNUSED PAD
4567 # WIDGET ID (DecreaseSelectTemp)
# Word 8
B180 # PARAMETER ID (A661_ENABLE)
0000 # VALUE (A66_FALSE)
# Word 9
D0 # A661_END_BLOCK
000000 # UNUSED PAD
When a CCD click occurs on one of the buttons, the following message is sent from the CDS to
the UA:
# Word 1
B0 # A661_BEGIN_BLOCK
42 # LAYER ID
ARINC SPECIFICATION 661 – Page 260
APPENDIX C
EXAMPLE OF A DEFINITION FILE
# Word 2
00000018 # BLOCK SIZE (= 24 bytes, words 1 – 6)
# Word 3
CC01 # A661_NOTIFY_WIDGET_EVENT
000C # COMMAND SIZE (= 12 bytes, words 3 – 5)
# Word 4
4566 # WIDGET ID (IncreaseSelectTemp)
# Word 5
E060 # EVENT ID (A661_SELECTION)
0000 # UNUSED PAD
# Word 6
D0 # A661_END_BLOCK
000000 # UNUSED PAD
The UA then acknowledges the event by sending an acknowledgment back to the
CDS.
Section C.3 provides an example of a User Application Definition File (UADF) for the
cabin temperature UA, containing only one layer. Note: unit length of measure is 1/100
of millimeter.
# START DF
# Input file:
cabin_temperature.xml
# Hexadecimal # Comment
# Word 1
A661 # A661_DF_MAGIC_NUMBER
00 # A661 LIBRARY VERSION
02 # A661 SUPP VERSION
# Word 2
6788 # DF ID
0000 # SIZE OF OEM FREE DATA
# Word 3
A0 # A661_BEGIN_LAYER_BLOCK
42 # LAYER ID
1230 # CONTEXT NUMBER
# Word 4
0000013C # BLOCK SIZE (=316 bytes, words 3 – 81)
ARINC SPECIFICATION 661 – Page 261
APPENDIX C
EXAMPLE OF A DEFINITION FILE
# Word 81
C0 # A661_END_LAYER_BLOCK
000000 # UNUSED PAD
E0 # A661_DF_FOOTER
000000 # UNUSED PAD
# END DF
ARINC SPECIFICATION 661 – Page 265
APPENDIX C
EXAMPLE OF A DEFINITION FILE
For the application illustrated in Section C.3, the corresponding XML form of the DF
would be as follows. Refer to Section 6 for a description of the XML DF format. In this
example not all property values are given explicitly. The unspecified properties take
default values.
Note: the DOCTYPE specification is ad hoc. It requires that a file defining the DTD be
found in the current directory with the name “a661.dtd”.
<?xml version="1.0"?>
This is an XML file example that uses a wider range of property types. Refer to Section
6 for a description of the XML DF format.
Note: the DOCTYPE specification is adhoc: it requires that a file defining the DTD be
found in the current directory with the name “a661.dtd”.
<?xml version="1.0" encoding="UTF-8"?>
This section shows a binary Definition File that defines two symbols. See Section C.7
for an XML version of this example.
# Binary Definition File
# Example for ARINC-661 Specification
# Demonstrates how symbols and layers can be defined in
# a single binary definition file
A661 # A661_DF_MAGIC_NUMBER
02 # Library_Version
02 # Supp_Version
6788 # Application Identifier
0000 # UNUSED PAD
F0 # A661_BEGIN_SYMBOL_BLOCK
000000 # UNUSED PAD
00000076 # block size (118 bytes)
CA04 # A661_CMD_CREATE_SYMBOL
0030 # command size (48 bytes)
0064 # symbol ID (100)
0000 # UNUSED PAD
90D0 # A661_SYMBOL_DEFN_POLYLINE
0004 # number of vertices
01 # closed (A661_TRUE)
000000 # UNUSED PAD
FFFFFE0C # first X (-500)
FFFFFE0C # first Y (-500)
000001F4 # second X (500)
000001F4 # second Y (500)
FFFFFE0C # third X (-500)
000001F4 # third Y (500)
000001F4 # fourth X (500)
FFFFFE0C # fourth Y(-500)
CA04 # A661_CMD_CREATE_SYMBOL
003A # command size (58 bytes)
0065 # symbol ID (101)
0000 # UNUSED PAD
90B0 # A661_SYMBOL_DEFN_LINE
0000 # UNUSED PAD
00000000 # first X (0)
FFFFFC18 # first Y (-1000)
00000000 # second X (0)
FFFFFE0C # second Y (-500)
90F0 # A661_SYMBOL_DEFN_TRIANGLE
0000 # UNUSED PAD
00 # filled (A661_FALSE)
00 # UNUSED PAD
FFFFFF38 # first X (-200)
FFFFFE0C # first Y (-500)
00000000 # second X (0)
00000000 # second Y (0)
000000C8 # third X (200)
FFFFFE0C # third Y (-500)
F8 # A661_END_SYMBOL_BLOCK
000000 # UNUSED PAD
ARINC SPECIFICATION 661 – Page 270
APPENDIX C
EXAMPLE OF A DEFINITION FILE
A0 # A661_BEGIN_LAYER_BLOCK
05 # layer ID (5)
0000 # context number
CA01 # A661_CMD_CREATE
0020 # command size (32 bytes)
A1F0 # widget type (A661_PANEL)
1221 # widget ID
0000 # parent ID (zero indicates layer is parent)
01 # enable, value: A661_TRUE
01 # visible, value: A661_TRUE
00002AF8 # pos_x, value: 11000
0000319C # pos_y, value: 12700
00001DC4 # size_x, value: 7620
0000175A # size_y, value: 5978
0000 # style_set
0000 # UNUSED PAD
CA01 # A661_CMD_CREATE
0020 # command size (32 bytes)
A200 # widget type (A661_PICTURE)
1222 # widget ID
1221 # parent ID
00 # anonymous, value: A661_FALSE
01 # visible, value: A661_TRUE
000002EE # pos_x, value: 750
00000956 # pos_y, value: 2390
000017EE # size_x, value: 6126
000009BA # size_y, value: 2490
0000 # style set
9870 # picture reference
CA01 # A661_CMD_CREATE
0020 # command size (32 bytes)
A310 # widget type (A661_SYMBOL)
1223 # widget ID
1221 # parent ID
01 # motion allowed, value: A661_TRUE
01 # visible, value: A661_TRUE
00000EE2 # pos_x, value: 3810
00000956 # pos_y, value: 2390
0000238C # rotation angle, value: 9100
0001 # style set, value: OEM_STYLESET_FREE_COLOR
0065 # symbol reference
0F # color index, value: OEM_WHITE
000000 # UNUSED PAD
CA01 # A661_CMD_CREATE
0020 # command size (32 bytes)
A310 # widget type (A661_SYMBOL)
1224 # widget ID
1221 # parent ID
01 # motion allowed, value: A661_TRUE
01 # visible, value: A661_TRUE
00000D52 # pos_x, value: 3410
00000A82 # pos_y, value: 2690
0000071C # rotation angle, value: 1820
0001 # style set, value: OEM_STYLESET_FREE_COLOR
0064 # symbol reference
0F # color index, value: OEM_GREEN
000000 # UNUSED PAD
C0 # A661_END_LAYER_BLOCK
000000 # UNUSED PAD
E0 # A661_DF_FOOTER
000000 # UNUSED PAD
ARINC SPECIFICATION 661 – Page 271
APPENDIX C
EXAMPLE OF A DEFINITION FILE
This is the XML encoding of the example given in Section C.6. Refer to Section 6 for a
description of the XML DF format. The WidgetId values are provided in hex format in
this example. Both hex and decimal formats for unsigned integral values are allowed.
Note: the DOCTYPE specification is ad hoc. It requires that a file defining the DTD be
found in the current directory with the name “a661.dtd”.
<?xml version="1.0" encoding="UTF-8"?>
</symboldefncmd>
</stdrepr>
</symboldefn>
</symboltable>
<a661_layer name="SYMBOL_EXAMPLE_LAYER">
<model>
<prop name="LayerId" value="5"/>
<prop name="ContextNumber" value="0"/>
<prop name="Height" value="20000"/>
ARINC SPECIFICATION 661 – Page 272
APPENDIX C
EXAMPLE OF A DEFINITION FILE
<prop name="Width" value="20000"/>
</model>
<a661_widget name="Panel" type="A661_PANEL">
<model>
<prop name="WidgetId" value="0x1221" />
<prop name="PosX" value="11000" />
<prop name="PosY" value="12700" />
<prop name="SizeX" value="7620" />
<prop name="SizeY" value="5978" />
</model>
<a661_widget name="TemperatureCelciusScale" type="A661_PICTURE">
<model>
<prop name="WidgetId" value="0x1222" />
<prop name="PosX" value="750" />
<prop name="PosY" value="2390" />
<prop name="SizeX" value="6126" />
<prop name="SizeY" value="2490" />
<prop name="PictureRef"
value="SymbolTemperatureCelciusScale" />
</model>
</a661_widget>
<a661_widget name="Symbol1" type="A661_SYMBOL">
<model>
<prop name="WidgetId" value="0x1223" />
<prop name="PosX" value="3810" />
<prop name="PosY" value="2390" />
<prop name="RotationAngle" value="9100" />
<prop name="StyleSet" value="OEM_STYLESET_FREE_COLOR" />
<prop name="ColorIndex" value="OEM_WHITE" />
<prop name="SymbolReference" value="VertArrowSymbol" />
</model>
</a661_widget>
<a661_widget name="Symbol2" type="A661_SYMBOL">
<model>
<prop name="WidgetId" value="0x1224" />
<prop name="PosX" value="3410" />
<prop name="PosY" value="2690" />
<prop name="RotationAngle" value="1820" />
<prop name="StyleSet" value="OEM_STYLESET_FREE_COLOR" />
<prop name="ColorIndex" value="OEM_GREEN4" />
<prop name="SymbolReference" value="HourGlassSymbol" />
</model>
</a661_widget>
</a661_widget>
</a661_layer>
</a661_df>
ARINC SPECIFICATION 661 – Page 273
APPENDIX D
EXAMPLE OF "IN/OUT” WIDGET MANAGEMENT USING STYLESET PARAMETER
The inner states of an interactive widget are generally managed by the CDS upon crew
member interaction. When the CDS changes the state of a widget, it sends an event to
inform the UA of the interaction. In this case, the widget is considered as an IN widget.
If the UA wants to display its functional context though the interactive widget, the
widget is considered as an OUT widget. The widget is used to provide functional
information to the crew member. This information should be acknowledged by the
StyleSet parameter.
Unselected
Inner State
Option Option
Modification of the Widget State
by the CDS by crewmember interaction.
Inner State
Selected
event to the UA Option Option
• aircraft latitude
• aircraft longitude
ARINC SPECIFICATION 661 – Page 275
APPENDIX E
MAP MANAGEMENT TUTORIAL
Note that the same item number could be used once for a SYMBOL_GENERIC and
later for another type of MapItem. The CDS must have enough space for the number
of items specified using the biggest possible size of parameter list.
Another command would be provided to access multiple Items in one command. The
A661_ParameterStructure for the SetParameter command would look like the
following:
ARINC SPECIFICATION 661 – Page 276
APPENDIX E
MAP MANAGEMENT TUTORIAL
ItemIndex 20
EndFlag 0
ItemType A661_LINE_START
X Longitude
Y Latitude
} }
Note: The set Parameter command can contain a different type of MapItem.
A specific ItemType is A661_NOT_USED. The parameter list for thie item would be
reduced to the ItemType. This approach declares a previously used Item as not used
anymore without faking a type and setting its visibility to HIDE.
The Map UA should handle with care the functional data associated with the
dynamic widgets. Changing the functional information associated with a visible
widget could cause the race condition. An example of a typical race condition
follows:
• Pilot desire is to select PARIS waypoint
ARINC SPECIFICATION 661 – Page 277
APPENDIX E
MAP MANAGEMENT TUTORIAL
• At the time the pilot clicks PARIS waypoint, data is carried by the
MapHorz_ItemList identified by 201 and the Item 32
• CDS sends back the event “Widget 201, Item 32” selected
In the mean time, the FMS has changed the information associated with “Widget
201, Item 32,” which now carries “NEW YORK”.
The problem is that the FMS cannot decide what the event truly means: has the
pilot has selected PARIS or NEW YORK?
To address this problem, the FMS could have several solutions. One solution is to
manage the Context Number. The UA can change the Context Number by changing
the functional information attached to a widget or simply to an Item. In this way, the
FMS will have the knowledge of the selected waypoint by correlation between the
Context Number and the ident of the selected waypoint.
The Items inside a MapHorz_ItemList are defined at run-time. The order of the Item
inside the MapHorz_ItemList defines the drawing order of the items defined by the
ItemIndex parameter of the item. The Item with the highest ItemIndex has the
highest drawing priority. Figure E.4-1 illustrates an example of dynamic priority
management.
The UA induces a specific drawing order of symbology by ordering the item inside a
MapHorz_ItemList. If the UA does not specify the drawing order, then the drawing
order should be defined statically in the DF with different MapHorz_ItemList for the
set of symbols and drawing orders. Nevertheless, this different set of symbols
correspond to different functional sets, for which it should define a different widget
(MapHorz_ItemList).
However, the drawing priority of one Item is defined by the ItemIndex of this Item.
Nevertheless, the ItemIndex of one Item is independent og the transmitting order of
this Item in the command. In Figure E.4-1, the UA, for instance the FMS, may have
to respect a transmitting order. But the transmitting order is independent of the order
of the ItemIndex declaration inside the SetParameter command.
ARINC SPECIFICATION 661 – Page 278
APPENDIX E
MAP MANAGEMENT TUTORIAL
First
Data
Data for a FPLN leg
Low
MapItemList Data Index
,,,
DataBuffer for a FPLN leg 50
,,,
,,
DataBuffer for a FPLN Waypoint 200
High
SUPPLEMENT 1
TO
ARINC SPECIFICATION 661
3.3.2 BasicContainer
This section modified to state that some widgets can only be positioned at run-time.
Supplement 1 supports the definition of the position of an optional panel at run-time.
The objective is to define a position, not to move the widget at run-time.
3.3.5 CheckButton
This section modified to define the label alignment on button. The definition of the
LabelPosition parameter is clarified. This parameter can be replaced by
“PicturePosition” to be coherent with PictureXxxxButton.
3.3.6 ComboBox
This section modified to define the label alignment on button.
3.3.9 EditBoxMasked
This section updated for clarity. The UA cannot change the EditBoxState into the edit
mode through the EditBoxState parameter. The UA must request the Focus on the
EditBox. When an EditBox reports all changes are completed and a crew member
cancels the modifications, the display should annunciate an aborted event.
Descriptive paragraph added. EditBoxState parameter deleted. Type of
ReportAllChanges changed from Boolean to Enumeration. STATE_CHANGE event
deleted. ABORTED event added.
3.3.10 EditBoxNumeric
This section updated for clarity. The UA cannot change the EditBoxState into the edit
mode through the EditBoxState parameter. The UA must request the Focus on the
EditBox. When an EditBox reports all changes are completed and a crew member
cancels the modifications, the display should annunciate an aborted event.
Descriptive paragraph added. EditBoxState parameter deleted. Type of
ReportAllChanges changed from Boolean to enumeration. STATE_CHANGE event
deleted. ABORTED event added. Parameters NumericKeyFlag, MinValue,
MaxValue and CyclicFlag are added. TicsCoarse and TicsFine are not modifiable at
run-time.
3.3.11 EditBoxText
This section updated for clarity. The UA cannot change the EditBoxState into the edit
mode through the EditBoxState parameter. The UA must request the Focus on the
EditBox. When an EditBox reports all changes are completed and a crew member
cancels the modifications, the display should annunciate an aborted event.
Descriptive paragraph added. EditBoxState parameter deleted. Type of
SUPPLEMENT 1 TO ARINC SPECIFICATION 661 – Page 3
3.3.20 Label
Changed “static” to “anonymous”. Deleted references to “blink” capability. Added
“ColorIndex” parameter. Added additional Alignment value definitions.
3.3.21 LabelComplex
Added additional Alignment value definitions.
3.3.22.2.1.12 FilledPolyStart
This section added.
3.3.22.2.1.13 SymbolOval
This section added.
3.3.23 MapLegacy
Parameter “FormatType” changed to “ChannelID”. All references to ARINC 702 and
ARINC 708 were removed. This makes MapLegacy consistent in description and
operation to ExternalSource widget.
3.3.24 MapHorz_Source
MapSource changed to MapHorz_Source. Table of MapDataFormat valued added
for clarity. “A661_EVT_SELECTION” changed to “A661_EVT_SELECTION_MAP”.
3.3.25 MapHorz
This section modified to support map display. Map Widget changed to MapHorz.
Description of “PRP Lat/Lng” identified as Commentary. Description of “Orientation”
updated for clarity. Screen Reference Point X/Y changed from ulong to long.
3.3.28 PicturePushButton
Alignment parameter added.
SUPPLEMENT 1 TO ARINC SPECIFICATION 661 – Page 4
3.3.29 PictureToggleButton
Alignment parameter added.
3.3.30 PopUpPanel
AutomaticClosure parameter added.
3.3.31 PopUpMenu
Replace “UAPositionFlag” by “OpeningMode”, because an UA may want to open a
menu UP or DOWN.
3.3.32 PopUpMenuButton
It is necessary to define the label alignment on button. Replace “UAPositionFlag” by
“OpeningMode”, because an UA may want to open a menu UP or DOWN.
3.3.33 PushButton
It is necessary to define the label alignment on button.
3.3.34 RadioBox
Updated to say that a user application may need to display a RadioBox without any
selected element (for example, in the disable state).
3.3.36 ScrollPanel
HorizontalScroll and VerticalScroll modified to cover all possibilities,
Absent/Up/Bottom/Left/right. For operational reasons, it might be necessary to place
vertical and horizontal scroll at the same place. It is easier for a crew member to
manage the scroll buttons.
3.3.37 ScrollList
It is necessary to define the label alignment on button.
3.3.38 Symbol
Category does not include “interactive”. This category was deleted.
3.3.39 TabbedPanel
It is necessary to define the label alignment on button. The UA managing a
TabbedPanel (or a set of TabbedPanel) may need to define inset size. To introduce
this functionality and keep the segregation between the TabbedPanel and the
TabbedPanelGroup, new parameters were added. For Tabbed Panel, the “InsetSize”
parameter is added. For TabbedPanelGroup, the “AutomaticInsetSizeFlag”
parameter is added. This flag allows the choice between the manual inset size using
“InsetSize” parameter or an inset size defined by a display dependent algorithm.
3.3.40 TabbedPanelGroup
The UA managing a TabbedPanel, or set of TabbedPanel, may need to define inset
size. To introduce this functionality and to keep the segregation between
TabbedPanel and the TabbedPanelGroup, new parameters were added. For Tabbed
Panel, the “InsetSize” parameter is added. For TabbedPanelGroup, the
“AutomaticInsetSizeFlag” parameter is added. This flag selects between the manual
SUPPLEMENT 1 TO ARINC SPECIFICATION 661 – Page 5
3.3.41 ToggleButton
It is necessary to define the label alignment on button.
3.4.1 MapGrid
This section added. New Widget is defined.
3.4.2 ExternalSource
This section added. New Widget is defined.
3.4.3 MapVert
This section added. New Widget is defined.
3.4.4 MapVert_Source
This section added. New Widget is defined.
3.4.5 MapVert_ItemList
This section added. New Widget is defined.
3.4.6 EditBoXMultiLine
This section added. New widget is defined.
3.4.7 ComboBoxEdit
This section added. New widget is defined.
3.4.8 MenuBar
This section added. New widget is defined.
SUPPLEMENT 2
TO
ARINC SPECIFICATION 661
0.0 Global Changes to Widgets and Data Structures Used in ARINC 661
The pad bits used within the data structures were modified to follow existing
conventions more consistently.
The FocusIndex attribute was replaced by NextFocusWidget
ParameterStructure_XY was replaced by ParameterStructure_8Bytes
3. WatchdogContainer widget
4. Slider widget
5. PictureAnimated widget
6. SymbolAnimated widget
7. SelectionListButton widget
3.2.2 Widgets Classification
Table 3.2.2-2 was updated to support the widget expansion in Supplement 2.
3.3.1 ActiveArea
A parameter was modified to include the identity of the widget to focus upon.
3.3.2 BasicContainer
Runtime parameters PosX and PosY were defined to be 8 bytes.
3.3.4 BufferFormat
The restrictions on BufferOf Parameter were modified.
3.3.4.1 A661_ParameterStructure_Buffer
This section was expanded to provide additional detail.
3.3.5 CheckButton
A parameter was modified to include the identity of the widget to focus upon.
3.3.6 ComboBox
This section was modified to add new OpeningEntry parameter. A parameter was
modified to include the identity of the widget to focus upon.
3.3.9 EditBoxMasked
An EntryValidation parameter was added. This would clarify use of alpha and
numeric characters.
3.3.10 EditBoxNumeric
The FormatString parameter was changed to be run-time modifiable. New
MaxFormatStringLength parameter was added. Events reported by this widget were
updated.
SUPPLEMENT 2 TO ARINC SPECIFICATION 661 – Page 3
3.3.11 EditBoxText
FormatString parameter was changed to be run-time modifiable. New
MaxFormatStringLength parameter was added. Events reported by this widget were
updated. New parameters StartCursorPos and LegendString were added.
3.3.13 GpArcCircle
Runtime parameters PosX and PosY were defined to be 8 bytes. UnusedPad were
changed from 8 bits to 16 bits for proper alignment.
3.3.14 GpCrown
Runtime parameters PosX and PosY were defined to be 8 bytes.
3.3.15 GpLine
Runtime parameters PosX and PosY were defined to be 8 bytes.
3.3.16 GpLinePolar
Runtime parameters PosX and PosY were defined to be 8 bytes.
3.3.17 GpRectangle
Runtime parameters PosX and PosY were defined to be 8 bytes.
3.3.18 GpTriangle
Runtime parameters PosX and PosY were defined to be 8 bytes.
3.3.22.2.1.6 Line_Arc
This section was updated to clarify the description of InboundCourse and
CourseChange angles.
3.3.22.2.1.14 Item_Synchronization
A new MapItem type was added.
3.3.24 MapHorz_Source
The EventFlag parameter was modified to support scroll wheels. A column was
added to Table 3.3.24-2b to show direction of positive orientation for angles
(clockwise or counter-clockwise).
SUPPLEMENT 2 TO ARINC SPECIFICATION 661 – Page 4
3.3.25 Map_Horz
A new event was defined for Item Synchronization.
3.3.28 PicturePushButton
A parameter was modified to include the identity of the widget to focus upon.
3.3.29 PictureToggleButton
A parameter was modified to include the identity of the widget to focus upon.
3.3.30 PopUpPanel
A restriction was removed. PopUpPanels can be nested.
3.3.31 PopUpMenu
PictureArray was added as run-time modifiable parameter in Table 3.3.31-4.
3.3.32 PopUpMenuButton
A parameter was modified to include the identity of the widget to focus upon. The
PictureArray parameter was added
3.3.33 PushButton
A parameter was modified to include the identity of the widget to focus upon.
3.3.34 RadioBox
Restrictions were removed from this widget.
3.3.35 RotationContainer
The Enable parameter was deleted as it does not apply to this widget
3.3.36 ScrollPanel
The Horizontal Scroll parameter was modified to include Top/Bottom scroll. The
Vertical Scroll parameter was modified to include Left/Right scroll.
3.3.37 ScrollList
The EnableArray parameter was added.
3.3.39 TabbedPanel
A parameter was modified to include the identity of the widget to focus upon.
3.3.41 ToggleButton
A parameter was modified to include the identity of the widget to focus upon.
3.3.42 TranslationContainer
The Enable parameter was deleted as it does not apply to this widget. Runtime
parameters TranslationX and TranslationY were defined to be 8 bytes.
SUPPLEMENT 2 TO ARINC SPECIFICATION 661 – Page 5
3.4.1 MapGrid
The description of MapGrid parameters, IncrementX and IncrementY, were modified
in Table 3.4.1-1. The changes would distinguish between distance-distance on a
rectangular grid versus true bearing-distance grid used with weather radar. Support
for various MapDataFormat values would be implementation dependent.
3.4.3 MapVert
Vertical display capability is included for terrain profile and other applications. A new
event was defined for Item Synchronization. This would ensure that weather radar
display and terrain display would be synchronized with aircraft position. Parameters
RangeX and RangeY were retained.
3.4.4 MapVert_Source
The MapDataFormat parameter described in Table 3.4.4-2b was modified to allow
the origin of the map to be an absolute geometric point or a point relative to a
geometric reference point. A clarification was made to the use of different
MapDataFormats in this widget.
3.4.5 MapVert_ItemList
Item Synchronization was added to Table 3.4.5.1-1.
3.4.5.2.1.10 Item_Synchronization
New Section added.
3.4.5.2.11 Symbol_Rotated
New Section added.
3.4.6 EditBoxMultiline
Changes made to event reporting of this widget.
3.4.7 ComboBoxEdit
A parameter was modified to include the identity of the widget to focus upon.
Changes made to event reporting and entry validation.
4.5.1 Notation
Notation was corrected to specify [<A>] means zero or one of [<A>].
4.5.4.5.7 A661_Parameter_Structure_EnableArray
This section was added to support new widgets.
SUPPLEMENT 2 TO ARINC SPECIFICATION 661 – Page 7
1. Document Title
ARINC Specification 661-2: Cockpit Display System Interfaces
Published: June 30, 2005
2. Reference
Page Number: Section Number: Date of Submission:
3. Error
(Reproduce the material in error, as it appears in the standard.)
4. Recommended Correction
(Reproduce the correction as it would appear in the corrected version of the material.)
6. Submitter (Optional)
(Name, organization, contact information, e.g., phone, email address.)
Note: Items 2-5 may be repeated for additional errata. All recommendations will be evaluated by
the staff. Any substantive changes will require submission to the relevant subcommittee for
incorporation into a subsequent supplement.
19_APIM-VerJ.doc Page 1
ARINC Project Initiation/Modification
07/06/05
The committee staff will endeavor to process APIMs and present them to the
appropriate Committee at its next available meeting. The Committee will then
evaluate the proposal. Evaluation criteria will include:
• Airline support – number and strength of airline support for the project,
including whether or not an airline chairman has been identified
• Issues – what technical, programmatic, or competitive issues are
addressed by the project, what problem will be solved
• Schedule – what regulatory, aircraft development or modification,
airline equipment upgrade, or other projected events drive the urgency
for this project
Accepted proposals will be assigned to a subcommittee for action with one of two
priorities:
• High Priority – technical solution needed as rapidly as possible
• Routine Priority – technical solution to proceed at a normal pace
Proposals may have designated coordination with other groups. This means that
the final work must be coordinated with the designated group(s) prior to submittal
for adoption consideration.
Proposals that are not accepted may be classified as follows:
• Deferred for later consideration - the project is not deemed of sufficient
urgency to be placed on the current calendar of activities but will be
reconsidered at a later date
• Deferred to a subcommittee for refinement – the subcommittee will be
requested to, for example, gain stronger airline support or resolve
architectural issues
• Rejected – the proposal is not seen as being appropriate, e.g., out of
scope of the committee
3. APIM Template
The following is an annotated outline for the APIM. Proposal initiators are
requested to fill in all fields as completely as possible, replacing the italicized
explanations in each section with information as available. Fields that cannot be
completed may be left blank. When using the Word file version of the following
template, update the header and footer to identify the project.
19_APIM-VerJ.doc Page 2
ARINC Project Initiation/Modification
07/06/05
19_APIM-VerJ.doc Page 3
ARINC Project Initiation/Modification
07/06/05
19_APIM-VerJ.doc Page 4