A

MULTI-PURPOSE CONTROL
AND DISPLAY UNIT

ARINC CHARACTERISTIC 739A-1

PUBLISHED: DECEMBER 16, 1998

AN A DOCUMENT
Prepared by
AIRLINES ELECTRONIC ENGINEERING COMMITTEE
Published by
AERONAUTICAL RADIO, INC.
2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401
 Copyright 1998 by
AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 24101-7465 USA

ARINC CHARACTERISTIC 739A-1

MULTI-PURPOSE CONTROL AND DISPLAY UNIT

Published: December 16, 1998

Prepared by the Airlines Electronic Engineering Committee

Characteristic 739A Adopted by the Airlines Electronic Engineering Committee: October 22, 1996
Characteristic 739A Adopted by the Industry: December 10, 1996

Summary of Document Supplements

Supplement Adoption Date Published

Characteristic 739A-1 October 26, 1998 December 16, 1998

A description of the changes introduced by each supplement is included on goldenrod paper at the end of this document.
 FOREWORD
Activities of AERONAUTICAL RADIO, INC. (ARINC)
and the
Purpose of ARINC Characteristics

Aeronautical Radio, Inc. is a corporation in which the United States scheduled airlines are the
principal stockholders. Other stockholders include a variety of other air transport companies, aircraft
manufacturers and non-U.S. airlines.

Activities of ARINC include the operation of an extensive system of domestic and overseas
aeronautical land radio stations, the fulfillment of systems requirements to accomplish ground and
airborne compatibility, the allocation and assignment of frequencies to meet those needs, the
coordination incident to standard airborne compatibility, the allocation and assignment of frequencies
to meet those needs, the coordination incident to standard airborne communications and electronics
systems and the exchange of technical information. ARINC sponsors the Airlines Electronic
Engineering Committee (AEEC), composed of airline technical personnel. The AEEC formulates
standards for electronic equipment and systems for the airlines. The establishment of Equipment
Characteristics is a principal function of this Committee.

An ARINC Equipment Characteristic is finalized after investigation and coordination with the
airlines who have a requirement or anticipate a requirement, with other aircraft operators, with the
Military services having similar requirements, and with the equipment manufacturers. It is released as
an ARINC Equipment Characteristic only when the interested airline companies are in general
agreement. Such a release does not commit any airline or ARINC to purchase equipment so described
nor does it establish or indicate recognition of the existence of an operational requirement for such
equipment, not does it constitute endorsement of any manufacturer’s product designed or built to meet
the Characteristic. An ARINC Characteristic has a twofold purpose, which is:

(1) To indicate to the prospective manufacturers of airline electronic equipment the

considered opinion of the airline technical people, coordinated on an industry basis,
concerning requisites of new equipment, and

(2) To channel new equipment designs in a direction which can result in the maximum
possible standardization of those physical and electrical characteristics which influence
interchangeability of equipment without seriously hampering engineering initiative.

ii
 ARINC CHARACTERISTIC 739A
TABLE OF CONTENTS

ITEM SUBJECT PAGE

1.0 INTRODUCTION AND DESCRIPTION 1

1.1 Purpose of This Document 1
1.2 Functions 1
1.3 System Description 1
1.4 Interchangeability 1
1.4.1 General 1
1.4.2 Interchangeability Desired for the ARINC 739A MCDU 1
1.4.3 “Generation Interchangeability” Consideration 1
1.5 Regulatory Approval 2
1.6 Relationship to ARINC 739 2

2.0 INTERCHANGEABILITY STANDARDS 3

2.1 Introduction 3
2.2 Form Factor 3
2.3 Environmental Conditions 3
2.4 Interwiring 3
2.5 Thermal Interface and Design 3
2.6 Power Circuitry 3
2.6.1 Primary Power Input 3
2.6.2 Power Control Circuitry 4
2.6.3 The Common Ground 4
2.6.4 The AC Common Cold 4
2.7 Weights 4
2.8 Grounding and Bonding 4

3.0 MCDU DESCRIPTION 5

3.1 General 5
3.2 Display 5
3.3 Keyboard 5
3.3.1 Basic Function Keys 5
3.3.2 Specific Function Keys 5
3.3.3 Alpha-Numeric Keys 5
3.3.4 Panel Illumination and Annunciator Lights 5
3.4 MCDU Operation and Display 6
3.4.1 Typical MCDU Initiation 6
3.4.2 MCDU Menu 6
3.4.3 Subsystem Specific Menu 7
3.4.4 Non-Menu Operation 7
3.4.5 Scratchpad and Data Field Entry 7
3.4.6 Clearing Data Fields 7
3.4.7 Exiting 7
3.4.8 Proposed Philosophy to Menu Stepping 7
3.5 MCDU Outputs 8
3.6 MCDU Inputs 8
3.7 System Communication 8
3.7.1 Subsystem and MCDU Identification 8
3.7.2 Menu Generation 8
3.7.2.1 Initial Menu 8
3.7.2.1.1 Addressing and Responses 8
3.7.2.1.2 Protocol Timing and Responses 9
3.7.2.2 Menu Changes 9
3.7.2.3 Alternate Menu Display 9
3.7.3 Data Communication 10
3.7.3.1 Subsystem Initiated Messages 10
3.7.3.1.1 Subsystems Not Currently Active 10
3.7.3.1.2 Active Subsystems 10
3.7.3.2 MCDU Communication with Inactive Subsystem and Data Request 10
3.7.3.3 Message Transfer 10
3.7.3.4 Control (CNTRL) Word 11
3.7.3.5 Data Word 11
3.7.3.6 Background/Vector Words 11
3.7.3.7 Discrete Word 11
3.7.3.8 Button Push Word 12

iii
 ARINC CHARACTERISTIC 739A
TABLE OF CONTENTS (cont’d)

ITEM SUBJECT PAGE

3.0 MCDU DESCRIPTION (cont’d)

3.8 Built-In Test Equipment (BITE) 12
3.8.1 BITE Considerations 12
3.8.2 BITE Display 12
3.8.3 Self-Test 12
3.9 Electronic Flight Instrument System Interface 12
3.9.1 MCDU Outputs to EFI 12
3.9.2 MCDU Inputs from EFI 12
3.9.3 MCDU Map Inputs from FMC 12
3.9.4 Flight Plans and Guidance 12
3.9.5 Map Display Edit Area 12
3.9.6 Background Data Prioritizing 12
3.9.7 Data Type Word Formats 13
3.9.8 Flight Plan Retention 13

4.0 NAVIGATION AND DISPLAY CONTROL 14

4.1 Introduction 14
4.2 Functional Requirements 14
4.2.1 System Selection and Control 14
4.2.2 Navigation Radio Tuning 14
4.2.2.1 Mode Selection 14
4.2.2.2 General Operation 14
4.2.2.3 Navigation Tuning Page Functions 14
4.2.2.3.1 Tuning Inhibit 15
4.2.2.4 Interface Requirements 15
4.2.3 Standby Navigation 15
4.2.3.1 Mode Selection 15
4.2.3.2 Operation 15
4.2.3.2.1 General 15
4.2.3.2.2 Navigation and Guidance 15
4.2.3.2.3 CDU Page Access 15
4.2.3.2.4 Navigation Computations 16
4.2.3.2.5 Map Display 16
4.2.3.3 Interface Requirement 16
4.2.4 Alternate EFIS Control 17
4.2.4.1 General 17
4.2.4.2 Page Access 17
4.2.4.3 Interface 17
4.2.5 Alternate EICAS Control 17
4.2.5.1 General 17
4.2.5.2 Page Access 17
4.2.5.3 Interface 17
4.2.6 System Communication 18
4.2.6.1 Inter-system 18
4.3 Hardware Requirements 18
4.3.1 General 18
4.3.2 Interwiring Definition 18
4.4 Standby Navigation Lateral Guidance 18

ATTACHMENTS

1 Standard Interwiring 19
2 Address Labels 22
3 Digital Word Formats 23
4 Character Code Assignments (Derived from ISO #5) 28
5 Environmental Test Categories 29
6 Typical System Configuration 30
7 Typical Front Panel Layout 31
8 Glossary 32
9 Optional MCDU Functions 33
10 MCDU Display Considerations 34

iv

1.0 INTRODUCTION AND DESCRIPTION
1.1 Purpose of This Document
This document sets forth the desired characteristics of a
Multi-Purpose Control and Display Unit (MCDU)
intended for installation in commercial transport aircraft.
The intent of this document is to provide general and
specific design guidance for the development of the
MCDU. It describes the desired operational capability of
the equipment and the standards necessary to ensure
interchangeability.
Equipment manufacturers should note that this document
encourages them to produce maintenance-free, high
performance equipment rather than that of minimum
weight and size. They are at liberty to accomplish this
objective by means of the techniques they consider to be
the most appropriate. Their airline customers are
interested primarily in the end result rather than the
means employed to achieve it.
Avionics systems optimization can be achieved on board
modern aircraft by minimizing the cost, weight and size
of avionics. The use of one or more MCDUs will
contribute to this goal.
By the use of identical MCDUs, the specific control and
display units for ACARS/CMU, AIDS, CFDS and other
systems can be eliminated. There would be substantial
savings due to:
a. Elimination of CDU spares
b. Simplification of cockpit
c. Easier crew operation training (common procedures)
d. Flexibility to accommodate other systems (e.g.,
SATCOM, Mode S, etc.)
e. MCDU can be applicable to any aircraft.
1.2 Functions
The MCDU is expected to communicate with multiple
systems one at a time (equivalent to multi-purpose
switch). System selection is by use of keys on the MCDU
(dedicated keys or by menu item key) and is achieved by
sending different user system address labels on a common
output command data bus. See Attachment 6.
The MCDU should provide means for manually selecting
subsystems connected and for inserting system control
parameters and modes of operation. In addition, it should
provide display capability for various subsystems outputs
as well as for the verification of data entered into
memory. Certain annunciations related to system
operation may also be included.
Providing that the standardized protocols and message
structures are used, the MCDU can be used with any
system regardless of application. It is therefore truly
multi-purpose.
ARINC CHARACTERISTIC 739A - Page 1
1.3 System Description
As a minimum, the MCDU should contain the circuitry
and processing necessary to accept alpha-numeric
message codes and display them on the screen, and
circuitry for transmitting command codes relating to line
keys or keyboard keys. Data communication is
determined by standard protocols and message formats,
within the selected system.
The structure and content of messages, menus and
interpretation of commands is carried out by software in
the user system and not in the MCDU.
1.4 Interchangeability
1.4.1 General
One of the primary functions of an ARINC Equipment
Characteristic is to designate, in addition to certain
performance parameters, the interchangeability desired of
aircraft equipment produced by various manufacturers.
The manufacturer is referred to Section 1.6 of ARINC
Report 414 for definitions of Terms and General
Requirements for the airline industry for
interchangeability. As explained in that report, the degree
of interchangeability considered necessary and attainable
for each particular equipment is specified in the pertinent
ARINC Equipment Characteristic.
1.4.2 Interchangeability Desired for the ARINC 739A
MCDU
Unit interchangeability is desired for the MCDU
regardless of manufacturing source. The physical
attributes, the electrical interfaces and operation of the
MCDU were defined to accommodate application to a
wide variety of avionics. The standards necessary to
achieve this level of interchangeability are set forth in this
Characteristic.
1.4.3 “Generation Interchangeability” Considerations
In defining the equipment described in this Characteristic,
the air transport industry has chosen to depart from
several of its previous control function standards. In
order to achieve the full benefit of the economies offered
by these changes, the industry desires that no provisions
be made in this equipment for backward compatibility
with earlier generations of equipment.
Unchanged, however, is the industry's traditional desire
that future evolutionary equipment improvements and the
inclusion of additional functions in new equipment in the
next few years do not violate the interwiring and form
factor standards set forth in this document. Provisions to
ensure forward-looking “generation interchangeability”
(as best can be predicted) are included in this document
to guide manufacturers in future developments.
 ARINC CHARACTERISTIC 739A - Page 2
1.0 INTRODUCTION AND DESCRIPTION (cont’d)
1.5 Regulatory Approval
The MCDU should meet all applicable FCC and FAA
regulatory requirements. Manufacturers are urged to
obtain all necessary information from the FAA and the
FCC on such regulatory approval. This information is not
contained in this Characteristic, nor is it available from
ARINC.
1.6 Relationship to ARINC 739
This document was developed from ARINC
Characteristic 739, “Multi-Purpose Control and Display
Unit”, originally developed to support the installation of
MCDUs in FMS-equipped airplanes. This document
builds on the ARINC 739 philosophy and includes
several capabilities viewed to be necessary to satisfy
airline desires for CNS/ATM equipment installations in
their existing fleets of airplanes. The ARINC 739A
MCDU retains the same textual man-machine interface
conceived for the ARINC 739 unit. This documents
c-1 includes new material describing:

Dedicated Function Select Key

GNSS Interface

Optional Smaller Form Factor

28 Vdc Power Connection

MCDU Display Considerations

Dual Subsystem Considerations


2.0 INTERCHANGEABILITY STANDARDS
2.1 Introduction
This section sets forth the specific form factor, mounting
provisions, interwiring, input and output interfaces and
power supply characteristics desired for the Multi-
Purpose Control and Display Unit. These standards are
necessary to ensure the continued independent design and
development of both the equipment and the airframe
installations.
Manufacturers should note that although this
Characteristic does not preclude the use of standards
different from those set forth herein, the practical
problems of redesigning a standard airframe installation
to accommodate a special equipment could make the use
of that equipment prohibitively expensive for the
customer. They should recognize, therefore, the practical
advantages of developing equipment in accordance with
the standards set forth in this document.
2.2 Form Factor
The MCDU should be packaged as a standard dzus-
mounted control panel 9.0 inches high by 5.75 inches
wide. The depth behind the panel should not exceed 10.5
inches, excluding the connector.
An alternative form factor intended to support installation
in older aircraft, should be packaged as a standard dzus-
mounted control panel 7.125 inches high by 5.75 inches
wide. The depth behind the panel should not exceed 6.0
inches, excluding the connector.
A connector type MS 24264R 20 B 41PN should be used
having pin assignments shown in Attachment 1.
When the optional navigation and display control
functions are included in the MCDU, a second connector
type MS 24264 20 B 41P6 should be used.
c-1
COMMENTARY
Cost, weight, and electrical power consumption
reduction may be achieved by developing a smaller
and simpler MCDU. Use of flat screen technology
will undoubtedly allow design of smaller units. Thus,
equipment manufacturers may offer MCDUs of
lesser dimensions. However, certain attributes such
as screen size and required keys should be
maintained.
The SAE S-7 Flight Deck and Handling Qualities
Subcommittee has expressed concern with the notion
of smaller form factor MCDUs. Manufacturers are
encouraged to consider human factor implications
resulting from a reduction in keyboard, character or
display sizes.
General Aviation (GA) may require smaller form
factors.
2.3 Environmental Conditions
The MCDU should be specified environmentally in terms
of the requirements of RTCA Document DO-160,
“Environmental Conditions and Test Procedures for
Airborne Equipment”. Attachment 5 to this
ARINC CHARACTERISTIC 739A - Page 3
Characteristic tabulates the relevant environmental
categories.
2.4 Interwiring
The standard interwiring for the MCDU is set forth in
Attachment 1 to this Characteristic. This interwiring is
designed to provide the degree of interchangeability
specified in Section 1.4. The equipment manufacturer is
cautioned not to rely upon special wires, cabling or
shielding for use with his particular units because they
will not exist in the standard installation.
COMMENTARY
Why Standardize Interwiring?
The standardized interwiring is perhaps the heart of
all ARINC Characteristics. It is this feature which
allows the airline customer to complete his
negotiation with the airframe manufacturer so that
the latter can proceed with installation engineering
and initial fabrication prior to airline commitment on
a special source of equipment. This provides the
equipment manufacturer with many valuable months
in which to put final “polish” on his equipment in
development.
2.5 Thermal Interface and Design
The internal power dissipation of the MCDU should not
exceed 92 watts. The MCDU cooling and thermal design
should be in accordance with ARINC Specification 408A,
Sections 2.3, 3.6 and 3.10. These sections define case
temperature limits, the equipment cooling method, the
thermal appraisal procedure and expected high
temperature exposure conditions which should be
considered for the equipment design. However, it may be
desirable (and may be imperative for some installations)
that the equipment be designed for passive cooling.
COMMENTARY
ARINC Specification 408A defines the standard
interface between the aircraft and indicators;
however, the thermal interface described should also
be applied to the MCDU.
2.6 Power Circuitry
2.6.1 Primary Power Input
The MCDU should be designed to use 115 volt 400 Hz
single phase power from a system designed for Category
(A) utilization equipment per ARINC Specification
413A. Optionally the equipment may be designed to
operate with 28Vdc. Manufacturers should determine the
most appropriate power source for each installation.
The primary power input to the MCDU should be
protected by a circuit breaker of the size shown in
Attachment 1 to this Characteristic.
NOTE: Airframe installation designers should verify that
ARINC CHARACTERISTIC 739A - Page 4
2.0 INTERCHANGEABILITY STANDARDS (cont’d)
the aircraft power systems satisfy the primary power
interruption criteria of ARINC Specification 413A.
2.6.2 Power Control Circuitry

There should be no master on/off power switching within

the CDU. Any user desiring on/off control should
provide, through the medium of an external switching
function installed in the airframe, a means of interrupting
the primary ac power to the system.
2.6.3 The Common Ground
The wire connected to the MCDU connector pin labelled
“Chassis Ground” should be employed as the dc ground
return to aircraft structure. It is not intended as a
common return for circuits carrying heavy ac currents,
and equipment manufacturers should design their
equipment accordingly.

2.6.4 The AC Common Cold

The wire connected to the MCDU connector pin labelled
“115 Vac Cold” should be grounded to the same structure
that provides the dc chassis ground but at a separate
ground stud. Airframe manufacturers are advised to keep
ac ground wires as short as practicable in order to
minimize noise pick-up and radiation.

2.7 Weights

System manufacturers should take note of the guidance

information on weights contained in ARINC
Specification 600.

2.8 Grounding and Bonding

The attention of equipment and airframe manufacturers is

drawn to the material in Section 3.2.4 of ARINC
Specification 600 and Appendix 2 of ARINC
Specification 404A on the subject of equipment
grounding and bonding.
COMMENTARY

A perennial problem for the airlines is the location

and repair of airframe ground connections whose
resistances have risen as the airframe ages. A high
resistance ground usually manifests itself as a system
problem that resists all usual approaches to
rectification, and invariably consumes a wholly
unreasonable amount of time and effort on the part
of maintenance personnel to fix. Airframe
manufacturers are urged, therefore, to pay close
attention to assuring the longevity of ground
connections. Close attention to the above-referenced
specification material should be their first step.

3.0 MCDU DESCRIPTION
3.1 General
The Multi-Purpose Control and Display Unit (MCDU)
should comprise a keyboard and a display with associated
line select keys as described in the following sections.
The MCDU should contain all the electronic circuitry,
etc., required to display all specified input/output
parameters, and should provide all necessary controls for
complete operation of the systems.
COMMENTARY
The MCDU display should provide sufficient data
display space to provide efficient, yet uncluttered,
display of all data required for the mode or function
selected.
3.2 Display
In general, the MCDU display should be adequate in size
to provide the greatest amount of information to flight
crew without needless clutter. The top line of the display
should be the title line describing the page contents. The
remaining lines should be arranged so as to provide ease
in reading the display. The bottom line of the display
should be used as the “scratch pad” for entering data.
Line keys should be provided on either side of the display
in order to support menu driven functions. Section 3.4
describes a typical MCDU display. As an option MCDU
designers may consider the use of color displays in order
to enhance readability. Additional considerations for
display and operation are provided in Attachment 10.
3.3 Keyboard
The MCDU keyboard should include the following:
a. Basic function keys
b. Specific function keys
c. Alpha keys
d. Numeric keys
e. Annunciators
All keys should provide tactile feedback to the operator
to indicate a contact has been made.
3.3.1 Basic Function Keys
A “MCDU MENU” key should be provided to return the
MCDU to the main subsystem menu.
A “CLEAR” key should be provided to clear the
information displayed in the “scratch pad”.
ARINC CHARACTERISTIC 739A - Page 5
As a minimum, a “NEXT PAGE” pushbutton should be
provided to advance the display. User systems are
expected to design their display formats such that use of
the “NEXT PAGE” key is the only specific key function
required for its operation as it may be the only key
guaranteed on some MCDUs. A depression of “NEXT
PAGE”, when the last page is being displayed, should
cause the MCDU to return to the first page. As an
alternative, line keys can be used to select basic
functions.
COMMENTARY
Although a “PREVIOUS PAGE” button is not
specifically called out in this Characteristic, a
dedicated button for this purpose appears to have
merit particularly when more than three pages are
being accessed by the MCDU. A “PREVIOUS
PAGE” key code has been assigned in this
Characteristic in order that manufacturers can
provide this option if they so desire.
Similarly, slewing keys are considered optional.
However, not all avionics connected to the MCDU
will be able to slew text up or down on the display.
Pressing the slew key, if provided, would have no
effect when these avionics are communicating with
the MCDU.
3.3.2 Specific Function Keys
Up to thirteen specific-function keys may be provided on
the MCDU to accommodate special functions on some
avionics (e.g., flight management computer/GN(L)U). At
a minimum, one of these keys should be programmable as
to which user it is dedicated. Selection of a dedicated
function key should result in the immediate display of the
functional page from the defined user system. This
implies automatic activation of the defined user and
deactivation of the prior active user.
COMMENTARY
Thirteen specific function key codes have been
assigned in this Characteristic. However, it should
not be misconstrued as industry support for these
“dedicated” keys on the MCDU. Their use by
avionics burdens the MCDU by cluttering its front
panel and essentially preempts its desired role as a
truly flexible multi-purpose CDU. Dedicated
function keys should only be used when rapid access
to a function is deemed important.
3.3.3 Alpha-Numeric Keys
A full set of alphanumeric keys should be provided on the
MCDU. The MCDU should have the capability to
support the available key codes illustrated in Attachment
4.
COMMENTARY
The provision for a “space” key is optional. The
“space” key is desired for ACARS and other “free
text” applications. The SAE S-7 Committee has
found that the space key is necessary for enhancing
readability of free text applications.
ARINC CHARACTERISTIC 739A - Page 6
3.0 MCDU DESCRIPTION (cont’d)
3.3.4 Panel Illumination and Annunciator Lights
The MCDU should be integrally lighted and be powered
by the 5 volt panel light dimmer bus. The annunciator
light brightness control should be accommodated by a 5
volt supply. The MCDU should accommodate both ac
and dc light sources.
COMMENTARY
Separate panel light and annunciator light pins have
been assigned to accommodate separate control. The
panel lights would be connected to the normal 5 volt
power source use for instrument panel lighting.
Two different methods to vary annunciator brightness
are commonly used. The first uses fixed dc ground
on the “LO” side and varies the voltage (up to 5 Vdc)
on the “HI” side. The other uses a fixed 5 Vdc on the
“HI” side and varies the voltage in the “LO” side (0
Vdc for full brightness). Adequate isolation of the
annunciator lights should be provided in the MCDU
to accommodate both methods.
An annunciation may be provided to alert the operator
that a subsystem is waiting to send a message. An
“FMC” annunciator could be dedicated to ports #1 and
#2, and a general “call” or “MCDU Menu” annunciator
could be provided to alert the operator for the lower
priority (#3-#7) ports.
COMMENTARY
The MCDU integration with an aircraft flight deck
may result in the need for equivalent but different
methods of providing the annunciations. For
example in the case where there is a centralized crew
indication and alerting system, each subsystem may
be required to produce a distinct indication to the
flightcrew via the indicating and alerting system as
the attention getting mechanism. This indication
could be produced via a separate digital data
interface or analog discrete interface.
A lamp test input from the master control should be
provided where necessary.
3.4 MCDU Operation and Display
The following sections describe typical MCDU operation
and display based on a front panel layout as shown in
Attachment 7. The preferred display should contain
fourteen lines, each having twenty-four characters. The
top line (line 1) should normally be used as a title line to
the display data to which the operator does not have
access.
The bottom line (line 14) should be the “scratch pad” line
for entering data. Columns 23 and 24 of the title line and
of the scratch pad line may be used as an option for
“Slew” indications. Lines 2 through 13 should be data
lines arranged into six pairs. The six line keys on each
side of the display should be adjacent to the odd data
lines. When selection by way of line key is anticipated
the symbols (< left, > right) should be used as activation
symbols and should be displayed either at the first
character position if a left line key is used or at the
twenty-fourth character position if right line key is used.
If more than one page is involved the sending system
should display a “more to come” symbol for the next
page. The 23rd and 24th characters of the first line
should be used for “more to come” symbol display.
When slewing is used, up and down arrows should
indicate that vertical slewing is available. They should
appear in columns 23 and 24 in the scratch pad.
Variations of the procedure may occur according to
display and keyboard presentation used by different
manufacturers.
Additional considerations for MCDU displays are
provided in Attachment 10.
3.4.1 Typical MCDU Initiation
As described in Section 3.7.2.1, the MCDU after Power-
Up would normally display the “first page” of the highest
priority subsystem. This would typically be a menu of the
subsystem functions. Selection of functions on subsystem
“pages” is described in the following sections.
3.4.2 MCDU Menu
To communicate with a subsystem other than the one
currently active, the operator should push the “MCDU
MENU” button. This should result in the presentation of
a list of all subsystems connected to the MCDU. Likewise
single key access may be provided by selection of
dedicated function keys without the need to use the menu
page.
The MCDU should generate subsystem status adjacent to
the subsystem menu text (i.e., after the system name).
The current active system should be annunciated by
“Active” or equivalent being displayed near or after the
subsystem name. Any other subsystems having sent a
“Request To Send” to the MCDU should be annunciated
by “Req” or equivalent near or after the subsystem name.
The operator should press the line key to establish
communications with the desired subsystem.
COMMENTARY
Historically, the MENU page subsystem selection
operation has taken two forms:
a. If no line key is pressed within 60 seconds after
the MCDU Menu is displayed, the MCDU should
revert to the active subsystem display, if there is
an active subsystem, otherwise it should display
an appropriate time-out page.
b. Once the MENU page is selected for display, the
MCDU should remain on the MENU page until a

3.0 MCDU DESCRIPTION (cont’d)
selection is made. If the active system is selected
on the menu, the last active subsystem page
display should return. In this case, the subsystem,
though not visible, is expected to compute current
information as appropriate for the display. If the
menu selection results in a changeover to a new
active subsystem, the MCDU displays the
subsystem’s initial page or menu as appropriate.
Following selection of a subsystem, an indication should
be provided to inform the operator that the selection of
the subsystem is acknowledged. Typical methods would
be to erase all other subsystems from the menu or color,
blink or highlight the selected subsystem.5
COMMENTARY
Occasionally there could be the inadvertent push of a
line key which has no function. There has been
some desire expressed to “blink” the display for a
short period simply to let the operator know that a
button push was recognized. MCDU manufacturers
are urged to consider this function in their design.
When communication has been established with a
subsystem, the “first page” as transmitted by the
subsystem should be displayed to the operator.
If communication is not established within the maximum
time stated in Section 3.7.3.2, a “Time-out” indication
should be provided by the MCDU and an instruction
should be displayed to the operator to press the “MCDU
MENU” key.
3.4.3 Subsystem Specific Menu
The first page of a subsystem menu should be a menu of
functions which may include the capability to select a
c-1 particular unit in a dual subsystem installation to be the
primary, “master”, or operational unit. Selection of a
menu item by the operator should result in an indication
to operator that the input was recognized as described in
Section 3.4.2.
3.4.4 Non-Menu Operation
Non-menu display pages sent by the subsystem could
contain data or requests for action from the operator.
When data or other inputs are needed by the subsystem,
they should be entered by the alphanumeric keyboard.
See Section 3.4.5 for the procedure.
3.4.5 Scratchpad and Data Field Entry
The following describes the typical procedure for
entering data into the MCDU:
Data should be entered through the MCDU keyboard.
The data should be entered from left to right into the
scratchpad by pressing the alphanumeric keys on the
keyboard. After entry of the data into the scratchpad, the
data can be moved from the scratchpad into the correct
data field by pressing the adjacent line select key. The
system should check the data for format and acceptability
(out of range, entry not allowed into the field, etc.). An
ability to move rapidly through multiple lines of data is
ARINC CHARACTERISTIC 739A - Page 7
necessary.
In situations where the available field does not
accommodate a scratchpad entry, an appropriate message
should be displayed on the MCDU.
If the data is incorrect, the system should leave the
previous data in the data field and display the associated
message indicating the error in the scratchpad. To enter
the correct data, the operator should clear the message
from the scratchpad. To clear the scratchpad of entered
data or incorrect data, the “Clear” key can be used. One
press of the key should erase the last character entered in
the scratchpad. If the key is held down for two seconds
the entire scratchpad should be cleared of any data.
NOTE: Normally all twenty-four characters of the line
can be used. If slewing indications (arrows) are
used then only twenty-two message characters
are available per line.
Whenever the MCDU is waiting for a response from a
subsystem or is in a situation which could be ambiguous
to the operator, an appropriate message should be
displayed in the scratchpad line.
3.4.6 Clearing Data Fields
Data fields on the MCDU can be cleared using the “CLR”
key. Pressing the “CLR” key when the scratchpad is
empty should result in “CLR” being displayed in the
scratchpad. If a “DEL” key exists then it would be used
to clear data fields. Then, pressing the line select key
adjacent to the data field should result in clearing that
data and “Clear/Delete” is removed from the scratchpad.
Not all data fields may be cleared.
3.4.7 Exiting
The operator can exit from communication with a
subsystem by pushing the “MCDU MENU” button and
selecting another subsystem or by pressing a special
function key for a different subsystem, which should
cause the MCDU to perform the sequence described in
Section 3.7.3.2.
3.4.8 Proposed Philosophy to Menu Stepping
The general philosophy is that the avionics subsystem
connected to the MCDU manages the stepping forwards
and backwards through the sequence of menus.
COMMENTARY
It is very important to standardize the chosen word
for backing into previous menus. The most used in
today’s applications is generally “RETURN”. Any
connected system should allocate a line key for the
“RETURN” control. Therefore, there is no need for
a specific function key on the MCDU key board.
“INDEX” is also typically used for returning to
original information. Although it may be
commonplace, use of “RETURN” is recommended
instead to minimize the potential for confusion.
 ARINC CHARACTERISTIC 739A - Page 8
3.0 MCDU DESCRIPTION (cont’d)
3.5 MCDU Outputs
The MCDU should have a single output port to provide
its own identification and commands to the individual
subsystems communicating through the MCDU using
thirty-two bit words as defined in ARINC Specification
429, “Digital Information Transfer System (DITS)”. The
words transmitted by the MCDU should include MCDU
identification (octal label 377), Discrete Word #1 (octal
label 270) Maintenance Word #1 (octal label 350) and all
words identified by “SAL” in bits 1-8. See Attachment 3
for word formats. Maintenance Word #1 data format is
not defined specifically and can be used as the MCDU
manufacturer desires.
3.6 MCDU Inputs
3.6.1 Seven Basic Input Ports
The MCDU should provide seven input ports as defined
by ARINC Specification 429 for receiving identification
information and display data from individual subsystems.
Ports #1 and #2 should operate at the high-speed rate
(100 Kb/s) and ports #3 and #4 should operate at the low-
speed rate (12-14.5 Kb/s). The ports should have
priorities with the highest for #1 and the lowest for #7.
The data words listed in Attachment 3 identified with
MAL in bits 1-8 should be recognized by the MCDU. It
should also recognize the word identified by label 172 as
the subsystem identifier.
COMMENTARY
The flight management computer would normally be
connected to ports #1 and #2. Communications with
a flight management computer is expected to be
“generic”. In other words, when an MCDU is
communicating with a flight management computer,
it would be through the port designated by the
program pin status as described in Note 2 of
c-1 Attachment 1. When this Characteristic refers to the
highest priority port (normally #1) and the pin
programming has selected port #2, then port #2
should be considered the highest priority port.
3.6.2 Additional Subsystem Input Ports
The MCDU may optionally provide additional ARINC
429 input ports for receiving identification information
and display data from either a second unit in a dual unit
subsystem installation, or from other individual
subsystems. These ports may be used to provide MCDU
menu selections for additional single-unit subsystems, or
may be associated with the subsystems on ports #3
through #7, to create port pairs (e.g., 3A/3B, 4A/4B) to
provide a single MCDU menu selection for control of
dual-unit subsystems as described in Section 3.6.3.
An equivalent number of input discretes may be provided
to be used either as program pins to indicate to the
MCDU that a particular port pair will handle a dual-unit
or subsystem or as a discrete whose state indicates the
active unit in a dual-unit subsystem. Further guidance
appears in Section 3.6.3.
COMMENTARY
It is desirable to have a common MCDU part number
that can operate on multiple airplane models within
an airline fleet. For older aircraft that do not have
common MCDU dual subsystem switching
configurations, it is possible to program the various
switching configurations into the MCDU software
and use one or more of the unreserved discrete inputs
as program pins to identify the aircraft model.
3.6.3 MCDU Interfaces Involving Dual Subsystem
Devices
Dual subsystems should consider the following guidelines
when controlled by a MCDU.
COMMENTARY
In addition to dual FMC or GNLU installations,
other subsystems such as SATCOM and CMU may
be installed as dual subsystems. There are a variety
of techniques used in current aircraft installations and
MCDU designs for subsystem displays for these dual
device subsystems. These include dedicating separate
MCDU input ports and line select keys to each
subsystem device or using aircraft wiring-based
switching to select between the similar devices, then
routing the selected unit to a single port and line
select key on the MCDU. Although the use of two
line select keys for a dual subsystem provides a
simple implementation, using this approach with dual
subsystems depletes the number of MCDU menu
prompt locations available. This is not desirable from c-1
a flight crew operations viewpoint. Aircraft wiring-
based switching reduces the dual subsystem inputs to
a single MCDU input port. However, this is
undesirable due to design complexity, introduction of
new cockpit switching controls, and introduction of a
single point failure potential (the switching device).
Although implementation of additional input ports
and related discrete inputs and software support is
optional, MCDU manufacturers should be prepared
to handle exposure to multiple subsystem devices
such as dual SATCOM, dual CMU, and other
possible dual subsystems. It is intended that these
additional ports be used for this purpose, as
necessary, in conjunction with associated discrete
inputs, if applicable.
Port pairs may be assigned in the software and use
automatic detection of the master or active unit (for
example, presence or absence of subsystem label 172, or
of the master/slave bit 17 in label 172). In this case, no
associated input discrete is required.
Port pairs may be assigned in the software and use an
input discrete to determine the master or active unit.
Typically, this discrete would be controlled by aircraft
switching.
Two ports may be operated either as single subsystem
inputs or as a port pair depending on the state of an input
discrete or “program pin”. In this case, if the program pin
indicates a port pair, then determination of the master or
active unit will most likely use automatic detection or be
controlled manually on the subsystem menu page.

3.0 MCDU DESCRIPTION (cont’d)
COMMENTARY
Manufacturers should carefully consider the potential
for subsystem failure modes if the automatic
detection of master or active unit is selected. For
example, if neither unit in a dual unit subsystem
declared itself to be the master or active unit, then
pilot access may be denied. This method of
determining the master or active unit may be more
appropriate only for lower priority and/or non-
essential subsystems.
Attachment 10, MCDU Display Considerations,
provides guidance for subsystem-generated menu
pages when dual subsystem devices are installed.
3.7 System Communication
Communication between the MCDU and the avionics
subsystems should be accomplished by serial digital data
transmission described in ARINC Specification 429.
Specific system interconnection and data transfer protocol
are described below. See Attachment 2 for MCDU
Address Labels (MALs), Attachment 3 for Word Formats
and ARINC Specification 429 for System Address Labels
(SALs).
These sections describe the MCDU digital protocol as it
relates to the initialization data for subsystem interfaces
with the MCDU (Section 3.7.1), generation of the MCDU
MENU page display (Section 3.7.2), and non-MENU
communication with active or inactive systems (Section
3.7.3).
3.7.1 Subsystem and MCDU Identification
The MCDU should monitor its ARINC 429 input ports
from the aircraft subsystems and decode the 32-bit word
identified by octal label 172. This word will contain the
System Address Label (SAL) of the avionics in bits 9-16
and will be transmitted at approximately one second
intervals. See Attachment 3 for word layout.
The MCDU should transmit its MCDU address label
(MAL) to an aircraft subsystem using the subsystems
SAL in the address field of the “ENQ” word. The
specific data communication sequence should be as
described in the following sections. See Attachment 3 for
the “ENQ” word layout.
3.7.2 Menu Generation
3.7.2.1 Initial Menu
The MCDU should attempt to obtain the text for the
MCDU menu from the subsystems. The maximum text
length should be 18 characters, with the exception
described in Section 3.7.2.3.
Subsystems on the MCDU menu should be listed in order
by port number. If a port does not respond properly or is
not active, a space should be left in the menu list. NOTE:
when FMCs/GN(L)Us are connected to ports #1 and #2
only a single FMC/GN(L)U menu should be shown since
only one FMC/GN(L)U would be active at a time.
ARINC CHARACTERISTIC 739A - Page 9
3.7.2.1.1 Addressing and Responses
Upon power-up the MCDU should attempt
communication with aircraft subsystems after a delay
period of thirteen seconds.
COMMENTARY
The delay was defined to allow aircraft subsystems
to execute BITE routines and other functions
associated with their initiation upon power-up. Ten
seconds is considered adequate time for the
subsystems to stabilize and three additional seconds
to start sending their System Address Label (SAL)
identification (label 172) to the MCDU.
This Characteristic does not attempt to specify the
actual sequence in which the MCDU will start initial
menu interrogation of the individual subsystems.
Depending on internal circuitry, different MCDUs
could interrogate them sequentially. If a sequential
method is used, it is recommended that the highest
priority port be interrogated first in order that the
“first page” of the priority subsystem can be
displayed as soon as possible.
The MCDU should monitor the input ports for words
identified by octal label 172 and determine the subsystem
SAL therein. After receiving the valid word, the MCDU
should send an “ENQ” command coded for a Menu Text
Request and with the label field set to the subsystem
SAL A “Request to Send (RTS)” with the MCDU’s MAL
in the label field and coded for Menu Text Request
would be the normal response of the subsystem. The
MCDU should respond with a “Clear-To-Send (CTS)”.
The subsystem and MCDU’s RTS and CTS responses
should be as defined in the communication protocol
described in Section 3.7.3.2 of this Characteristic.
Communication with the subsystem should continue with
data words and an end-of-transmission word until the
menu text has been determined by the MCDU.
If the initial communication with the highest priority port
(#1, or #2 as determined by the program pin) is
successful, then the MCDU should send another “ENQ”
word as soon as possible coded for “normal”
communications with the priority subsystem as described
in Section 3.7.3.2. The “first page” of the highest priority
subsystem should be presented on the MCDU display
after “normal” communication has occurred.
COMMENTARY
The original version of ARINC Characteristic 739
defined bits 17-24 of the RTS word to be set to zero.
Supplement 1 to ARINC 739 defines bits 17-20 to
be used to distinguish between a response to a
normal request and menu text request (see
Attachment 3). All MCDUs designed to conform
with ARINC Characteristic 739A should encode the
RTS word accordingly.
The preferred implementation of the RTS word is the
version specified by this Characteristic. MCDU
manufacturers should exercise caution as some
subsystems have defined their protocol using the
ARINC CHARACTERISTIC 739A - Page 10
3.0 MCDU DESCRIPTION (cont’d)
3.7.2.1.1 Addressing and Responses (cont’d)
COMMENTARY (cont’d)
original version of the RTS word defined in ARINC
Characteristic 739.
If after thirteen seconds “normal” communications has
not been established for ports #1 or #2, then “normal”
communications should be attempted for the next highest
priority port that had completed the menu text
interrogation successfully. If after one additional second,
“normal” communications cannot be established with that
system, the next highest priority system should be
attempted. This procedure should be repeated until
“normal” communications has been established with a
subsystem.
3.7.2.1.2 Protocol Timing and Responses
During initial menu text interrogation, if on an input port
a word with label 172 is received by the MCDU, but the
3.7.2.1.2 Protocol Timing and Responses
subsystem fails to respond with an “RTS” within one
second after the MCDU sends the initial “ENQ”, then a
second “ENQ” should be sent. If unsuccessful, a third
“ENQ” should be sent one second later. One second after
the third (unsuccessful) “ENQ”, the MCDU should
assume that the subsystem is faulty. However, once the
menu has been created, the MCDU should attempt the
menu text interrogation with the non-responding system
periodically (every 10 to 60 seconds).
After a long-term power interruption, the procedure in
this section should be repeated.
3.7.2.2 Menu Changes
Subsequent to the creation of the initial menu, aircraft
subsystems operating with the MCDU may be turned on
or off by the crew’s use of breakers or by some abnormal
condition. The following text describes the desired
MCDU reaction in such abnormal situations.
After the initial menu has been established and label 172
is lost from a subsystem for three seconds, the MCDU
should consider that subsystem to be inoperative and
should not attempt to communicate with the system. The
MCDU should remove (or flag) the text on the main
menu for that particular subsystem.
If label 172 suddenly appears on an MCDU input bus
after the initial menu has been established (whether or not
the communication had previously been established), the
MCDU should attempt to establish the subsystem on the
main menu using the “Initial Menu” procedure described
above.
COMMENTARY
The ability to change menu dynamically has been
provided to handle abnormal situations. A typical
situation is that the crew may have elected to keep a
system turned off until after take-off. If the menu
could not be changed after the initial menu routine
was performed, a system powered up later would not
be able to communicate with the MCDU.
Similarly, a system experiencing intermittent problems
could reestablish communication with the MCDU as its
health permits. Although it may be considered a nuisance
by the crew to have a main menu item disappear and
reappear from time to time, it alerts them that a problem
does exist with that system.
3.7.2.3 Alternate Menu
An alternate menu display format should be used for
MCDUs designed for back up navigation data, radio
control, and display control. The alternate display format
is described in Section 4.2.1. The display menu should be
capable of listing all menu items. It is recommended that
the MCDU display contain menu items on both sides of
the page to accommodate the maximum number of
selectable functions and modes. The text for each menu
item should be limited to eleven characters. Two menu
items per line is permitted, and each menu item should be
selected by its respective pushbutton switch, (i.e., item c-1
selected by left button and right menu item selected by
right button).
COMMENTARY
The MCDU should be capable of accommodating up
to 18 characters of menu text. In some instances, the
available field length may be less than 18 characters
and the description of such menu items may need to
be shortened to fit in the available space.
3.7.3 Data Communication
The following sections describe the protocol when
normal communication is desired between an MCDU and
an aircraft subsystem.
3.7.3.1 Subsystem Initiated Message
ACARS/CMU and the FMC/GN(L)U are systems
typically wanting to send a message to the MCDU
without a crew-initiated request. The following sections
describe the procedure for subsystem-initiated requests.
3.7.3.1.1 Subsystems Not Currently Active
After a system has been established on the menu list, but
is not in “active” communications with the MCDU and it
has a message for the MCDU, it should send a “Request
to Send” (RTS) to each MCDU using the “MCDU
Address Label” (MAL) in the label position of the data
word (bits 1-8) and coded for a “normal request”. If the
system is connected to three MCDUs, it should send the
RTS three times successively (once for each different
MAL). When the MCDU is not in active communication
with that subsystem, this “RTS” message should cause the
annunciator lights on the MCDU to come on to alert the
crew of a message waiting and should cause the MCDU
to display the request status described in Section 3.4.2
when the MCDU menu is on the screen.
The MCDU should respond to a “RTS” within 200
milliseconds with a “CTS” with the “Maximum Record
Count” set to zero. The subsystem should wait until an
“ENQ” is received from the MCDU. The MCDU should

3.0 MCDU DESCRIPTION (cont’d)
then use the procedure described in Section 3.7.3.2 to
initialize communications with the “requesting”
subsystem.
After an “ENQ” is received from a MCDU, the subsystem
should send a Discrete Word (DC4) to the other MCDUs
with the appropriate clear request bit set, as defined in
Attachment 3. The clear request should extinguish the
annunciator light and then delete the request status from
the associated subsystem name on the MENU page. The
clear request bit should remain set (to “1”) for each
MCDU until an “ACK” is returned from the respective
MCDUs.
3.7.3.1.2 Active Subsystems
When the MCDU is already in active communication
with a subsystem and a “RTS” is received from the
subsystem, the MCDU should send a “CTS” containing
the maximum number of records receivable and the
subsystem’s SAL. A zero in the maximum record count
should cause the subsystem to wait for a valid “CTS”
word for up to one second at which time the message
should be dropped.If the maximum record count in the
“CTS” word is non-zero and less than the record count in
the “RTS” word, the “RTS” should be repeated every 200
milliseconds after each invalid “CTS” word up to ten
times before dropping the message.
If a “CTS” word is not received from the MCDU within
200 milliseconds, the subsystem should repeat the “RTS”
word. The “RTS” should be repeated 10 times without
receiving a “CTS” before dropping the message.
The subsystem upon receiving a valid “CTS” word
should send its transmission to the responding MCDU
using the “STX” word and continue as described in
Section 3.7.3.3 of this Characteristic.
3.7.3.2 MCDU Communication with Inactive
Subystem and Data Request
When a new subsystem is selected via the MENU page or
special function key, the MCDU should repeat a
“LOGOFF” word to the already active subsystem every
200 milliseconds for 1 second or until an “ACK” word is
received and then send an “ENQ” with the new SAL, its
MAL and coded for a Normal Request. On power-up the
logoff is not needed (see Section 3.7.2.1). The subsystem
should respond with a “RTS” within 200 milliseconds.
COMMENTARY
Some MCDUs may be designed to ‘hold’ the prior
active user obviating the need to “LOGOFF” the
current active user. This avoids the time required to
“LOGOFF” the active user and reinitiate
communication using “ENQ” if the ‘held’ user is
subsequently returned to. If a system is in a ‘held’
state, then this status should be reflected on the menu
page. This operation can be beneficial when the
system architecture dictates that the crew must
frequently toggle between two of the user systems.
If no “RTS” is received within 200 milliseconds, the
MCDU should repeat the “ENQ” message every 200
milliseconds until a “RTS” is received or a period of one
second has elapsed since the first “ENQ”. If no response
ARINC CHARACTERISTIC 739A - Page 11
is received, the MCDU should indicate a “time-out” on
the display. In a power-up condition the next priority
subsystem should be attempted.
In response to a “RTS” the MCDU should send a “CTS”
with the maximum record number and the subsystem’s
SAL. The normal subsystem response would be the
“STX” providing the initial data as described in Section
3.7.3.3.
If a “CTS” word is not received within 200 milliseconds,
the subsystem should repeat the “RTS” word. The “RTS”
should be repeated 10 times without receiving a “CTS”
before dropping the message.
If the maximum record count in the “CTS” word is non-
zero and less than the record count in the “RTS” word,
the “RTS” should be repeated every 200 milliseconds
after each invalid “CTS” word up to ten times before
dropping the message.
3.7.3.3 Message Transfer
Normal message transfer should begin with an “STX”
word from the subsystem. See Sections 3.7.3.1 and
3.7.3.2 for message initialization. Every “STX” word
should contain the “record word count” to designate the
number of ARINC 429 words comprising a record (one
record for each line of text). The count should be the
number of words between the “STX” and “EOT/ETX”
words inclusive. The “record sequence number” should
indicate the record sequence within the entire message,
e.g., the third record should have a “three”. The “STX”
word should be followed by one or more control words
and one or more data words. The last word of a record
should use the “ETX” word and should repeat the “record
sequence number. Unused character positions at the end
of a record prior to record sequence number and
EOT/ETX should be padded with zeros. The last word of
the last record should use an “EOT” word in place of the
“ETX” to designate the end of the message. Following
the successful reception of a complete message, the
MCDU should send an “ACK” within 1.5 seconds.
During the subsystem transmission of a message, if a
parity check fails or expected word counts and actual
word counts are not equal, the MCDU should send a
“NAK” word containing the subsystem’s SAL and the
record sequence number of the record exhibiting the
problem. The subsystem should complete its
transmission and attempt to repeat the NAKed portion of
the message by using the subsystem initialization
procedure described in Section 3.7.3.1. The MCDU
should retain the valid records.
If an “ACK” or “NAK” is not received by the subsystem
within 1.5 seconds, the subsystem should repeat the entire
message starting with the first “STX” word. The message
should be attempted three times before discontinuing
further transmission of the message.
If no data words containing the remaining portion of the
message are received for a period of 200 milliseconds or
the MCDU becomes “confused” in the word counting
process, a “SYN” word should be sent to the subsystem.
The subsystem should discontinue its message, attempt a
ARINC CHARACTERISTIC 739A - Page 12
3.0 MCDU DESCRIPTION (cont’d)
3.7.3.3 Message Transfer (cont’d)
“RTS” as described in Section 3.7.3.1.2 and repeat the
entire message. If three successive “SYN” words are
received by the subsystem, it should drop the message.
COMMENTARY
A “SYN” differs from a “NAK” in that the MCDU
can recover portions of the message by using the
“NAK”. “SYN” announces to the subsystem that
essentially no portion of the message is recoverable
and that the entire message must be retransmitted.
However, for the purpose of error processing, there
is virtually no difference between “SYN” and
“NAK” responses.
3.7.3.4 Control (CNTRL) Word
The control word should specify the initial character
position, the color, the font and the line number at which
to start filling the MCDU display. This word may be
repeated within a record as necessary. The Display field
identifies the characteristic of displayed characters, e.g.,
reverse video, underscore, blinking. See Attachment 3
for bit assignments.
COMMENTARY
Not all displays, due to inherent design limitations,
have the capability to provide all of the special
display effects designated by the bits of the control
word. Care should be taken in subsystem design to
ensure that operator confusion does not occur if any
special display effect cannot be produced by the
MCDU.
3.7.3.5 Data Word
The data word should specify up to three characters of the
set listed in Attachment 4. Carriage return or line feed
should not be sent. The control word should be used to
accomplish these functions.
3.7.3.6 Background/Vector Words
The Standby Navigation capability described in Section
4.2.3 includes an optional map display interface. Section
3.9 of this characteristic describes the interface standards
which will enable the MCDU to be used with any
manufacturer’s electronic display, designated Electronic
Flight Instrument (EFI) herein.
3.7.3.7 Discrete Word
A discrete word identified by “DC4” should be sent as
needed from the subsystem to all MCDUs at one second
intervals. It informs the MCDU of the self-test status of
the subsystem and provides the MCDU with commands
to blank the display/buffer, extinguish the FMC
annunciator light and extinguish the MCDU menu light.
The MCDU after recognizing a bit set for a command and
executing it should send an “ACK” to the subsystem at
which time the subsystem should discontinue sending the
“DC4” word to that MCDU.
COMMENTARY
Since the “DC4” word addresses each MCDU
individually, the word would not completely
disappear from the subsystem output bus until all
MCDUs have responded.
The blanking displays and buffers capabilities have
the following intent. When a DC4 word is received
with the clear display buffer bit set, the MCDU
should clear the input memory buffer used to update
the active display buffer. The current MCDU
display should not be affected by clearing this buffer.
This capability could be applied in cases where there
is a need to completely erase the input buffer,
allowing for a quick build of a different display.
When a DC4 word is received with a blank screen
bit set, the MCDU should blank the display via
hardware or by the active display buffer The
blank screen capability could be used in between
page changes to provide a more visible indication of
a display page change.
3.7.3.8 Button Push Word
The button push word identified by DC1 in bits 19-25
should be sent by the MCDU in response to all
alphanumeric, mode keys, and select enter button pushes
on the MCDU. The exceptions are that the “MCDU
Menu” button and the “line select” keys (while in the
Main Menu Mode) will not generate a button push word.
The pushbutton code field should contain the code for the
button pressed. The valid codes are highlighted in
Attachment 4. The sequence number field ranges from 0
to 15 decimal and should be incremented for each new
key pressed. A retransmission of a button push should
have the same sequence number as the previous
transmission. The repeat field is normally a zero and
should be set to one key if a key is held continuously for
one second. If the key is held for greater than one second
the button push word should be repeated at a one second
rate with this indicator set. Note that a button push
without the repeat indicator set should always precede
one with the indicator set.
The button push word should always be ACKed by the
subsystem unless a parity error is detected. In this case
the subsystem should send a “NAK” and the MCDU
should repeat the word. If an “ACK” is not received
within 200 milliseconds the button push word should be
repeated.
3.8 Built-In Test Equipment (BITE)
3.8.1 BITE Considerations
The MCDU should contain Built-In Test Equipment
(BITE) capable of detecting (and optionally
annunciating) faults or failures which can occur within
the MCDU. 90% BITE coverage should be a design
goal. BITE should operate continuously during flight.
Monitoring should be automatic and BITE should have
the capability to test, detect, isolate and identify
intermittent and steady state failures. BITE should
display system conditions and indicate the presence of a
fault upon the activation of self-test described in Section
3.8.3. The design should minimize the effect of BITE
failure on normal MCDU operation.
 ARINC CHARACTERISTIC 739A - Page 13
3.0 MCDU DESCRIPTION (cont’d)
3.8.2 BITE Display 3.9.5 Map Display Edit Area
BITE information may be made available on a low speed The MCDU may limit the data sent to the EFI to that
ARINC 429 bus for use in the centralized fault display as needed for the viewing window. Editing should only be
described in ARINC Report 604, “Guidance for Design considered if there is a likelihood of MCDU data
and Use of Built-In Test Equipment (BITE)”. Alternate exceeding the size of the map data block.
MCDUs could be used to display BITE data to the flight
crew or maintenance technician while controlling BITE 3.9.6 Background Data Prioritizing
from another unit.
The MCDU background data priority should be as
3.8.3 Self-Test follows:
At the time of MCDU turn-on, a power-up self-test 1. Primary Flight Plan
should be automatically initiated as described in ARINC 2. Flight Plan changes
Report 604. Failure conditions should be displayed 3. Waypoints
where possible on the MCDU display.
3.9.7 Data Type Word Formats
COMMENTARY
The data type word formats specified in Attachement 6 of
It is highly desirable that subsystems that are ARINC 702A should apply for the MCDU. However, the
software loadable consider including in their only data type identification codes expected to be used
software kernal the ability for an unloaded unit to are as follows:
indicate its unloaded state on the MCDU. This
indication could be on the MENU page or a Octal Label Parameter
subsystem page depending on the extent of the
software kernal in the subsystem. 000 Fill-in Words
014 Discrete Word-Range
070 Active Standard Waypoint plus Identifier
3.9 Electronic Flight Instrument System Interface 100 Vector-Active Flight Plan
164 Map Reference Group-Longitude
The standards in this section represent a subset of those 264 Map Reference Group-Latitude
described in ARINC Characteristic 702A. This section 300 Vector-Active Flight Plan Changes
addresses the unique subset requirements for the MCDU, 301 Start of Transmission
leaving ARINC 702A as the complete standard for the 302 End of Transmission
EFI interface. 303 Start of Dynamic Data
330 Standard Waypoint plus Identifier
364 Discrete Word-Map Mode
3.9.1 MCDU Outputs to EFI
3.9.8 Flight Plan Retention
The MCDU should provide one high speed ARINC 429
output port for an EFI. The MCDU should be designed to provide the capability
to retain the flight plan during power loss of up to 10
Dynamic data is comprised of ARINC 429 labelled data seconds.
and may include situational information such as time to
go, distance to go, desired track and cross track distance.

3.9.2 MCDU Inputs from EFI

The MCDU provides one low speed ARINC 429 data

input port through which map mode, scale and option
selections are transferred from the EFIs to the MCDU.
3.9.3 MCDU Flight Plan Inputs from FMC

The MCDU may provide a capability to receive flight

plan information from the FMC/GN(L)U.
3.9.4 Flight Plans and Guidance
If the MCDU is capable of receiving information from an
FMC, the flight plan data will consist only of fixes, fix
identifiers, vectors and conics. The data sequence of
lines and conics will be represented by great circle paths
between waypoints and a curved transitions between the
first path legs only. The MCDU may contain guidance
algorithms which generate the guidance commands to a
flight control system to track the flight plan.
ARINC CHARACTERISTIC 739A - Page 14
4.0 NAVIGATION AND DISPLAY CONTROL
4.1 Introduction
This section defines the optional features of the Multi-
purpose Control and Display Unit (MCDU) to provide
alternate navigation data source, back-up navigation radio
management, and back-up display control. Attachment 9
illustrates optional functions of the MCDU which would
be used in addition to the basic functions.
As an option, the MCDU may perform the following
specialized functions in addition to the multi-purpose
operations currently defined in the previous sections of
this Characteristic. If the MCDU implements these
features, they should be performed as specified herein.
a. Standby frequency and tuning control for navigation
radio systems such as VHF Omni-Range (VOR),
Distance Measuring Equipment (DME), Automatic
Direction Finder (ADF), Instrument Landing System
(ILS), Microwave Landing System (MLS).
b. Independent (stand-alone) navigation with the
capability to support the display of simple map on a
display system using position data from the Inertial
Reference System (IRS) and/or GNSS receiver or
GPIRU.
The availability of the standby navigation mode of
operation provides the ability to improve dispatch
reliability and minimum certification requirements
for dispatch with long range navigation equipment.
c. Mode and selection controls for Electronic Flight
Instrument System (EFIS) and Engine Indication and
Crew Alerting System (EICAS).
COMMENTARY
Future updates to this Characteristic may include the
need for Differential GNSS (DGNSS) selection.
4.2 Functional Requirements
4.2.1 System Selection and Control
The selection of the MENU push-button should result in
the MCDU display of a menu page, listing the interfacing
systems and available alternate modes. The MCDU
should generate the MENU page title, page numbers, line
headers, and line text for the MCDU’s alternate modes.
4.2.2 Navigation Radio Tuning
4.2.2.1 Mode Selection
The MCDU should provide the capability to tune DME,
VOR, ADF, ILS and MLS radios. This function is an
alternative to the radio tuning capability provided as part
of a dedicated radio management panel. Navigation radio
tuning should be integral to MCDU design where all
normal radio management is accomplished by a Flight
Management Computer (FMC). The navigation radio
tuning page should be accessible via a dedicated function
button appearing on the FMC pages of the MCDU.
4.2.2.2 General Operation
The MCDU radio tuning data should be sent to the
appropriate transceiver via a dedicated tuning bus
following the activation of the standby radio tuning mode.
The MCDU should be capable of retaining selected
portions of the last FMC transmission of data when the
standby tuning mode of operation has been activated. The
MCDU monitors its Source Destination Identifier (SDI)
pins to determine which corresponding radio data will be
continued to be displayed and transmitted. The tuning
page should display information which indicates the
tuned frequency, course, mode, etc., as well as the
auto/manual/remote tuning status of the radios.
COMMENTARY
The MCDU should monitor its SDI pins to
determine when and if a function should be active.
For example, the MCDU would inhibit the back up
navigation, radio tuning and EFIS/EICAS display
functions for MCDU installations which support
maintenance systems only.
The MCDU should continue to maintain the correct data
status and transmit data to the radios following the
selection of any other MCDU menu or functions.
4.2.2.3 Navigation Tuning Page Functions
The navigation radio page should provide the capability
to tune VOR, ADF, ILS and MLS ground stations. The
page format should include the display of line headers
such as VOR, ADF, ILS-MLS, etc. as appropriate for the
specific radio being tuned.
Valid data entry should be monitored on the basis of
frequency range, course azimuth, elevation, and
increment as appropriate for each radio type. Valid
entries may also be accompanied by an indication that it
is a manual selection (this would provide consistency
with an FMC radio page which will provide both
automatic and manual selection indications). Incorrect
entry to the MCDU should result in the display of an
INVALID ENTRY message. Deletion of an ILS/MLS
entry should result in reversion to the PARK mode.
For ADF radios the MCDU should be capable of
commanding the Beat Frequency Oscillation (BFO),
Antenna (ANT), and ADF modes.
For ILS or MLS receivers the MCDU should be capable
of determining radio type automatically from manual
entry.
The MCDU should have the capability to determine
DME frequency pairing with VOR, ILS or MLS by using
the mode data from external sources such as EFIS control
panel and/or cockpit switches.

4.0 NAVIGATION AND DISPLAY CONTROL (cont’d)
4.2.2.3.1 Tune Inhibit
The MCDU should inhibit any changes in the selected
ILS/MLS frequency when a tune inhibit condition exists.
It is expected that this condition would exist only during
auto-land conditions.
4.2.2.4 Interface Requirements
The MCDU should transmit radio tuning data on a
dedicated low speed ARINC 429 output port. In
addition, the MCDU may provide the following discretes:
a. L-DME and R-DME audio discretes where an open
state represents DME paired with VOR, and a
ground condition represents DME paired with ILS or
MLS.
b. ILS/MLS select discrete where an open state
represents ILS station selected and a ground
condition represents MLS station selected.
c. ILS/MLS PARK discrete where an open state
represents NOT PARK and a ground condition
represents PARK. An external source should be able
to inhibit changes to ILS/MLS tuning (i.e., during
autoland) using the PARK discrete.
d. Normal/Standby to enable radios to determine which
input port to select for tuning control.
The MCDU should have the capability to receive and
process the following analog discretes:
a. ILS Tune Inhibit
The radio tuning command and digital discrete data
words generated by the MCDU should conform to the
guidelines of the appropriate ARINC Characteristics to
which the radio is designed.
COMMENTARY
The analog discrete interfaces described herein
should also have corresponding digital discretes to
allow for appropriate flexibility for various
installation configurations. In addition, analog
discretes such as PARK may not be necessary if the
backup radio control design automatically defaults to
full featured operation in order to avoid exposure to
any other faults.
4.2.3 Standby Navigation
4.2.3.1 Mode Selection
The standby navigation mode, if provided, should be
capable of being activated either manually by crew
intervention, or automatically, if for example, the MCDU
detects a failure in the selected FMC/GN(L)U. The
MCDU should monitor the activity of the selected
ARINC CHARACTERISTIC 739A - Page 15
FMC/N(LG)U data bus to determine when the loss of
activity occurs.
COMMENTARY
Provision of a manual activation capability in the
MCDU should be given careful consideration to
factors such as: a. clear and unambiguous indications
that the standby capability is being used; b. means to
ensure no potential confusion by flight plan changes
in the standby mode which are not reflected in the
FMC/GN(L)U; and c. a means to return to normal
operation with the FMC/GN(L)U.
4.2.3.2 Operation
4.2.3.2.1 General
The MCDU should be capable of performing a role as
independent (stand-alone) navigator using the Inertial
Reference System (IRS) and/or a GNSS receiver or a
GPIRU as the means of navigation.
COMMENTARY
When multiple positioning sources are allowed, it
may be necessary for the MCDU to provide an
indication of it’s navigation source, depending on the
system integration and implementation.
4.2.3.2.2 Navigation and Guidance
Under normal operation each MCDU receives flight plan
data from its onside FMC/GN(L)U, consisting of active
route waypoint latitudes/longitudes and waypoint names.
If there is a valid FMC/GN(L)U available the MCDU
should receive an update to a flight plan upon sequencing
the active waypoint or following the activation of a
modification to a flight plan (i.e., direct-to, approach
change, waypoint deletions/additions, etc.).
When the standby navigation mode becomes active due to
the detection of an FMC/GN(L)U failure, the MCDU
should use the last received FMC/GN(L)U flight plan and
IRS/GNSS data to maintain an active standby flight plan.
If the MCDU detects no valid IRS or GNSS input when
the standby navigation mode becomes active, it should
generate an appropriate failure indication by removing
the affected MCDU page display or by disabling access
to the affected page. When operating in the standby
navigation mode, the MCDU should allow only flight
plan changes using direct-to waypoint, entered and line
selected lat/long waypoints, line select closure of
discontinuities, and line selected insertion and deletions.
Direct-to selections should be made by line selection of a
waypoint identifier or lat/long on the appropriate MCDU
page.
4.2.3.2.3 CDU Page Access
When the MCDU activates the standby navigation mode,
it should be capable of generating at least two types of
display pages for flight plan data, radio tuning and flight
progress status, as appropriate.
When the MCDU standby navigation mode is activated,
all purely FMC/GN(LU) push button functions should
become inoperative. The MCDU pages which display
ARINC CHARACTERISTIC 739A - Page 16
4.0 NAVIGATION AND DISPLAY CONTROL (cont’d)
4.2.3.2.3 CDU Page Access (cont’d)
standby flight plan data generated by the standby
navigation function should be available, but should be
clearly identified as displaying standby data. The standby
flight plan data pages should be displayed in response to
the corresponding MCDU function keys.
With an invalid FMC/GN(L)U, the selection of a function
key, which would normally be used to access an active
flight plan related page, should provide direct access to
the active standby navigation pages.
The desired course to the current active waypoint, as
displayed on the active standby flight plan related pages,
should be referenced to magnetic north if IRS magnetic
referenced data is available. Otherwise, the course to any
waypoint should be displayed relative to true north. A T
or M should be displayed by all course information to
denote the reference being used.
COMMENTARY
It may be desired that the course indications (M or
T) be selected by a program pin. One possible
approach is that a ground (logic “0”) represents all
true heading courses and logic “1” represents
magnetic heading for desired course and blank for
all others.
4.2.3.2.4 Navigation Computations
The MCDU should be capable of generating informative
navigation parameters for display on its own screen
and/or transmitted to other displays as specified by the
operator. The parameters, specified by the operator, are
generated using data primarily from the IRS and/or a
GNSS receiver, and the flight plan most recently received
from the FMC. The standby navigation function may
provide for integration of the inertial and GNSS sensor
data in a manner that allows “coasting” through
temporary loss of GNSS information. The parameters
computed by the standby navigation function may include
any or all of the following, or others as determined by the
requirements of the operator:
a. Present Position
b. Present Track
c. Desired track to the next waypoint
d. Heading (if IRS is available)
e. Cross Track Deviation
f. Distance to next waypoint
g. Time to go to the next waypoint and between route
waypoints (if GNSS data is unavailable), otherwise
estimated time of arrival (if GNSS data is available)
h. Wind speed and direction (if IRS is available)
i. Waypoint alert
j. Ground Speed
k. Track Angle Error
l. Cross Track Acceleration
The standby navigation function should be designed to
the guidelines established by SC-181 MASPS for RNP
Navigation. The standby navigation function, at a
minimum, should provide for RNP default and entry,
computation of Estimated Position Uncertainty (EPU),
and the associated alerting displays.
The MCDU should continuously update data at the rate
appropriate to the data’s function, using inputs from the
IRS and/or GNSS receiver, and the last FMC cross-load
flight plan data. The data will be available for advisory
display and other functional use when the standby
navigation mode is active.
4.2.3.2.5 Map Display
The MCDU may be capable of generating formatted data
which can be used by an EFIS type system to generate a
map display on the Navigation Display (ND) unit. Map
data should be consistent with vectors, waypoints,
identifiers, etc., as computed by the FMC/GN(L)U. The
Map Display interface should be as described in Section
3.9 of this Characteristic.
The EFIS and the MCDU may be configured in a variety
of ways to effect a map display on the ND which is
responsive to the selected mode and range commands.
One preferred way is for the MCDU to receive
mode/range commands directly from the EFIS control
panel and transmit map data to the EFIS accordingly. In
this case the MCDU may have the capability of providing
a page to serve as backup to the EFIS control panel if it
fails.
Another preferred way is to configure the EFIS and the
MCDU such that the MCDU transmits the entire flight
plan as most recently received from the FMC, and the
EFIS produces the map display in accordance with the
mode/range commands received from the control panel.
The MCDU, in this case, does not necessarily have the
capability of providing backup EFIS control panel
capability.
If GNSS data is available, the standby navigation function
should compute and display ETAs associated with
waypoints and destination, otherwise the time should be
displayed as the Time To Go (TTG) when in the Standby
Navigation mode.
4.2.3.3 Interface Requirement
The MCDU should process data received from a
dedicated Inertial Reference System (IRS) and/or GNSS
receiver or GPIRU. Additionally, the MCDU should be
designed with the capability to process the same data
format transmitted on the current FMC/IRS hi-speed
ARINC 429 interface.

4.0 NAVIGATION AND DISPLAY CONTROL (cont’d)
The MCDU should monitor the status of the analog
discrete interface to determine the selection of the
standby navigation mode, by an open/ground indication.
It should be capable of processing mode and range
received on the EFIS control panel interface.
When the standby navigation mode has been activated,
the MCDU should set the Signed Status Matrix (SSM)
bits for flight path angle, range to altitude and vertical
deviation to no-computed data when the standby
navigation mode has been activated.
4.2.4 Alternate EFIS Control
4.2.4.1 General
The MCDU may provide the capability to generate
MENU selectable display pages as an alternate to the
EFIS control panel. The alternate EFIS control panel
page function should automatically activate when a total
bus loss has been detected for an EFIS control panel
input. When the failure is detected, the MCDU should
initialize its EFIS control panel pages using the last
processed EFIS panel selection. The page data can
include mode, range, VOR course, decision height (DH),
DH reset, and barometric altimeter setting.
4.2.4.2 Page Access
The EFIS CONTROL page should be accessible via a
menu prompt on the MENU page. The MCDU should
restrict page access based upon the bus status of the EFIS
control panel (CP) input. If the EFIS CP is valid, the
MCDU should have the capability to list the EFIS control
item but preclude page access. If the EFIS CP is invalid
(loss of all data activity for one second), the EFIS control
functions should automatically become active and page
access should be allowed. Access between the EFIS
control panel pages will be provided by line select key
prompts on each page.
The MCDU should automatically return to the MENU
page if an alternate EFIS control panel page is being
displayed and the EFIS CP bus becomes valid for one
second. If an alternate EFIS control panel page is not
being displayed, the MCDU page display will not be
affected.
The NEXT/PREV keys should be the only function push
buttons associated with the ALTN EFIS CONT page.
COMMENTARY
The page access restriction is intended to prevent the
selection of different conflicting modes, ranges, etc.,
if both the EFIS CP and MCDU were available
simultaneously. The unnecessary complication of
back-driving the primary unit (EFIS CP) from the
back-up MCDU is thus avoided.
Consideration should also be given to the bus
fail/page access criteria. An alternate approach is to
have the MCDU monitor selected parameters. For
example, if the barometric altimeter data word has
no-computed-data, or failure warning sign status,
only access to the EFIS control panel pages would
be allowed.
ARINC CHARACTERISTIC 739A - Page 17
4.2.4.3 Interface
The MCDU should transmit the alternate EFIS control
panel page data on its display control panel bus. Data
transmission will begin when the page function becomes
active. Data transmission should cease if the EFIS CP
becomes valid for one second.
The digital data characteristics should be the same as the
original EFIS control panel inputs.
COMMENTARY
A good design approach would consider automatic
bus switching within the MCDU. With this design,
if the EFIS CP is valid, the MCDU will pass the
EFIS CP data directly onto its control panel bus. If
the MCDU detects the loss of data for one second,
its bus monitor should then switch control of the bus
to its internal control panel function.
4.2.5 Alternate EICAS Control
4.2.5.1 General
The MCDU may provide the capability to generate
MENU selectable display pages as an alternate to the
EICAS control panel. The alternate EICAS control panel
page function will become active automatically when the
MCDU detects a total bus loss for its control panel input.
The MCDU will initialize its alternate EICAS control
panel pages for no selections.
4.2.5.2 Page Access
The EICAS MODES page should be accessible only by
the menu prompt on the MENU page, after a loss of
control panel input is detected. Access between the
EICAS MODES and SYNOPTICS pages should be
provided by line select key prompts on each page.
The MCDU should automatically return to the MENU
page if an alternate EICAS control panel page is being
displayed and the control panel bus becomes valid for one
second. If an alternate EICAS control panel page is not
being displayed, the MCDU page display should not be
affected.
The NEXT/PREV keys should be the only function push
buttons associated with the ALTN EICAS CONT page.
4.2.5.3 Interface
The MCDU should transmit the EICAS page data on its
display control panel bus. Data transmission will begin
when the page function becomes active. A MCDU
maintenance word, label 351, should be the discrete word
which is transmitted to the EICAS to indicate that a non-
selected system is requesting attention.
ARINC CHARACTERISTIC 739A - Page 18
4.0 NAVIGATION AND DISPLAY CONTROL (cont’d)
4.2.5.3 Interface (cont’d)
COMMENTARY
System integrators may find it desirable to utilize an
analog discrete interface to identify requesting
systems on the EICAS. If implemented, the analog
discretes signals should utilize pins 31-33 and
identify them as FMC Request, ACARS Request,
and Menu Request respectively.
The MCDU should suspend transmission of data if its
control panel bus becomes valid for one second. The
MCDU should respond to mode function line selections
by momentarily setting the appropriate digital discrete for
a period of one-half to one second.
The digital data characteristics should be the same as for
the original EICAS input data.
Similar to the alternate EFIS controls, the MCDU
designer should consider automatic bus switching in the
MCDU.
4.2.6 System Communication
4.2.6.1 Inter-System
is also defined in Section 2.2. The pin assignments for
both the Basic Connector and Optional Connector are
defined in Attachment 1.
4.4 Standby Navigation Lateral Guidance
Some users may desire the MCDU to compute a lateral
steering signal for use by the Flight Control Computers
(FCC). The steering signal should be continously
computed when there is an active waypoint identitifed.
The steering signal should be based upon the same
control laws as used for lateral steering in the FMC,
considering cross-track deviation, track angle error,
ground speed and track intercept. Lateral turn
anticipation should be included for waypoint transition.
The data should be transmitted on a low-speed ARINC
429 bus in the same format as that produced by the FMC.
COMMENTARY
It should be noted that the aircraft system
architecture, operating modes and configurations,
failure rates, undetected failure rates, and system
safety assessment are among the considerations
necessary to determine when and how these
capabilities may be utilized.

The handshake and digital data transfer communication

between the MCDU and all other interfacing avionics
systems (including the FMC) should be based on ARINC
4.2.6.1 Inter-System (cont’d)

Specification 429, “Mark 33 Digital Information Transfer

System (DITS)”.

COMMENTARY
The MCDU should be able to receive updates to its
flight plan and/or radio tuning data even when it is
under active control of another system. It is
recommended that this be accomplished by the use
of a priority level such as the system ID labels. Each
broadcast label should be the initial word of a block
data transmission. This approach will allow the
MCDU to have essentially transparent foreground
processing of flight plan and/or radio data which
may occur concurrently with the basic
handshake/log-on protocol.

4.3 Hardware Requirements

4.3.1 General

The following enhancements to the existing ARINC

Characteristic 739A would enable the MCDU to provide
functions of radio tuning and standby navigation.
4.3.2 Interwiring Definition

If the functions described in Section 4 of this

Characteristic are implemented in the MCDU, it should
have two interwiring connectors.

The basic connector is described in Section 2.2. An

additional connector should be provided for the interfaces
and physical/functional isolation required for radio tuning
and standby navigation functions. The optional connector
 ARINC CHARACTERISTIC 739A - Page 19
ATTACHMENT 1
STANDARD INTERWIRING

BASIC CONNECTOR:
FUNCTION MCDU AIRCRAFT WIRE I-R [5]

Future Spare 1 o
Onside FMC
Onside FMC
] AB 2
3
o
o
Onside FMC
(High Speed)
D-5
D-5
Future Spare ] 4 o
Offside FMC
Offside FMC
] AB 5
6
o
o
Offside FMC
(High Speed)
D-5
D-5
Future Spare ] 7 o
Input Port #3
Input Port #3
] AB 8
9
o
o
Aircraft
Subsystem
D-5
D-5
Future Spare ] 10 o
Input Port #4
Input Port #4
] AB 11
12
o
o
Aircraft
Subsystem
D-5
D-5
Future Spare ] 13 o
Input Port #5
Input Port #5
] AB 14
15
o
o
Aircraft
Subsystem
D-5
D-5
Future Spare ] 16 o
Input Port #7
Input Port #7
] AB 17
18
o
o
Aircraft
Subsystem
D-5
D-5
Future Spare ] 19 o
Future Spare 20 o
Future Spare 21 o
28 VDC Inst. Power C 22 o
Program Return 23 o
Input Port #6
Input Port #6
] AB 24
25
o
o
Aircraft
Subsystem
D-5
D-5
Shield Ground ] 26 o
Output Port
Output Port
] AB 27
28
o
o
Aircraft
Subsystem
D-5
D-5
Act Port Prog ] 29 o
CDU Location 30 o
CDU Location 31 o
CDU Fail Discrete 32 o
Lamp Test 33 o
Chassis Ground 34 o DC Ground 1-0.1
Ann. Bright/Dim
Ann. Bright/Dim
] HiLo
35
36
o
o
5 Vac Light ]] H 37 o 5 VAC Panel
5 Vac Light C 38 o Light Supply
28 Vdc Inst. Power ]H 39 o 2A
115 Vac, 400HZ
115 Vac, 400HZ
] HC 40
41
o
o
115 VAC 400 Hz
Aircraft Power
2-0.1
2-0.1
]
ARINC CHARACTERISTIC 739A - Page 20
ATTACHMENT 1 (cont’d)
STANDARD INTERWIRING

OPTIONAL CONNECTOR:
FUNCTION MCDU AIRCRAFT WIRE I-R [5]

Future Spare 1 o
Onside IRU (GPIRU)
Onside IRU (GPIRU)
] AB 2
3
o
o
Onside IRU
(High Speed)
D-5
D-5
Future Spare ] 4 o
EFIS Cont. Panel
EFIS Cont. Panel
] AB 5
6
o
o
EFIS Control D-5
D-5
Future Spare ] 7 o
Display Output A 8 o Aircraft D-5
Display Output ]B 9 o Subsystem D-5
Future Spare ] 10 o
Gen. Bus Output
Gen. Bus Output
] BA 11
12
o
o
Aircraft
Subsystem
D-5
D-5
Future Spare ] 13 o
EFIS Cont. Output
EFIS Cont. Output
] AB 14
15
o
o
Aircraft
Subsystem
D-5
D-5
Future Spare ] 16 o
Future Spare 17 o
Discrete Input (Spare) 18 o
Discrete Input 19 o
Discrete Input 20 o
Discrete Input 21 o
Future Spare 22 o
Discrete Input 23 o
Discrete Output 24 o
Discrete Output 25 o
Discrete Output 26 o
Discrete Input 27 o
Discrete Output 28 o
Future Spare 29 o
Discrete Input 30 o
Discrete Output 31 o
Discrete Output 32 o
Discrete Output 33 o
Future Spare 34 o
Onside GNSS
Onside GNSS
] AB 35
36
o
o
GNSS

Future Spare ] 37 o
Future Spare 38 o
Future Spare 39 o
Future Spare 40 o
Future Spare 41 o
 ARINC CHARACTERISTIC 739A - Page 21

ATTACHMENT 1 (cont'd)
NOTES ON STANDARD INTERWIRING

1. Pins 30 and 31 should be used for encoding MCDU 5. The “I-R” values define the maximum current (I) in
position in the aircraft and the appropriate MCDU amperes and effective resistance (R) in ohms for
Address Label (MAL) for identification. The which the installation and equipment should be
following encoding scheme should be employed on designed. It is anticipated that installation designers
the connector. will use these figures, together with the lengths of the
cable runs in a given airframe, to calculate the gauge
of each wire in the installation. Where their
MAL PIN calculations reveal the possibility of using higher
30 31 gauge numbers than #22 AWG, they are asked to
stop and consider whether the mechanical strength of
220 To Pin 23 Open this wire is adequate for the installation before
221 Open To Pin 23 deciding to use it. The airlines report recent sad
222 To Pin 23 To Pin 23 experiences with such wire, and although they are, of
course, interested in the weight saving its use affords,
230 Open Open they will quickly point out that these savings are
rapidly nullified by maintenance costs if frequent
breakage occur.
2. When Pin 29 is open, the MCDU should
communicate with the subsystem (FMC) on input NOTE: Wires for which a “D” symbol is shown in
port #1. When Pin 29 is connected to Pin 23 place of a current rating may be used for any function
Program Return, the MCDU should communicate ranging from “Dry Circuits” (hence “D”) to 5 ampere
with the subsystem (FMC) on input port #2. applications.

Both installation and equipment designers should

3. A “ground” on pin 33 should cause a lamp test to be give due regard to special cases wherein parallel or
executed. series-parallel connected circuits may result in higher
currents or voltage drop (effective resistance) than in
simple circuits. Unless otherwise noted, the current
4. When the MCDU has detected an internal failure, an limit set forth applies to all elements of parallel or
internal ground should be made on pin 32. series-parallel circuits.
ARINC CHARACTERISTIC 739A - Page 22

ATTACHMENT 2
ADDRESS LABELS

MCDU NO. MCDU ADDRESS LABEL (OCTAL)

1 220
2 221
3 222
4 230

NOTE: See Attachment 1 for MCDU number pin coding.

 ARINC CHARACTERISTIC 739A - Page 23
ATTACHMENT 3
DIGITAL WORD FORMATS

RTS WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P DC2 0 SEE BELOW 0 RECORD COUNT MAL
MSB

BITS FUNCTION
20 19 18 17
0 0 0 0 NORMAL REQUEST
0 0 0 1 MENU TEXT REQUEST
0 0 1 0 SPARE
• •
• •
1 1 1 1 SPARE

CTS WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P DC3 0 MAX RECORD COUNT 0 SAL
MSB

STX WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P STX 0 RECORD SEQUENCE 0 RECORD WORD COUNT MAL
NUMBER MSB

CNTRL WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P CNTRL F COLOR LINE FUNCTION INITIAL MAL
SEE NUMBER SEE CHARACTER MSB
BELOW BELOW POSITION

BITS COLOR BITS FUNCTION

23 22 21 16 15 14
0 0 0 BLACK 0 0 1 REVERSE VIDEO (OPTIONAL)
0 0 1 CYAN 0 1 0 UNDERSCORE
0 1 0 RED 1 0 0 FLASHING
0 1 1 YELLOW
1 0 0 GREEN
1 0 1 MAGENTA
1 1 0 AMBER
1 1 1 WHITE
ARINC CHARACTERISTIC 739A - Page 24
ATTACHMENT 3 (cont’d)
DIGITAL WORD FORMATS

DATA WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P CH #3 0 CH #2 0 CH #1 MAL
MSB

DATA WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P CH #6 0 CH #5 0 CH #4 MAL
MSB

ETX WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P ETX 0 RECORD 0 MAL
SEQUENCE NUMBER MSB

EOT WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P EOT 0 LAST 0 MAL
RECORD NUMBER MSB

PUSH BUTTON WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P DC1 R PUSH BUTTON 0 SEQUENCE SAL
CODE NUMBER MSB

SCRATCH PAD WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P DC1 F CHARACTER COLOR INITIAL MAL
SEE CHARACTER MSB
BELOW POSITION

BITS COLOR
16 15 14
0 0 0 BLACK
0 0 1 CYAN
0 1 0 RED
0 1 1 YELLOW
1 0 0 GREEN
1 0 1 MAGENTA
1 1 0 AMBER
1 1 1 WHITE
 ARINC CHARACTERISTIC 739A - Page 25
ATTACHMENT 3 (cont’d)
DIGITAL WORD FORMATS

ACK/NAK WORD From MCDU

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P ACK/NAK 0 RECORD 0 SAL
SEQUENCE NUMBER MSB

ACK/NAK WORD From Subsystem

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P ACK/NAK 0 MAL/SAL
MSB

ACK/NAK WORD From Subsystem

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P DC4 DISCRETE BITS MAL
(SEE BELOW) MSB

BIT FUNCTION (when set to “1”)

9* Self-Test (Subsystem from which the MCDU receives the word is in self-test)
10 Blank Screen
11 Clear Display Buffer
12 Clear FMC Request
13 Clear Subsystem Request (not used with FMC and ACARS)
14 Clear ACARS Request
15 EXEC Annunciator
16 DSPY Annunciator Applies only to MCDUs with Annunciator
17 MSG Annunciator - Receipt of logic “1” lights Annunciator
18 OFST Annunciator - Receipt of logic “0” extinguishes Annunciator
19* MCDU Test Request Receipt from allowed subsystem causes MCDU to execute self-test
- Inputs to MCDU during self-test are ignored
20 Spare
21 Spare
22 Spare
23 Spare
24 Spare

* NOTE: In some installations, the functions of bits 9 and 19 are reversed.

SYN WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

P SYN 0 SAL

VECTOR WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

P TBD
ARINC CHARACTERISTIC 739A - Page 26
ATTACHMENT 3 (cont’d)
DIGITAL WORD FORMATS

BACKGROUND WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

P TBD

ENQ WORD

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
P ENQ 0 SEE BELOW MAL SAL
MSB MSB

BITS FUNCTION
20 19 18 17
0 0 0 0 NORMAL REQUEST
0 0 0 1 MENU TEXT REQUEST
0 0 1 0 SPARE
• •
• •
1 1 1 1 SPARE

SUBSYSTEM IDENTIFIER (from Subsystem)

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

P 0 SUBSYSTEM SAL SUBSYSTEM ID

MSB (LABEL 172)

Optional Data
Bit 17 - Master/Slave Status for some dual system configurations, 1 = Master

MCDU IDENTIFIER (from MCDU)

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

P 0 DECIMAL DECIMAL SUBSYSTEM ID

“3” “9” (LABEL 377)

Optional Data
Bits 19&20 indicate selected FMC port of 1 or 2, where 20/19 = 0 1 = 1, 1 0 = 2
Bits 21&22 indicate keyboard differences, where 22/21 = 0 0 = baseline, 0 1 = alternate

EICAS DISCRETE WORD (from MCDU)

32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
7 6 5 4 3 2 1
P 0 SDI
MCDU INPUT PORT
OF EICAS ID
ACTIVE = 1
MCDU (LABEL 351)

0 = Port Selected or Inactive

1= Non-Selected Port Request for Attention
 ARINC CHARACTERISTIC 739A - Page 27
ATTACHMENT 3 (cont’d)
DIGITAL WORD FORMATS

MCDU NORMAL DISCRETE WORD (270)

BIT NO. FUNCTION BIT STATUS
1 0
1 X
2 X
3 X
4 LABEL 270 (OCTAL) X
5 X
6 X
7 X
8 X
9 NOT USED
10 NOT USED
11 PORT #1 RECEIVER FAILED NORMAL
12 PORT #1 DATA INPUT FAILED NORMAL
13 PORT #2
14 PORT #2
15 PORT #3
16 PORT #3
17 PORT #4
18 PORT #4
19 PORT #5
20 PORT #5
21 PORT #6
22 PORT #6
23 PORT #7
24 PORT #7
25
26 *OPTIONAL PORTS (SEE BELOW)
27
28 SPARE
29 MCDU STATUS FAILED NORMAL
30 SSM
31 SSM
32 PARITY
c-1

OPTIONAL PORTS HEALTH STATUS

BIT 27 26 25
NORMAL 0 0 0
PORT A FAILED 0 0 1
PORT B FAILED 0 1 0
PORT C FAILED 0 1 1
PORT D FAILED 1 0 0
PORT E FAILED 1 0 1
PORT F FAILED 1 1 0
PORT G FAILED 1 1 1

*NOTE: See Section 3.6.2 for description of optional ports.

ARINC CHARACTERISTIC 739A - Page 28
ATTACHMENT 4
CHARACTER CODE ASSIGNMENTS (DERIVED FROM ISO #5)

BIT 7-----------------------------------------------> 0 0 0 0 1 1 1 1
BIT 6----------------------------------------> 0 0 1 1 0 0 1 1
BIT 5--------------------------------> 0 1 0 1 0 1 0 1

BIT BIT BIT BIT Column

4 3 2 1 → 0 1 2 3 4 5 6 7
Row ↓
MCDU
0 0 0 0 0 NUL SP 0 P MENU SEL1

SPECIAL
0 0 0 1 1 CNTRL DC1 ! 1 A Q FUNCTION SEL2

KEYS
0 0 1 0 2 STX DC2 " 2 B R 1 TO 13 SEL3

0 0 1 1 3 ETX DC3 # 3 C S SEL4

0 1 0 0 4 EOT DC4 4 D T SEL5

0 1 0 1 5 ENQ NAK % 5 E U SEL6

PREV
0 1 1 0 6 ACK SYN & 6 F V PAGE

NEXT
0 1 1 1 7 / 7 G W PAGE

LOG
1 0 0 0 8 CLR OFF ( 8 H X SER1

1 0 0 1 9 ) 9 I Y SER2

1 0 1 0 10 * : J Z SER3

1 0 1 1 11 + ; K [ SER4

1 1 0 0 12 o , < L SER5

1 1 0 1 13 o - = M ] SER6

1 1 1 0 14 ↓ . > N ↑ ∆
CLR/
1 1 1 1 15 → ? O ← or ∆ DEL

NOTE: The “pushbutton” word should not be generated by the “MCDU Menu” key or “line select” keys when the MCDU
menu is being displayed.

Shaded codes are button push codes.

 ARINC CHARACTERISTIC 739A - Page 29

ATTACHMENT 5
ENVIRONMENTAL TEST CATEGORIES

The following environmental specifications for the Multi-Purpose Control and Display Unit (MCDU) reflect RTCA
DO-160D categories. Designers should use the current version of RTCA DO-160.

ENVIRONMENT (DO-160D) Section Category

Temperature & Altitude 4 CAT A1
In-Flight Loss of Cooling 4.5.4 CAT Z
Temperature Variation 5 CAT C
Humidity 6 CAT A
Operational Shock and Crash Safety 7 CAT B
Vibration (1) 8 CAT S
Explosion Proofness 9 CAT X
Waterproofness (2) 10 CAT X
Fluids Susceptibility 11 CAT X
Sand and Dust 12 CAT X
Fungus Resistance 13 CAT X
Salt Spray 14 CAT X
c-1
Magnetic Effect 15 CAT Z
Power Input 16 CAT A
Voltage Spike 17 CAT A
Audio Frequency Conducted Susceptibility – Power Inputs 18 CAT A
Induced Signal Susceptibility 19 CAT Z
Radio Frequency Susceptibility (Radiated and Conducted) 20 CAT V
Emission of Radio Frequency Energy 21 CAT M
Lightning Induced Transient Susceptibility 22 CATA3E3
Lightning Direct Effects 23 CAT X
Icing 24 CAT X
Electrostatic Discharge (ESD) 25 CAT A

1. The use of alternative categories may be necessary if the installation is to be made in other than turbine
powered fixed-wing aircraft. Refer to RTCA DO-160D directly.

2. Rack-mounted and cockpit-mounted units should withstand spillage of liquids (beverages).

ARINC CHARACTERISTIC 739A - Page 30

ATTACHMENT 6
TYPICAL SYSTEM CONFIGURATION

MCDU
1
• •

•
• MCDU
2
• • •
•
MCDU
COMMAND
BUSES

FMC 1 FMC 2 ACARS

SUBSYSTEM RESPONSE BUSES

NOTE: These could be dedicated to theMCDU or could be normal operational data buses (shared).
 ARINC CHARACTERISTIC 739A - Page 31
ATTACHMENT 7

TYPICAL FRONT PANEL LAYOUT

ANNUNCIATOR FOR THE SYSTEM HAVING PRIORITY

TITLE LINE
LINE NUMBER 1
LINE NUMBER 2
LINE NUMBER 3
LINE NUMBER 4
LINE NUMBER 5
LINE NUMBER 6
LINE NUMBER 7
LINE NUMBER 8
LINE NUMBER 9
LINE NUMBER 10
LINE NUMBER 11
LINE NUMBER 12
SCRATCH PAD

NEXT MAIN
CALL
PAGE MENU

A B C D E

F G H I J

1 2 3 K L M N O

4 5 6 P Q R S T

7 8 9 U V W X Y

/ 0 . Z + - SP CLR
ARINC CHARACTERISTIC 739A - Page 32

ATTACHMENT 8
GLOSSARY

ACARS Aircraft Communications Addressing and Reporting System

ACK Acknowledge Transmission
AIDS Aircraft Integrated Data System
BITE Built-In Test Equipment
CDU Control/Display Unit
CFDIU Central Fault and Display Interface Unit
CLR Clear
CTS Clear to Send
DEL Delete
EFIS Electronic Flight Instrumentation System
EICAS Engine Indication and Crew Alerting System
ENQ Enquire
EOT End of Transmission
ETX End of Text
CFDS Central Fault and Display System
FMC Flight Management Computer
GN(L)U GNSS Navigation (and Landing) Unit
IRS Inertial Reference System
ISO International Organization for Standardization
MAL MCDU Address Label
MCDU Multi-Purpose Control and Display Unit
NAK Not-Acknowledge Transmission
RNP Required Navigation Performance
RTS Request to Send
SAL System Address Label
SATCOM Satellite Communication
SDI Source Destination Identifier
SSM Signed Status Matrix
STX Start Transmission
SYN Transmission Not Understandable/Recoverable
 ARINC CHARACTERISTIC 739A - Page 33

ATTACHMENT 9
OPTIONAL MCDU FUNCTIONS

BASIC 7 ARINC 429 MCDU HANDSHAKE OUTPUT

INPUTS FROM BASIC ARINC 739 TO SYSTEMS
SYSTEMS FUNCTIONS + INPUT STATUS LABEL

NEW NAV RADIO

TUNING FUNCTION * NAV RADIO TUNING
ADDITIONAL INPUT + *

NEW, BACK-UP
IRS INPUT * NAVIGATION * NAV DISPLAY
FUNCTION
GNSS INPUT * *

NEW, OPTIONAL
LATERAL CONTROL * AUTO PILOT
*

NEW, BACK-UP
MONITOR EICAS CP * EICAS CONTROL * EICAS ALTERNATE
and EFIS CP OUTPUT FUNCTION CONTROL
BUS *

NEW, BACK-UP
EFIS CONTROL * EFIS ALTERNATE
FUNCTION CONTROL
*
 ARINC CHARACTERISTIC 739A - Page 34
ATTACHMENT 10
MCDU DISPLAY CONSIDERATIONS
1.0 General
This attachment is considered as guidance and is
provided only for example. Specific implementations
may vary.
1.1 Display
The MCDU screen will accommodate 14 rows of 24
characters each. The top line can be referred to as the
title line and the bottom line can be referred to as the
scratch pad. The title line should normally be used to
indicate the active subsystem and function being
accessed. The scratch pad should be used to display
messages to the crew and to reflect keyboard entry of data
which can then be shifted to an appropriate field on the
display by pressing the adjacent line select key, as
described in Section 2.4.1.
The 12 middle rows on the display should be viewed as
six paired lines where each pair consists of a “header
line” and a “data line”. A line select key is positioned
adjacent to each end of each data line. In describing
formats and operations, it is convenient to refer to the
pairs as lines 1 through 6 and the line select keys as 1L
through 6L and 1R through 6R. If a display application
requires lengthy text messages, multiple lines may be
used. However, the remaining lines should preserve the
header line and data line distinction.
Each line can be divided into one, two or three fields as
desired. When a center field is defined, it should be a
display only field. Field widths are variable and should
be sized by the data they will contain. At least two spaces
should be left between fields. In laying out fields,
consideration should be given to display readability. Too
much data on a page can make scanning difficult, thereby
rendering it ineffective inflight and undesirable for
maintenance use as well.
2.0 Display Format Conventions
2.1 Title Line
When a subsystem is in communication with the MCDU,
the subsystem generated page title should clearly identify
that subsystem and/or the function being accessed. The
page title should be displayed using the large font
alphanumeric characters. This convention ensures that in
the case of typical cockpit operations, the flight crew will
always have a clear indication of the active subsystem
and function to aid in the mental reorientation required
after any number of interruptions. For example,
“ACARS” would appear in the title of an ACARS control
c-1 page. Similarly, “ACMS” would appear on ACMS pages,
etc. To avoid confusion, use of another subsystem’s key
words must be avoided in the title line.
When a subsystem consists of two identical units, either
master/slave, or master/hot spare, or both units operating
at the same time and performing complimentary
functions, the subsystem may generate an introductory or
top level menu page that provides capability to select
and/or display which of the two units is active or is
primary. In these cases, the MCDU-generated menu page
should have a single prompt for access to the subsystem-
generated menu page where the L/R (or onside/offside,
etc.) select/display capability is provided. The subsystem-
generated introductory or top-level menu page TITLE
LINE should clearly identify the subsystem without an
indication of “L” or “R”, or onside/offside, etc. For
example “ACARS”. An indication such as “ACTIVE” or
other distinct indication in a HEADER or DATA line
(Sections 2.2 and 2.3) or a combination of the two, may
be used on the subsystem-generated menu page to
designate which unit is in control, if appropriate. If the
architecture is such that the two subsystem units are
performing complimentary functions and a master/slave
or similar hierarchy does not apply, then the subsystem-
generated menu page can simply provide access to either
unit without indication of a primary or master.
Use of a subsystem-generated menu page for display and
control of dual subsystem units reduces space demands
on the MCDU-generated menu page by requiring only
one, rather than two, line select positions.
In a dual unit subsystem installation where one of the
units has been selected for display, (via line selection
from either the MCDU menu page or the subsystem-
generated menu page) the particular unit should be clearly
identified in the TITLE LINE of the subsystem page for
ease of identification. For example: “ACARS - L”. If
appropriate for the architecture, an indication in another
location on the subsystem page may indicate whether or
not that unit is “primary” or “master”. When one unit in a
dual installation is the active MCDU subsystem, the c-1
subsystem will be designated as “ACTIVE” on the
MCDU-generated menu page as described in Section
3.4.2. Selection of the subsystem prompt on the MCDU-
generated menu page in this case should result in direct
access to the active unit subsystem page without having to
go to the subsystem-generated menu page.
Many pages overflow the screen space. When this
happens, a display page can be considered to consist of
multiple screens/pages of data and should be numbered
on the right end of the title line. For example, if there are
two pages they should be numbered “1/2” and “2/2” using
numbers in small font. In cases where the total number of
pages may be variable, the total pages available must be
determined and identified. The NEXT PAGE and PREV
PAGE keys should be used to move back and forth
through these multiple pages. Unless some unique
requirement dictates otherwise (such as scrolling),
pressing NEXT PAGE when viewing the last page should
roll the display to page 1/xx and pressing PREV PAGE
when viewing page 1/xx should roll the display to the last
page. When there will never be more than one page for a
given title, the page number (i.e., 1/1) need not be
displayed. However, “1/1” should be displayed in cases
where more than one page could exist under different
circumstances.
Titles should be static (invariant). However, some may
change or be enhanced with superimposed words to
indicate a submode, submenu, etc. Use of dynamic titles
should be avoided. Also, titles should be kept as short as
possible rather than strive to identify every function on
the page. It should be recognizable at a glance. A

ATTACHMENT 10 (cont’d)
MCDU DISPLAY CONSIDERATIONS
consistently used abbreviation is preferable to a long
word (e.g., use MAINT rather than MAINTENANCE).
The title should not overflow onto the next line. If a
c-1 subtitle is absolutely necessary, it should be centered on
the 1C header line (i.e., in field 1C) and use of the 1L and
1R header and data lines restricted to keep the subtitle
identifiable.
2.2 Header Line
For line pairs one through six, the header line should be
located above its corresponding data line. Header text or
data should be displayed using the small alpha-numeric
font. The use of a small font header line in relation to the
position, and size of the corresponding data line field is
intended to optimize both visual and search performance.
Field of view aspects of the header line may be a basis
for establishing that left headers be left adjusted starting
in column 2. However, right headers could be right
adjusted to column 24. The positioning for center fields
should be on the basis of adequate identification and
discrimination of the information to be displayed.
2.3 Data Line
The data line may have varied attributes depending upon
data type and function. A data field may be characterized
as display only, modifiable, or selectable. In general,
large alpha-numeric font should be used for the data line.
However, small font should be used for:
a. Units of measurement following a data value
b. Computer predicted data which may or must be
validated by an operator
c. Display of a default value
d. Data of a low priority, informational nature
2.3.1 Display Only Data Fields
Data characterized as display only cannot be overwritten
by data from the scratchpad and cannot be selected to the
scratchpad. Selection of the adjacent line select key
should have no effect. The key press should be ignored.
2.3.2 Variable Capability Data Fields
a. Select Only
This type of data field should only allow for the line
selection of the displayed data to the scratchpad or
functional selections as described in paragraph 2.3.3.
Data entry to and deletion of this type of field is not
allowed. A select only, special procedure field, may exist
when the attributes of the field are such that it can only be
selected after specific criteria have been satisfied
b. Enter Only
This type of data field only allows for the line selection of
displayed data from the scratchpad to the data field. Line
selection of this data to the scratchpad and deletion of this
ARINC CHARACTERISTIC 739A - Page 35
type of field is not allowed.
In cases where a unique field structure allows the entry of
more than one piece of data and entry of either part can
be mutually exclusive, special entry criteria may be
required; For example the field data may be “xxx/yyy”
where the entry of “aaa” will automatically be considered
for the the x-part only and where an entry including a
special delimiter such as “/bbb” should be required to
only enter the data into the y-part of the data field.
An enter only, special procedure field, may exist when the
data field has more than one function governed by
specific pre-existing conditions, or as a normal alternative
for the field.
c. Select/Enter
This type of data field allows for the line selection of
displayed data both to and from the scratchpad. Deletion
of this type of field is not allowed. The special procedure
aspects, of the field are as described for the select only
and enter only fields.
d. Enter/Delete
This type of data field allows for the line selection of
displayed data from the scratchpad and the capability to
delete data entered.
e. Delete
This type of data field allows for deletion of data in the
field. It may be combined with any of the above types.
The special procedure capabilities for selection and entry
into the field are as described for the select only and
enter only fields. A special delete procedure would exist
in the case where deletion of a data field resulted in the
display of a selection prompt instead of the display of a
blank or default value data field.
2.3.3 Prompts
a. Select
A data field may be used to display a prompt which
emphasizes the selectability of another mode, option,
page, parameter, or menu item.
Select prompts on the left side of the display should begin
with a large font caret “< ” in column 1 followed by the
left justified prompt starting in column 2. Select prompts
on the right side of the display must be right justified to
column 23 followed by a large font caret “> ” in column
24.
When a line selectkey associated with a prompt is
pressed, the system should execute the action required by
the prompt selection. A display indication in response to
this action could be in the form of a noticeable change in
indicated system mode, activation/deactivation of a
function, a new page display, etc. The title of a page
display should include the prompt name which selected
the page. The use of prompt names which reflect the
page to be displayed is intended to eliminate any
ambiguity regarding the consequences of selecting a
prompt.
ARINC CHARACTERISTIC 739A - Page 36
ATTACHMENT 10 (cont’d)
MCDU DISPLAY CONSIDERATIONS
2.3.3 Prompts (cont’d)
The data field font size should be as defined in paragraph
2.3. However, a small font prompt may be used in the
case where the prompt must be validated or superseded
by a line select entry from the scratchpad. In this case,
there should be a change in character font size as a
consequence of validation, the caret prompt should be
removed, and the validated prompt should be left or right
adjusted as appropriate. In special applications, the
header field may also be used to either accentuate the
prompt or reflect the condition/status of the prompt
selection.
These type of select prompts should be located at the
bottom of a page (e.g., positioned on lines 6L and/or 6R).
If the number of required select prompts exceeds the
capacity of a line, the menu/list of select prompts should
be built from the bottom line up for any remaining
prompts. The select prompts should have a distinct
separation boundary from other page display data, in the
form of a page width, dashed line located in the header
line of the uppermost select prompt.
b. Enter only
An entry of this type may be required or optional for the
display field and should be indicated by the use of dashes
or box prompts to solicit the data. Typically this type of
entry would be associated with and dependent on another
display field or possibly function/mode. In this case, a
change in the dominant field or function/mode should
cause the dependent field to return to the initial prompt;
Where the data entry is not essential to a function/mode,
dashes to solicit an entry should be displayed. Where the
data entry is required before a function can be performed
or before a mode change can be completed, box prompts
should be displayed to solicit data to be entered. The
number of dashes or boxes used for the prompt should
correspond to the maximum number of alpha-numeric
characters which can be entered.
c. Enter/Delete Only -
An entry of this type may be optional and should be
indicated by the use of dashes to solicit the data. This
type of entry could be associated with an on/off type
function or the insertion of a reference value or limit.
After data has been entered, deletion of the data field
should return to dash prompts or default value for the
data field. The number of dashes used for the prompt
should correspond to the maximum number of alpha-
numeric characters which can be entered.
d. Select/Enter/Delete -
An entry of this type should use dash prompts for the
display data field. This type of entry could be required or
optional. The use of this field should be oriented toward
setting limits, adding a bias to a default setting, setting a
reference, etc. It should be used where the systems page
designs allow for the transfer of data from one field to
another to facilitate data entry. The number of dashes
used for the prompt should correspond to the maximum
number of alpha-numeric characters which can be
entered.
2.4 Scratch Pad Line
The scratch pad line at the bottom of the display should
be used for two purposes:
a. To temporarily display data being entered via the
keyboard or moved from field to field, and
b. To display system messages to the crew.
2.4.1 Scratch Pad Data Entry via Keyboard
Normally, the whole 24 character scratch pad line should
be kept available for data entry. Since it may be time
shared with the display of system messages, any message
being displayed may require being cleared by pressing the
CLR key before data entry is allowed. The subsystem
must keep track of when the scratch pad contains a
message and when it contains either a blank line or
previously entered data.
If a subsystem designer determines that the 24 character
line can be subdivided to allow simultaneous data entry
and message display without interference, the data entry
field should be considered on the left. Its maximum size
should be indicated by a full-time vertical line character,
whether or not a message is being displayed on the right.
This alternative design restricts the size of data entries
and messages but has the advantage of avoiding the need
to clear messages before data entry.
Starting with a blank scratch pad, the first character
entered should be displayed in column 1. Each
subsequent character entered should appear to the right of
the last character already be in the scratch pad. All
characters should be displayed in large font. The last
character on the right of the scratch pad entry should be
removed when the CLR key is pressed and released. The
next character on the right should be removed when the
CLR key is pressed again and so on. The complete data
entry should be removed when the CLR key is held down
for more than one second.
2.4.2 Scratch Pad Data Entry via Line Select
If the scratch pad is clear, pressing the line select key
adjacent to a selectable data field should cause the data in
that field to be duplicated in the scratch pad, left adjusted.
Once in the scratch pad, it should be treated just as
though it had been entered via the keyboard. In other
words, characters can be added on the right and/or
cleared from the right of the entry.
2.4.3 Scratch Pad Transfer to Data Field
If the scratch pad contains data, pressing a line select key
should cause the subsystem computer to:
a. Check that data entry is permissable for the adjacent
data field. If not, the line select key press should be
ignored.
b. Check the validity of the data for use in the adjacent
data field. In other words, validity checking of data
occurs when the transfer is attempted, not when the
data is keyboarded into the scratch pad. If the
 ARINC CHARACTERISTIC 739A - Page 37
ATTACHMENT 10 (cont’d)
MCDU DISPLAY CONSIDERATIONS

validity check fails, an indication of an invalid entry
should be generated.
c. Transfer valid data from the scratch pad to the data
field, replacing previous contents and clearing the
scratch pad.
If an entry is reformatted when it is moved from the
scratch pad to a data field, it must be returned to the entry
format when it is moved from data field to scratch pad.
For example, a latitude/longitude might be entered as
N4720.3W12245.2 in the scratch pad and be reformatted
as N47 20.3 W122 45.2 in a data field. It must be
returned to the N4720.3W12245.2 form when moved
back to the scratch pad.
The requirements for the display may specify special
responses/indications resulting from the data entry into a
field. For example, in the case where a list is being
displayed and it is desired to insert a new item in the list,
the line select entry to a specific field should produce the
result of inserting the entry and pushing all previous list
data down one data line versus overwriting the field into
which the entry is made.
Messages are expected to be cleared automatically from
the display and message stack when the subsystem set
logic is no longer satisfied. Any displayed message
should be cleared and associated message set logic reset
when the CLR key is pressed. The next message in the
stack should then be displayed. Holding the CLR key
down should not cause all messages and data to be
displayed and cleared in a continuous sequence. Cleared
messages must not be redisplayed until the appropriate set
logic has again been satisified or some appropriate
redisplay or recall logic is satisfied. In general, messages
should be avoided wherever possible since they can be
perceived as more of a nuisance than an aid to flight
crews.
When more than one MCDU is in communication with a
subsystem at the same time, a scratch pad data entry
should only appear on both MCDUs if they are on the
same page. If they are on different pages, it should be
possible to make an independent data entry on each
MCDU. Data entry error advisory messages must only be
displayed on the MCDU displaying the offending entry.
Other advisory messages should only be displayed when a
related page is displayed.

2.4.4 Data Transfer From Field to Field

Data can be moved from one field to another via the
scratch pad. First the scratch pad should be cleared if not
already clear. Next the line select key adjacent to the data
to be moved should be pressed. This action duplicates
the selected data in the scratch pad. Finally, the line
select key adjacent to the destination field should be
pressed to move the data up from the scratch pad. It
should be possible to move data from page to page using
the same technique unless the pages are sufficiently
dissimilar that no need for this capability exists.
However, data cannot be moved across subsystem
boundaries using the scratch pad.

2.4.5 Scratch Pad Messages

Different levels of message priority may be defined e.g.,

alerting and advisory.

An alerting message could be used when the subsystem

computer detects a condition which must be brought to
the crew’s attention. It would be displayed in the scratch
pad of each operating MCDU in communication with the
subsystem regardless of prior contents of the scratch pad.
The prior contents of the scratch pad, if any, should be
saved in a message stack/buffer and redisplayed when the
alerting message is cleared.
An advisory message could be used to indicate data entry
errors or other lower priority information. It should not
displace alerting messages but should be displayed when
the scratch pad is cleared. Therefore, it should be
inserted in a message stack below any alerting messages
in the stack. Data entry error advisory messages would
take precedence over other advisory messages and scratch
pad data entries. Other advisory messages should only be
displayed when the scratch pad is cleared. As with
alerting messages, scratch pad contents should be saved
in a message stack when replaced by an advisory
message.
 Copyright 1998 by
AERONAUTICAL RADIO, INC.
2551 Riva Road
Annapolis, Maryland 21401-7465 USA

SUPPLEMENT 1

TO

ARINC CHARACTERISTIC 739A

MULTI-PURPOSE CONTROL AND DISPLAY UNIT

Published: November 3, 1998

Prepared by the Airlines Electronic Engineering Committee

Adopted by the Airlines Electronic Engineering Committee: October 29, 1998
SUPPLEMENT 1 TO ARINC CHARACTERISTIC 739A - Page 2

A. PURPOSE OF THIS DOCUMENT in a dual unit subsystem installation, or from other

individual subsystems.
This Supplement introduces changes and additions to
ARINC Characteristic 739A to accommodate MCDU 3.6.3 MCDU Interfaces Involving Dual Subsystem
switching between dual subsystems, for example dual Devices
FMSs.
This section was added to describe dual subsystem
B. ORGANIZATION OF THIS SUPPLEMENT installation techniques.

The first part of this document, printed on goldenrod- 3.7.2.3 Alternate Menu Display
colored paper, contains descriptions of the changes
introduced in Characteristic 739A by this Supplement. A note was added to alert the reader to Section 4.2.1,
The second part consists of replacement white pages for System Selection and Control.
the Characteristic modified to reflect these changes.
The modified and added material on each replacement ATTACHMENT 3, DIGITAL WORD FORMATS
page is identified by the “c-1” symbol in the margins.
Existing copies of Characteristic 739A may be updated The MCDU Normal Discrete Word (Label 270) was
by simply inserting the replacement pages where modified to include health status reporting for port 7
necessary and destroying the pages they replace. The (omission) and optional paired ports.
goldenrod-colored pages should be inserted inside the
rear cover of the Characteristic. ATTACHMENT 5, ENVIRONMENTAL TEST
CATEGORIES
C. CHANGES TO ARINC CHARACTERISTIC
739A INTRODUCED BY THIS SUPPLEMENT This attachment was update to reflect the current
environmental test requirements defined in RTCA DO-
This section presents a complete tabulation of the 160D.
changes and additions to Characteristic 739A
introduced by this Supplement. Each change or addition ATTACHMENT 10, MCDU DISPLAY
is defined by the section number and the title that will CONSIDERATIONS
be employed when this Supplement is incorporated. In
each case, a brief description of the change or addition 2.1 Title Line
is included.
New material was added to provide guidance on
1.6 Relationship to ARINC 739 subsystem-generated menu pages and MCDU-
generated menu pages for dual subsystem
This section was updated to include dual subsystem configurations.
considerations.

2.2 Form Factor

Connector part number was revised to reflect current

military specifications.

3.4.3 Subsystem Specific Menu

This section was modified to describe a typical first

page of a subsystem menu in a dual subsystem
installation. This may include the capability to select a
specific unit to be primary, master, or the operational
unit.

3.6 MCDU Inputs

This section was reorganized and subdivided into three

subordinate sections for the purpose of defining Seven
Basic Input Ports (3.6.1), Additional Subsystem Input
Ports (3.6.2) and MCDU Interfaces Involving Dual
Subsystem Devices (3.6.3).
3.6.1 Seven Basic Input Ports

This section was renumbered. The content is unchanged

from the former Section 3.6.

3.6.2 Additional Subsystem Input Ports

New section was added to describe five optional

ARINC 429 input ports for receiving identification
information and display data from either a second unit