55629551-Arinc739A-1

A

MULTI-PURPOSE CONTROLAND DISPLAY UNIT

ARINC CHARACTERISTIC 739A-1

PUBLISHED: DECEMBER 16, 1998

AN A DOCUMENT

Prepared byAIRLINES ELECTRONIC ENGINEERING COMMITTEEPublished byAERONAUTICAL RADIO, INC.2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401

Copyright 1998 byAERONAUTICAL RADIO, INC.

2551 Riva RoadAnnapolis, 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, 1996Characteristic 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 theprincipal stockholders. Other stockholders include a variety of other air transport companies, aircraftmanufacturers and non-U.S. airlines.

Activities of ARINC include the operation of an extensive system of domestic and overseasaeronautical land radio stations, the fulfillment of systems requirements to accomplish ground andairborne compatibility, the allocation and assignment of frequencies to meet those needs, thecoordination incident to standard airborne compatibility, the allocation and assignment of frequenciesto meet those needs, the coordination incident to standard airborne communications and electronicssystems and the exchange of technical information. ARINC sponsors the Airlines ElectronicEngineering Committee (AEEC), composed of airline technical personnel. The AEEC formulatesstandards for electronic equipment and systems for the airlines. The establishment of EquipmentCharacteristics is a principal function of this Committee.

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

(1) To indicate to the prospective manufacturers of airline electronic equipment theconsidered 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 maximumpossible standardization of those physical and electrical characteristics which influenceinterchangeability of equipment without seriously hampering engineering initiative.

ii

ARINC CHARACTERISTIC 739ATABLE OF CONTENTS

ITEM SUBJECT PAGE

1.0 INTRODUCTION AND DESCRIPTION 11.1 Purpose of This Document 11.2 Functions 11.3 System Description 11.4 Interchangeability 11.4.1 General 11.4.2 Interchangeability Desired for the ARINC 739A MCDU 11.4.3 “Generation Interchangeability” Consideration 11.5 Regulatory Approval 21.6 Relationship to ARINC 739 2

2.0 INTERCHANGEABILITY STANDARDS 32.1 Introduction 32.2 Form Factor 32.3 Environmental Conditions 32.4 Interwiring 32.5 Thermal Interface and Design 32.6 Power Circuitry 32.6.1 Primary Power Input 32.6.2 Power Control Circuitry 42.6.3 The Common Ground 42.6.4 The AC Common Cold 42.7 Weights 42.8 Grounding and Bonding 4

3.0 MCDU DESCRIPTION 53.1 General 53.2 Display 53.3 Keyboard 53.3.1 Basic Function Keys 53.3.2 Specific Function Keys 53.3.3 Alpha-Numeric Keys 53.3.4 Panel Illumination and Annunciator Lights 53.4 MCDU Operation and Display 63.4.1 Typical MCDU Initiation 63.4.2 MCDU Menu 63.4.3 Subsystem Specific Menu 73.4.4 Non-Menu Operation 73.4.5 Scratchpad and Data Field Entry 73.4.6 Clearing Data Fields 73.4.7 Exiting 73.4.8 Proposed Philosophy to Menu Stepping 73.5 MCDU Outputs 83.6 MCDU Inputs 83.7 System Communication 83.7.1 Subsystem and MCDU Identification 83.7.2 Menu Generation 83.7.2.1 Initial Menu 83.7.2.1.1 Addressing and Responses 83.7.2.1.2 Protocol Timing and Responses 93.7.2.2 Menu Changes 93.7.2.3 Alternate Menu Display 93.7.3 Data Communication 103.7.3.1 Subsystem Initiated Messages 103.7.3.1.1 Subsystems Not Currently Active 103.7.3.1.2 Active Subsystems 103.7.3.2 MCDU Communication with Inactive Subsystem and Data Request 103.7.3.3 Message Transfer 103.7.3.4 Control (CNTRL) Word 113.7.3.5 Data Word 113.7.3.6 Background/Vector Words 113.7.3.7 Discrete Word 113.7.3.8 Button Push Word 12

iii

ARINC CHARACTERISTIC 739ATABLE OF CONTENTS (cont’d)

ITEM SUBJECT PAGE

3.0 MCDU DESCRIPTION (cont’d)3.8 Built-In Test Equipment (BITE) 123.8.1 BITE Considerations 123.8.2 BITE Display 123.8.3 Self-Test 123.9 Electronic Flight Instrument System Interface 123.9.1 MCDU Outputs to EFI 123.9.2 MCDU Inputs from EFI 123.9.3 MCDU Map Inputs from FMC 123.9.4 Flight Plans and Guidance 123.9.5 Map Display Edit Area 123.9.6 Background Data Prioritizing 123.9.7 Data Type Word Formats 133.9.8 Flight Plan Retention 13

4.0 NAVIGATION AND DISPLAY CONTROL 144.1 Introduction 144.2 Functional Requirements 144.2.1 System Selection and Control 144.2.2 Navigation Radio Tuning 144.2.2.1 Mode Selection 144.2.2.2 General Operation 144.2.2.3 Navigation Tuning Page Functions 144.2.2.3.1 Tuning Inhibit 154.2.2.4 Interface Requirements 154.2.3 Standby Navigation 154.2.3.1 Mode Selection 154.2.3.2 Operation 154.2.3.2.1 General 154.2.3.2.2 Navigation and Guidance 154.2.3.2.3 CDU Page Access 154.2.3.2.4 Navigation Computations 164.2.3.2.5 Map Display 164.2.3.3 Interface Requirement 164.2.4 Alternate EFIS Control 174.2.4.1 General 174.2.4.2 Page Access 174.2.4.3 Interface 174.2.5 Alternate EICAS Control 174.2.5.1 General 174.2.5.2 Page Access 174.2.5.3 Interface 174.2.6 System Communication 184.2.6.1 Inter-system 184.3 Hardware Requirements 184.3.1 General 184.3.2 Interwiring Definition 184.4 Standby Navigation Lateral Guidance 18

ATTACHMENTS

1 Standard Interwiring 192 Address Labels 223 Digital Word Formats 234 Character Code Assignments (Derived from ISO #5) 285 Environmental Test Categories 296 Typical System Configuration 307 Typical Front Panel Layout 318 Glossary 329 Optional MCDU Functions 3310 MCDU Display Considerations 34

iv

ARINC CHARACTERISTIC 739A - Page 1

1.0 INTRODUCTION AND DESCRIPTION

1.1 Purpose of This Document

This document sets forth the desired characteristics of aMulti-Purpose Control and Display Unit (MCDU)intended for installation in commercial transport aircraft.The intent of this document is to provide general andspecific design guidance for the development of theMCDU. It describes the desired operational capability ofthe equipment and the standards necessary to ensureinterchangeability.

Equipment manufacturers should note that this documentencourages them to produce maintenance-free, highperformance equipment rather than that of minimumweight and size. They are at liberty to accomplish thisobjective by means of the techniques they consider to bethe most appropriate. Their airline customers areinterested primarily in the end result rather than themeans employed to achieve it.

Avionics systems optimization can be achieved on boardmodern aircraft by minimizing the cost, weight and sizeof avionics. The use of one or more MCDUs willcontribute to this goal.

By the use of identical MCDUs, the specific control anddisplay units for ACARS/CMU, AIDS, CFDS and othersystems can be eliminated. There would be substantialsavings 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 multiplesystems one at a time (equivalent to multi-purposeswitch). System selection is by use of keys on the MCDU(dedicated keys or by menu item key) and is achieved bysending different user system address labels on a commonoutput command data bus. See Attachment 6.

The MCDU should provide means for manually selectingsubsystems connected and for inserting system controlparameters and modes of operation. In addition, it shouldprovide display capability for various subsystems outputsas well as for the verification of data entered intomemory. Certain annunciations related to systemoperation may also be included.

Providing that the standardized protocols and messagestructures are used, the MCDU can be used with anysystem regardless of application. It is therefore trulymulti-purpose.

1.3 System Description

As a minimum, the MCDU should contain the circuitryand processing necessary to accept alpha-numericmessage codes and display them on the screen, andcircuitry for transmitting command codes relating to linekeys or keyboard keys. Data communication isdetermined by standard protocols and message formats,within the selected system.

The structure and content of messages, menus andinterpretation of commands is carried out by software inthe user system and not in the MCDU.

1.4 Interchangeability

1.4.1 General

One of the primary functions of an ARINC EquipmentCharacteristic is to designate, in addition to certainperformance parameters, the interchangeability desired ofaircraft equipment produced by various manufacturers.

The manufacturer is referred to Section 1.6 of ARINCReport 414 for definitions of Terms and GeneralRequirements for the airline industry forinterchangeability. As explained in that report, the degreeof interchangeability considered necessary and attainablefor each particular equipment is specified in the pertinentARINC Equipment Characteristic.

1.4.2 Interchangeability Desired for the ARINC 739AMCDU

Unit interchangeability is desired for the MCDUregardless of manufacturing source. The physicalattributes, the electrical interfaces and operation of theMCDU were defined to accommodate application to awide variety of avionics. The standards necessary toachieve this level of interchangeability are set forth in thisCharacteristic.

1.4.3 “Generation Interchangeability” Considerations

In defining the equipment described in this Characteristic,the air transport industry has chosen to depart fromseveral of its previous control function standards. Inorder to achieve the full benefit of the economies offeredby these changes, the industry desires that no provisionsbe made in this equipment for backward compatibilitywith earlier generations of equipment.

Unchanged, however, is the industry's traditional desirethat future evolutionary equipment improvements and theinclusion of additional functions in new equipment in thenext few years do not violate the interwiring and formfactor standards set forth in this document. Provisions toensure forward-looking “generation interchangeability”(as best can be predicted) are included in this documentto guide manufacturers in future developments.


1.0 INTRODUCTION AND DESCRIPTION (cont’d)

1.5 Regulatory Approval

The MCDU should meet all applicable FCC and FAAregulatory requirements. Manufacturers are urged toobtain all necessary information from the FAA and theFCC on such regulatory approval. This information is notcontained in this Characteristic, nor is it available fromARINC.

1.6 Relationship to ARINC 739

This document was developed from ARINCCharacteristic 739, “Multi-Purpose Control and DisplayUnit”, originally developed to support the installation ofMCDUs in FMS-equipped airplanes. This documentbuilds on the ARINC 739 philosophy and includesseveral capabilities viewed to be necessary to satisfyairline desires for CNS/ATM equipment installations intheir existing fleets of airplanes. The ARINC 739AMCDU retains the same textual man-machine interfaceconceived for the ARINC 739 unit. This documentsincludes new material describing:

Dedicated Function Select Key

GNSS Interface

Optional Smaller Form Factor

28 Vdc Power Connection

MCDU Display Considerations

Dual Subsystem Considerations

c-1


2.0 INTERCHANGEABILITY STANDARDS

2.1 Introduction

This section sets forth the specific form factor, mountingprovisions, interwiring, input and output interfaces andpower supply characteristics desired for the Multi-Purpose Control and Display Unit. These standards arenecessary to ensure the continued independent design anddevelopment of both the equipment and the airframeinstallations.

Manufacturers should note that although thisCharacteristic does not preclude the use of standardsdifferent from those set forth herein, the practicalproblems of redesigning a standard airframe installationto accommodate a special equipment could make the useof that equipment prohibitively expensive for thecustomer. They should recognize, therefore, the practicaladvantages of developing equipment in accordance withthe 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 incheswide. The depth behind the panel should not exceed 10.5inches, excluding the connector.

An alternative form factor intended to support installationin older aircraft, should be packaged as a standard dzus-mounted control panel 7.125 inches high by 5.75 incheswide. The depth behind the panel should not exceed 6.0inches, excluding the connector.

A connector type MS 24264R 20 B 41PN should be usedhaving pin assignments shown in Attachment 1.

When the optional navigation and display controlfunctions are included in the MCDU, a second connectortype MS 24264 20 B 41P6 should be used.

COMMENTARY

Cost, weight, and electrical power consumptionreduction may be achieved by developing a smallerand simpler MCDU. Use of flat screen technologywill undoubtedly allow design of smaller units. Thus,equipment manufacturers may offer MCDUs oflesser dimensions. However, certain attributes suchas screen size and required keys should bemaintained.

The SAE S-7 Flight Deck and Handling QualitiesSubcommittee has expressed concern with the notionof smaller form factor MCDUs. Manufacturers areencouraged to consider human factor implicationsresulting from a reduction in keyboard, character ordisplay sizes.

General Aviation (GA) may require smaller formfactors.

2.3 Environmental Conditions

The MCDU should be specified environmentally in termsof the requirements of RTCA Document DO-160,“Environmental Conditions and Test Procedures forAirborne Equipment”. Attachment 5 to this

Characteristic tabulates the relevant environmentalcategories.

2.4 Interwiring

The standard interwiring for the MCDU is set forth inAttachment 1 to this Characteristic. This interwiring isdesigned to provide the degree of interchangeabilityspecified in Section 1.4. The equipment manufacturer iscautioned not to rely upon special wires, cabling orshielding for use with his particular units because theywill not exist in the standard installation.

COMMENTARY

Why Standardize Interwiring?

The standardized interwiring is perhaps the heart ofall ARINC Characteristics. It is this feature whichallows the airline customer to complete hisnegotiation with the airframe manufacturer so thatthe latter can proceed with installation engineeringand initial fabrication prior to airline commitment ona special source of equipment. This provides theequipment manufacturer with many valuable monthsin which to put final “polish” on his equipment indevelopment.

2.5 Thermal Interface and Design

The internal power dissipation of the MCDU should notexceed 92 watts. The MCDU cooling and thermal designshould be in accordance with ARINC Specification 408A,Sections 2.3, 3.6 and 3.10. These sections define casetemperature limits, the equipment cooling method, thethermal appraisal procedure and expected hightemperature exposure conditions which should beconsidered for the equipment design. However, it may bedesirable (and may be imperative for some installations)that the equipment be designed for passive cooling.

COMMENTARY

ARINC Specification 408A defines the standardinterface between the aircraft and indicators;however, the thermal interface described should alsobe applied to the MCDU.

2.6 Power Circuitry

2.6.1 Primary Power Input

The MCDU should be designed to use 115 volt 400 Hzsingle phase power from a system designed for Category(A) utilization equipment per ARINC Specification413A. Optionally the equipment may be designed tooperate with 28Vdc. Manufacturers should determine themost appropriate power source for each installation.

The primary power input to the MCDU should beprotected by a circuit breaker of the size shown inAttachment 1 to this Characteristic.

NOTE: Airframe installation designers should verify that

c-1


2.0 INTERCHANGEABILITY STANDARDS (cont’d)

the aircraft power systems satisfy the primary powerinterruption criteria of ARINC Specification 413A.

2.6.2 Power Control Circuitry

There should be no master on/off power switching withinthe CDU. Any user desiring on/off control shouldprovide, through the medium of an external switchingfunction installed in the airframe, a means of interruptingthe 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 groundreturn to aircraft structure. It is not intended as acommon return for circuits carrying heavy ac currents,and equipment manufacturers should design theirequipment 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 structurethat provides the dc chassis ground but at a separateground stud. Airframe manufacturers are advised to keepac ground wires as short as practicable in order tominimize noise pick-up and radiation.

2.7 Weights

System manufacturers should take note of the guidanceinformation on weights contained in ARINCSpecification 600.

2.8 Grounding and Bonding

The attention of equipment and airframe manufacturers isdrawn to the material in Section 3.2.4 of ARINCSpecification 600 and Appendix 2 of ARINCSpecification 404A on the subject of equipmentgrounding and bonding.

COMMENTARY

A perennial problem for the airlines is the locationand repair of airframe ground connections whoseresistances have risen as the airframe ages. A highresistance ground usually manifests itself as a systemproblem that resists all usual approaches torectification, and invariably consumes a whollyunreasonable amount of time and effort on the partof maintenance personnel to fix. Airframemanufacturers are urged, therefore, to pay closeattention to assuring the longevity of groundconnections. Close attention to the above-referencedspecification 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 associatedline select keys as described in the following sections.

The MCDU should contain all the electronic circuitry,etc., required to display all specified input/outputparameters, and should provide all necessary controls forcomplete operation of the systems.

COMMENTARY

The MCDU display should provide sufficient datadisplay space to provide efficient, yet uncluttered,display of all data required for the mode or functionselected.

3.2 Display

In general, the MCDU display should be adequate in sizeto provide the greatest amount of information to flightcrew without needless clutter. The top line of the displayshould be the title line describing the page contents. Theremaining lines should be arranged so as to provide easein reading the display. The bottom line of the displayshould be used as the “scratch pad” for entering data.Line keys should be provided on either side of the displayin order to support menu driven functions. Section 3.4describes a typical MCDU display. As an option MCDUdesigners may consider the use of color displays in orderto enhance readability. Additional considerations fordisplay 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 operatorto indicate a contact has been made.

3.3.1 Basic Function Keys

A “MCDU MENU” key should be provided to return theMCDU to the main subsystem menu.

A “CLEAR” key should be provided to clear theinformation displayed in the “scratch pad”.

As a minimum, a “NEXT PAGE” pushbutton should beprovided to advance the display. User systems areexpected to design their display formats such that use ofthe “NEXT PAGE” key is the only specific key functionrequired for its operation as it may be the only keyguaranteed on some MCDUs. A depression of “NEXTPAGE”, when the last page is being displayed, shouldcause the MCDU to return to the first page. As analternative, line keys can be used to select basicfunctions.

COMMENTARY

Although a “PREVIOUS PAGE” button is notspecifically called out in this Characteristic, adedicated button for this purpose appears to havemerit particularly when more than three pages arebeing accessed by the MCDU. A “PREVIOUSPAGE” key code has been assigned in thisCharacteristic in order that manufacturers canprovide this option if they so desire.

Similarly, slewing keys are considered optional.However, not all avionics connected to the MCDUwill be able to slew text up or down on the display.Pressing the slew key, if provided, would have noeffect when these avionics are communicating withthe MCDU.

3.3.2 Specific Function Keys

Up to thirteen specific-function keys may be provided onthe MCDU to accommodate special functions on someavionics (e.g., flight management computer/GN(L)U). Ata minimum, one of these keys should be programmable asto which user it is dedicated. Selection of a dedicatedfunction key should result in the immediate display of thefunctional page from the defined user system. Thisimplies automatic activation of the defined user anddeactivation of the prior active user.

COMMENTARY

Thirteen specific function key codes have beenassigned in this Characteristic. However, it shouldnot be misconstrued as industry support for these“dedicated” keys on the MCDU. Their use byavionics burdens the MCDU by cluttering its frontpanel and essentially preempts its desired role as atruly flexible multi-purpose CDU. Dedicatedfunction keys should only be used when rapid accessto a function is deemed important.

3.3.3 Alpha-Numeric Keys

A full set of alphanumeric keys should be provided on theMCDU. The MCDU should have the capability tosupport the available key codes illustrated in Attachment4.

COMMENTARY

The provision for a “space” key is optional. The“space” key is desired for ACARS and other “freetext” applications. The SAE S-7 Committee hasfound that the space key is necessary for enhancingreadability of free text applications.


3.0 MCDU DESCRIPTION (cont’d)

3.3.4 Panel Illumination and Annunciator Lights

The MCDU should be integrally lighted and be poweredby the 5 volt panel light dimmer bus. The annunciatorlight brightness control should be accommodated by a 5volt supply. The MCDU should accommodate both acand dc light sources.

COMMENTARY

Separate panel light and annunciator light pins havebeen assigned to accommodate separate control. Thepanel lights would be connected to the normal 5 voltpower source use for instrument panel lighting.

Two different methods to vary annunciator brightnessare commonly used. The first uses fixed dc groundon 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 (0Vdc for full brightness). Adequate isolation of theannunciator lights should be provided in the MCDUto accommodate both methods.

An annunciation may be provided to alert the operatorthat 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” annunciatorcould be provided to alert the operator for the lowerpriority (#3-#7) ports.

COMMENTARY

The MCDU integration with an aircraft flight deckmay result in the need for equivalent but differentmethods of providing the annunciations. Forexample in the case where there is a centralized crewindication and alerting system, each subsystem maybe required to produce a distinct indication to theflightcrew via the indicating and alerting system asthe attention getting mechanism. This indicationcould be produced via a separate digital datainterface or analog discrete interface.

A lamp test input from the master control should beprovided where necessary.

3.4 MCDU Operation and Display

The following sections describe typical MCDU operationand display based on a front panel layout as shown inAttachment 7. The preferred display should containfourteen lines, each having twenty-four characters. Thetop line (line 1) should normally be used as a title line tothe display data to which the operator does not haveaccess.

The bottom line (line 14) should be the “scratch pad” linefor entering data. Columns 23 and 24 of the title line andof the scratch pad line may be used as an option for“Slew” indications. Lines 2 through 13 should be datalines arranged into six pairs. The six line keys on eachside of the display should be adjacent to the odd datalines. When selection by way of line key is anticipatedthe symbols (< left, > right) should be used as activation

symbols and should be displayed either at the firstcharacter position if a left line key is used or at thetwenty-fourth character position if right line key is used.

If more than one page is involved the sending systemshould display a “more to come” symbol for the nextpage. The 23rd and 24th characters of the first lineshould be used for “more to come” symbol display.When slewing is used, up and down arrows shouldindicate that vertical slewing is available. They shouldappear in columns 23 and 24 in the scratch pad.

Variations of the procedure may occur according todisplay and keyboard presentation used by differentmanufacturers.

Additional considerations for MCDU displays areprovided 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 highestpriority subsystem. This would typically be a menu of thesubsystem 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 onecurrently active, the operator should push the “MCDUMENU” button. This should result in the presentation ofa list of all subsystems connected to the MCDU. Likewisesingle key access may be provided by selection ofdedicated function keys without the need to use the menupage.

The MCDU should generate subsystem status adjacent tothe 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 thesubsystem name. Any other subsystems having sent a“Request To Send” to the MCDU should be annunciatedby “Req” or equivalent near or after the subsystem name.

The operator should press the line key to establishcommunications with the desired subsystem.

COMMENTARY

Historically, the MENU page subsystem selectionoperation has taken two forms:

a. If no line key is pressed within 60 seconds afterthe MCDU Menu is displayed, the MCDU shouldrevert to the active subsystem display, if there isan active subsystem, otherwise it should displayan appropriate time-out page.

b. Once the MENU page is selected for display, theMCDU should remain on the MENU page until a



selection is made. If the active system is selectedon the menu, the last active subsystem pagedisplay should return. In this case, the subsystem,though not visible, is expected to compute currentinformation as appropriate for the display. If themenu selection results in a changeover to a newactive subsystem, the MCDU displays thesubsystem’s initial page or menu as appropriate.

Following selection of a subsystem, an indication shouldbe provided to inform the operator that the selection ofthe subsystem is acknowledged. Typical methods wouldbe 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 aline key which has no function. There has beensome desire expressed to “blink” the display for ashort period simply to let the operator know that abutton push was recognized. MCDU manufacturersare urged to consider this function in their design.

When communication has been established with asubsystem, the “first page” as transmitted by thesubsystem should be displayed to the operator.

If communication is not established within the maximumtime stated in Section 3.7.3.2, a “Time-out” indicationshould be provided by the MCDU and an instructionshould be displayed to the operator to press the “MCDUMENU” key.

3.4.3 Subsystem Specific Menu

The first page of a subsystem menu should be a menu offunctions which may include the capability to select aparticular unit in a dual subsystem installation to be theprimary, “master”, or operational unit. Selection of amenu item by the operator should result in an indicationto operator that the input was recognized as described inSection 3.4.2.

3.4.4 Non-Menu Operation

Non-menu display pages sent by the subsystem couldcontain 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 forentering data into the MCDU:

Data should be entered through the MCDU keyboard.The data should be entered from left to right into thescratchpad by pressing the alphanumeric keys on thekeyboard. After entry of the data into the scratchpad, thedata can be moved from the scratchpad into the correctdata field by pressing the adjacent line select key. Thesystem should check the data for format and acceptability(out of range, entry not allowed into the field, etc.). Anability to move rapidly through multiple lines of data is

necessary.

In situations where the available field does notaccommodate a scratchpad entry, an appropriate messageshould be displayed on the MCDU.

If the data is incorrect, the system should leave theprevious data in the data field and display the associatedmessage indicating the error in the scratchpad. To enterthe correct data, the operator should clear the messagefrom the scratchpad. To clear the scratchpad of entereddata or incorrect data, the “Clear” key can be used. Onepress of the key should erase the last character entered inthe scratchpad. If the key is held down for two secondsthe entire scratchpad should be cleared of any data.

NOTE: Normally all twenty-four characters of the linecan be used. If slewing indications (arrows) areused then only twenty-two message charactersare available per line.

Whenever the MCDU is waiting for a response from asubsystem or is in a situation which could be ambiguousto the operator, an appropriate message should bedisplayed 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 isempty should result in “CLR” being displayed in thescratchpad. If a “DEL” key exists then it would be usedto clear data fields. Then, pressing the line select keyadjacent to the data field should result in clearing thatdata 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 asubsystem by pushing the “MCDU MENU” button andselecting another subsystem or by pressing a specialfunction key for a different subsystem, which shouldcause the MCDU to perform the sequence described inSection 3.7.3.2.

3.4.8 Proposed Philosophy to Menu Stepping

The general philosophy is that the avionics subsystemconnected to the MCDU manages the stepping forwardsand backwards through the sequence of menus.

COMMENTARY

It is very important to standardize the chosen wordfor backing into previous menus. The most used intoday’s applications is generally “RETURN”. Anyconnected system should allocate a line key for the“RETURN” control. Therefore, there is no need fora specific function key on the MCDU key board.“INDEX” is also typically used for returning tooriginal information. Although it may becommonplace, use of “RETURN” is recommendedinstead to minimize the potential for confusion.

c-1



3.5 MCDU Outputs

The MCDU should have a single output port to provideits own identification and commands to the individualsubsystems communicating through the MCDU usingthirty-two bit words as defined in ARINC Specification429, “Digital Information Transfer System (DITS)”. Thewords transmitted by the MCDU should include MCDUidentification (octal label 377), Discrete Word #1 (octallabel 270) Maintenance Word #1 (octal label 350) and allwords identified by “SAL” in bits 1-8. See Attachment 3for word formats. Maintenance Word #1 data format isnot defined specifically and can be used as the MCDUmanufacturer desires.

3.6 MCDU Inputs

3.6.1 Seven Basic Input Ports

The MCDU should provide seven input ports as definedby ARINC Specification 429 for receiving identificationinformation 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 havepriorities with the highest for #1 and the lowest for #7.The data words listed in Attachment 3 identified withMAL in bits 1-8 should be recognized by the MCDU. Itshould also recognize the word identified by label 172 asthe subsystem identifier.

COMMENTARY

The flight management computer would normally beconnected to ports #1 and #2. Communications witha flight management computer is expected to be“generic”. In other words, when an MCDU iscommunicating with a flight management computer,it would be through the port designated by theprogram pin status as described in Note 2 ofAttachment 1. When this Characteristic refers to thehighest priority port (normally #1) and the pinprogramming has selected port #2, then port #2should be considered the highest priority port.

3.6.2 Additional Subsystem Input Ports

The MCDU may optionally provide additional ARINC429 input ports for receiving identification informationand display data from either a second unit in a dual unitsubsystem installation, or from other individualsubsystems. These ports may be used to provide MCDUmenu selections for additional single-unit subsystems, ormay be associated with the subsystems on ports #3through #7, to create port pairs (e.g., 3A/3B, 4A/4B) toprovide a single MCDU menu selection for control ofdual-unit subsystems as described in Section 3.6.3.

An equivalent number of input discretes may be providedto be used either as program pins to indicate to theMCDU that a particular port pair will handle a dual-unitor subsystem or as a discrete whose state indicates theactive unit in a dual-unit subsystem. Further guidanceappears in Section 3.6.3.

COMMENTARY

It is desirable to have a common MCDU part number

that can operate on multiple airplane models withinan airline fleet. For older aircraft that do not havecommon MCDU dual subsystem switchingconfigurations, it is possible to program the variousswitching configurations into the MCDU softwareand use one or more of the unreserved discrete inputsas program pins to identify the aircraft model.

3.6.3 MCDU Interfaces Involving Dual Subsystem Devices

Dual subsystems should consider the following guidelineswhen controlled by a MCDU.

COMMENTARY

In addition to dual FMC or GNLU installations,other subsystems such as SATCOM and CMU maybe installed as dual subsystems. There are a varietyof techniques used in current aircraft installations andMCDU designs for subsystem displays for these dualdevice subsystems. These include dedicating separateMCDU input ports and line select keys to eachsubsystem device or using aircraft wiring-basedswitching to select between the similar devices, thenrouting the selected unit to a single port and lineselect key on the MCDU. Although the use of twoline select keys for a dual subsystem provides asimple implementation, using this approach with dualsubsystems depletes the number of MCDU menuprompt locations available. This is not desirable froma flight crew operations viewpoint. Aircraft wiring-based switching reduces the dual subsystem inputs toa single MCDU input port. However, this isundesirable due to design complexity, introduction ofnew cockpit switching controls, and introduction of asingle point failure potential (the switching device).

Although implementation of additional input portsand related discrete inputs and software support isoptional, MCDU manufacturers should be preparedto handle exposure to multiple subsystem devicessuch as dual SATCOM, dual CMU, and otherpossible dual subsystems. It is intended that theseadditional ports be used for this purpose, asnecessary, in conjunction with associated discreteinputs, if applicable.

Port pairs may be assigned in the software and useautomatic detection of the master or active unit (forexample, presence or absence of subsystem label 172, orof the master/slave bit 17 in label 172). In this case, noassociated input discrete is required.

Port pairs may be assigned in the software and use aninput discrete to determine the master or active unit.Typically, this discrete would be controlled by aircraftswitching.

Two ports may be operated either as single subsysteminputs or as a port pair depending on the state of an inputdiscrete or “program pin”. In this case, if the program pinindicates a port pair, then determination of the master oractive unit will most likely use automatic detection or becontrolled manually on the subsystem menu page.

c-1

c-1



COMMENTARY

Manufacturers should carefully consider the potentialfor subsystem failure modes if the automaticdetection of master or active unit is selected. Forexample, if neither unit in a dual unit subsystemdeclared itself to be the master or active unit, thenpilot access may be denied. This method ofdetermining the master or active unit may be moreappropriate only for lower priority and/or non-essential subsystems.

Attachment 10, MCDU Display Considerations,provides guidance for subsystem-generated menupages when dual subsystem devices are installed.

3.7 System Communication

Communication between the MCDU and the avionicssubsystems should be accomplished by serial digital datatransmission described in ARINC Specification 429.Specific system interconnection and data transfer protocolare described below. See Attachment 2 for MCDUAddress Labels (MALs), Attachment 3 for Word Formatsand ARINC Specification 429 for System Address Labels(SALs).

These sections describe the MCDU digital protocol as itrelates to the initialization data for subsystem interfaceswith the MCDU (Section 3.7.1), generation of the MCDUMENU page display (Section 3.7.2), and non-MENUcommunication with active or inactive systems (Section3.7.3).

3.7.1 Subsystem and MCDU Identification

The MCDU should monitor its ARINC 429 input portsfrom the aircraft subsystems and decode the 32-bit wordidentified by octal label 172. This word will contain theSystem Address Label (SAL) of the avionics in bits 9-16and will be transmitted at approximately one secondintervals. See Attachment 3 for word layout.

The MCDU should transmit its MCDU address label(MAL) to an aircraft subsystem using the subsystemsSAL in the address field of the “ENQ” word. Thespecific data communication sequence should be asdescribed in the following sections. See Attachment 3 forthe “ENQ” word layout.

3.7.2 Menu Generation

3.7.2.1 Initial Menu

The MCDU should attempt to obtain the text for theMCDU menu from the subsystems. The maximum textlength should be 18 characters, with the exceptiondescribed in Section 3.7.2.3.

Subsystems on the MCDU menu should be listed in orderby port number. If a port does not respond properly or isnot active, a space should be left in the menu list. NOTE:when FMCs/GN(L)Us are connected to ports #1 and #2only a single FMC/GN(L)U menu should be shown sinceonly one FMC/GN(L)U would be active at a time.

3.7.2.1.1 Addressing and Responses

Upon power-up the MCDU should attemptcommunication with aircraft subsystems after a delayperiod of thirteen seconds.

COMMENTARY

The delay was defined to allow aircraft subsystemsto execute BITE routines and other functionsassociated with their initiation upon power-up. Tenseconds is considered adequate time for thesubsystems to stabilize and three additional secondsto start sending their System Address Label (SAL)identification (label 172) to the MCDU.

This Characteristic does not attempt to specify theactual sequence in which the MCDU will start initialmenu interrogation of the individual subsystems.Depending on internal circuitry, different MCDUscould interrogate them sequentially. If a sequentialmethod is used, it is recommended that the highestpriority port be interrogated first in order that the“first page” of the priority subsystem can bedisplayed as soon as possible.

The MCDU should monitor the input ports for wordsidentified by octal label 172 and determine the subsystemSAL therein. After receiving the valid word, the MCDUshould send an “ENQ” command coded for a Menu TextRequest and with the label field set to the subsystemSAL A “Request to Send (RTS)” with the MCDU’s MALin the label field and coded for Menu Text Request would be the normal response of the subsystem. TheMCDU should respond with a “Clear-To-Send (CTS)”.The subsystem and MCDU’s RTS and CTS responsesshould be as defined in the communication protocoldescribed in Section 3.7.3.2 of this Characteristic.Communication with the subsystem should continue withdata words and an end-of-transmission word until themenu 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) issuccessful, then the MCDU should send another “ENQ”word as soon as possible coded for “normal”communications with the priority subsystem as describedin Section 3.7.3.2. The “first page” of the highest prioritysubsystem should be presented on the MCDU displayafter “normal” communication has occurred.

COMMENTARY

The original version of ARINC Characteristic 739defined bits 17-24 of the RTS word to be set to zero.Supplement 1 to ARINC 739 defines bits 17-20 tobe used to distinguish between a response to anormal request and menu text request (seeAttachment 3). All MCDUs designed to conformwith ARINC Characteristic 739A should encode theRTS word accordingly.

The preferred implementation of the RTS word is theversion specified by this Characteristic. MCDUmanufacturers should exercise caution as somesubsystems have defined their protocol using the



3.7.2.1.1 Addressing and Responses (cont’d)

COMMENTARY (cont’d)

original version of the RTS word defined in ARINCCharacteristic 739.

If after thirteen seconds “normal” communications hasnot been established for ports #1 or #2, then “normal”communications should be attempted for the next highestpriority port that had completed the menu textinterrogation successfully. If after one additional second,“normal” communications cannot be established with thatsystem, the next highest priority system should beattempted. This procedure should be repeated until“normal” communications has been established with asubsystem.

3.7.2.1.2 Protocol Timing and Responses

During initial menu text interrogation, if on an input porta 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 onesecond after the MCDU sends the initial “ENQ”, then asecond “ENQ” should be sent. If unsuccessful, a third“ENQ” should be sent one second later. One second afterthe third (unsuccessful) “ENQ”, the MCDU shouldassume that the subsystem is faulty. However, once themenu has been created, the MCDU should attempt themenu text interrogation with the non-responding systemperiodically (every 10 to 60 seconds).

After a long-term power interruption, the procedure inthis section should be repeated.

3.7.2.2 Menu Changes

Subsequent to the creation of the initial menu, aircraftsubsystems operating with the MCDU may be turned onor off by the crew’s use of breakers or by some abnormalcondition. The following text describes the desiredMCDU reaction in such abnormal situations.

After the initial menu has been established and label 172is lost from a subsystem for three seconds, the MCDUshould consider that subsystem to be inoperative andshould not attempt to communicate with the system. TheMCDU should remove (or flag) the text on the mainmenu for that particular subsystem.

If label 172 suddenly appears on an MCDU input busafter the initial menu has been established (whether or notthe communication had previously been established), theMCDU should attempt to establish the subsystem on themain menu using the “Initial Menu” procedure describedabove.

COMMENTARY

The ability to change menu dynamically has beenprovided to handle abnormal situations. A typicalsituation is that the crew may have elected to keep asystem turned off until after take-off. If the menucould not be changed after the initial menu routine

was performed, a system powered up later would notbe able to communicate with the MCDU.

Similarly, a system experiencing intermittent problemscould reestablish communication with the MCDU as itshealth permits. Although it may be considered a nuisanceby the crew to have a main menu item disappear andreappear from time to time, it alerts them that a problemdoes exist with that system.

3.7.2.3 Alternate Menu

An alternate menu display format should be used forMCDUs designed for back up navigation data, radiocontrol, and display control. The alternate display formatis described in Section 4.2.1. The display menu should becapable of listing all menu items. It is recommended thatthe MCDU display contain menu items on both sides ofthe page to accommodate the maximum number ofselectable functions and modes. The text for each menuitem should be limited to eleven characters. Two menuitems per line is permitted, and each menu item should beselected by its respective pushbutton switch, (i.e., itemselected by left button and right menu item selected byright button).

COMMENTARY

The MCDU should be capable of accommodating upto 18 characters of menu text. In some instances, theavailable field length may be less than 18 charactersand the description of such menu items may need tobe shortened to fit in the available space.

3.7.3 Data Communication

The following sections describe the protocol whennormal communication is desired between an MCDU andan aircraft subsystem.

3.7.3.1 Subsystem Initiated Message

ACARS/CMU and the FMC/GN(L)U are systemstypically wanting to send a message to the MCDUwithout a crew-initiated request. The following sectionsdescribe 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, butis not in “active” communications with the MCDU and ithas a message for the MCDU, it should send a “Requestto Send” (RTS) to each MCDU using the “MCDUAddress Label” (MAL) in the label position of the dataword (bits 1-8) and coded for a “normal request”. If thesystem is connected to three MCDUs, it should send theRTS three times successively (once for each differentMAL). When the MCDU is not in active communicationwith that subsystem, this “RTS” message should cause theannunciator lights on the MCDU to come on to alert thecrew of a message waiting and should cause the MCDUto display the request status described in Section 3.4.2when the MCDU menu is on the screen.

The MCDU should respond to a “RTS” within 200milliseconds with a “CTS” with the “Maximum RecordCount” set to zero. The subsystem should wait until an“ENQ” is received from the MCDU. The MCDU should

c-1



then use the procedure described in Section 3.7.3.2 toinitialize communications with the “requesting”subsystem.

After an “ENQ” is received from a MCDU, the subsystemshould send a Discrete Word (DC4) to the other MCDUswith the appropriate clear request bit set, as defined inAttachment 3. The clear request should extinguish theannunciator light and then delete the request status fromthe associated subsystem name on the MENU page. Theclear request bit should remain set (to “1”) for eachMCDU until an “ACK” is returned from the respectiveMCDUs.

3.7.3.1.2 Active Subsystems

When the MCDU is already in active communicationwith a subsystem and a “RTS” is received from thesubsystem, the MCDU should send a “CTS” containingthe maximum number of records receivable and thesubsystem’s SAL. A zero in the maximum record countshould cause the subsystem to wait for a valid “CTS”word for up to one second at which time the messageshould be dropped.If the maximum record count in the“CTS” word is non-zero and less than the record count inthe “RTS” word, the “RTS” should be repeated every 200milliseconds after each invalid “CTS” word up to tentimes before dropping the message.

If a “CTS” word is not received from the MCDU within200 milliseconds, the subsystem should repeat the “RTS”word. The “RTS” should be repeated 10 times withoutreceiving a “CTS” before dropping the message.

The subsystem upon receiving a valid “CTS” wordshould send its transmission to the responding MCDUusing the “STX” word and continue as described inSection 3.7.3.3 of this Characteristic.

3.7.3.2 MCDU Communication with InactiveSubystem and Data Request

When a new subsystem is selected via the MENU page orspecial function key, the MCDU should repeat a“LOGOFF” word to the already active subsystem every200 milliseconds for 1 second or until an “ACK” word isreceived and then send an “ENQ” with the new SAL, itsMAL and coded for a Normal Request. On power-up thelogoff is not needed (see Section 3.7.2.1). The subsystemshould respond with a “RTS” within 200 milliseconds.

COMMENTARY

Some MCDUs may be designed to ‘hold’ the prioractive user obviating the need to “LOGOFF” thecurrent active user. This avoids the time required to“LOGOFF” the active user and reinitiatecommunication using “ENQ” if the ‘held’ user issubsequently returned to. If a system is in a ‘held’state, then this status should be reflected on the menupage. This operation can be beneficial when thesystem architecture dictates that the crew mustfrequently toggle between two of the user systems.

If no “RTS” is received within 200 milliseconds, theMCDU should repeat the “ENQ” message every 200milliseconds until a “RTS” is received or a period of onesecond has elapsed since the first “ENQ”. If no response

is received, the MCDU should indicate a “time-out” onthe display. In a power-up condition the next prioritysubsystem should be attempted.

In response to a “RTS” the MCDU should send a “CTS”with the maximum record number and the subsystem’sSAL. The normal subsystem response would be the“STX” providing the initial data as described in Section3.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 millisecondsafter each invalid “CTS” word up to ten times beforedropping 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 and3.7.3.2 for message initialization. Every “STX” wordshould contain the “record word count” to designate thenumber of ARINC 429 words comprising a record (onerecord for each line of text). The count should be thenumber of words between the “STX” and “EOT/ETX”words inclusive. The “record sequence number” shouldindicate 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 wordsand one or more data words. The last word of a recordshould use the “ETX” word and should repeat the “recordsequence number. Unused character positions at the endof a record prior to record sequence number andEOT/ETX should be padded with zeros. The last word ofthe last record should use an “EOT” word in place of the“ETX” to designate the end of the message. Followingthe successful reception of a complete message, theMCDU should send an “ACK” within 1.5 seconds.

During the subsystem transmission of a message, if aparity check fails or expected word counts and actualword counts are not equal, the MCDU should send a“NAK” word containing the subsystem’s SAL and therecord sequence number of the record exhibiting theproblem. The subsystem should complete itstransmission and attempt to repeat the NAKed portion ofthe message by using the subsystem initializationprocedure described in Section 3.7.3.1. The MCDUshould retain the valid records.

If an “ACK” or “NAK” is not received by the subsystemwithin 1.5 seconds, the subsystem should repeat the entiremessage starting with the first “STX” word. The messageshould be attempted three times before discontinuingfurther transmission of the message.

If no data words containing the remaining portion of themessage are received for a period of 200 milliseconds orthe MCDU becomes “confused” in the word countingprocess, a “SYN” word should be sent to the subsystem.The subsystem should discontinue its message, attempt a



3.7.3.3 Message Transfer (cont’d)

“RTS” as described in Section 3.7.3.1.2 and repeat theentire message. If three successive “SYN” words arereceived by the subsystem, it should drop the message.

COMMENTARY

A “SYN” differs from a “NAK” in that the MCDUcan recover portions of the message by using the“NAK”. “SYN” announces to the subsystem thatessentially no portion of the message is recoverableand that the entire message must be retransmitted.However, for the purpose of error processing, thereis virtually no difference between “SYN” and“NAK” responses.

3.7.3.4 Control (CNTRL) Word

The control word should specify the initial characterposition, the color, the font and the line number at whichto start filling the MCDU display. This word may berepeated within a record as necessary. The Display fieldidentifies the characteristic of displayed characters, e.g.,reverse video, underscore, blinking. See Attachment 3for bit assignments.

COMMENTARY

Not all displays, due to inherent design limitations,have the capability to provide all of the specialdisplay effects designated by the bits of the controlword. Care should be taken in subsystem design toensure that operator confusion does not occur if anyspecial display effect cannot be produced by theMCDU.

3.7.3.5 Data Word

The data word should specify up to three characters of theset listed in Attachment 4. Carriage return or line feedshould not be sent. The control word should be used toaccomplish these functions.

3.7.3.6 Background/Vector Words

The Standby Navigation capability described in Section4.2.3 includes an optional map display interface. Section3.9 of this characteristic describes the interface standardswhich will enable the MCDU to be used with anymanufacturer’s electronic display, designated ElectronicFlight Instrument (EFI) herein.

3.7.3.7 Discrete Word

A discrete word identified by “DC4” should be sent asneeded from the subsystem to all MCDUs at one secondintervals. It informs the MCDU of the self-test status ofthe subsystem and provides the MCDU with commandsto blank the display/buffer, extinguish the FMCannunciator light and extinguish the MCDU menu light.The MCDU after recognizing a bit set for a command andexecuting it should send an “ACK” to the subsystem atwhich time the subsystem should discontinue sending the“DC4” word to that MCDU.

COMMENTARY

Since the “DC4” word addresses each MCDUindividually, the word would not completelydisappear from the subsystem output bus until allMCDUs have responded.

The blanking displays and buffers capabilities havethe following intent. When a DC4 word is receivedwith the clear display buffer bit set, the MCDUshould clear the input memory buffer used to updatethe active display buffer. The current MCDUdisplay should not be affected by clearing this buffer.This capability could be applied in cases where thereis 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 screenbit set, the MCDU should blank the display viahardware or by the active display buffer Theblank screen capability could be used in betweenpage changes to provide a more visible indication ofa display page change.

3.7.3.8 Button Push Word

The button push word identified by DC1 in bits 19-25should be sent by the MCDU in response to allalphanumeric, mode keys, and select enter button pusheson the MCDU. The exceptions are that the “MCDUMenu” button and the “line select” keys (while in theMain Menu Mode) will not generate a button push word.The pushbutton code field should contain the code for thebutton pressed. The valid codes are highlighted inAttachment 4. The sequence number field ranges from 0to 15 decimal and should be incremented for each newkey pressed. A retransmission of a button push shouldhave the same sequence number as the previoustransmission. The repeat field is normally a zero andshould be set to one key if a key is held continuously forone second. If the key is held for greater than one secondthe button push word should be repeated at a one secondrate with this indicator set. Note that a button pushwithout the repeat indicator set should always precedeone with the indicator set.

The button push word should always be ACKed by thesubsystem unless a parity error is detected. In this casethe subsystem should send a “NAK” and the MCDUshould repeat the word. If an “ACK” is not receivedwithin 200 milliseconds the button push word should berepeated.

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 optionallyannunciating) faults or failures which can occur withinthe MCDU. 90% BITE coverage should be a designgoal. BITE should operate continuously during flight.Monitoring should be automatic and BITE should havethe capability to test, detect, isolate and identifyintermittent and steady state failures. BITE shoulddisplay system conditions and indicate the presence of afault upon the activation of self-test described in Section3.8.3. The design should minimize the effect of BITEfailure on normal MCDU operation.



3.8.2 BITE Display

BITE information may be made available on a low speedARINC 429 bus for use in the centralized fault display asdescribed in ARINC Report 604, “Guidance for Designand Use of Built-In Test Equipment (BITE)”. AlternateMCDUs could be used to display BITE data to the flightcrew or maintenance technician while controlling BITEfrom another unit.

3.8.3 Self-Test

At the time of MCDU turn-on, a power-up self-testshould be automatically initiated as described in ARINCReport 604. Failure conditions should be displayedwhere possible on the MCDU display.

COMMENTARY

It is highly desirable that subsystems that aresoftware loadable consider including in theirsoftware kernal the ability for an unloaded unit toindicate its unloaded state on the MCDU. Thisindication could be on the MENU page or asubsystem page depending on the extent of thesoftware kernal in the subsystem.

3.9 Electronic Flight Instrument System Interface

The standards in this section represent a subset of thosedescribed in ARINC Characteristic 702A. This sectionaddresses the unique subset requirements for the MCDU,leaving ARINC 702A as the complete standard for theEFI interface.

3.9.1 MCDU Outputs to EFI

The MCDU should provide one high speed ARINC 429output port for an EFI.

Dynamic data is comprised of ARINC 429 labelled dataand may include situational information such as time togo, distance to go, desired track and cross track distance.

3.9.2 MCDU Inputs from EFI

The MCDU provides one low speed ARINC 429 datainput port through which map mode, scale and optionselections 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 flightplan information from the FMC/GN(L)U.

3.9.4 Flight Plans and Guidance

If the MCDU is capable of receiving information from anFMC, the flight plan data will consist only of fixes, fixidentifiers, vectors and conics. The data sequence oflines and conics will be represented by great circle pathsbetween waypoints and a curved transitions between thefirst path legs only. The MCDU may contain guidancealgorithms which generate the guidance commands to aflight control system to track the flight plan.

3.9.5 Map Display Edit Area

The MCDU may limit the data sent to the EFI to thatneeded for the viewing window. Editing should only beconsidered if there is a likelihood of MCDU dataexceeding the size of the map data block.

3.9.6 Background Data Prioritizing

The MCDU background data priority should be asfollows:

1. Primary Flight Plan2. Flight Plan changes3. Waypoints

3.9.7 Data Type Word Formats

The data type word formats specified in Attachement 6 ofARINC 702A should apply for the MCDU. However, theonly data type identification codes expected to be usedare as follows:

Octal Label Parameter

000 Fill-in Words014 Discrete Word-Range070 Active Standard Waypoint plus Identifier100 Vector-Active Flight Plan164 Map Reference Group-Longitude264 Map Reference Group-Latitude300 Vector-Active Flight Plan Changes301 Start of Transmission302 End of Transmission303 Start of Dynamic Data330 Standard Waypoint plus Identifier364 Discrete Word-Map Mode

3.9.8 Flight Plan Retention

The MCDU should be designed to provide the capabilityto retain the flight plan during power loss of up to 10seconds.


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 providealternate navigation data source, back-up navigation radiomanagement, and back-up display control. Attachment 9illustrates optional functions of the MCDU which wouldbe used in addition to the basic functions.

As an option, the MCDU may perform the followingspecialized functions in addition to the multi-purposeoperations currently defined in the previous sections ofthis Characteristic. If the MCDU implements thesefeatures, they should be performed as specified herein.

a. Standby frequency and tuning control for navigationradio systems such as VHF Omni-Range (VOR),Distance Measuring Equipment (DME), AutomaticDirection Finder (ADF), Instrument Landing System(ILS), Microwave Landing System (MLS).

b. Independent (stand-alone) navigation with thecapability to support the display of simple map on adisplay system using position data from the InertialReference System (IRS) and/or GNSS receiver orGPIRU.

The availability of the standby navigation mode ofoperation provides the ability to improve dispatchreliability and minimum certification requirementsfor dispatch with long range navigation equipment.

c. Mode and selection controls for Electronic FlightInstrument System (EFIS) and Engine Indication andCrew Alerting System (EICAS).

COMMENTARY

Future updates to this Characteristic may include theneed 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 inthe MCDU display of a menu page, listing the interfacingsystems and available alternate modes. The MCDUshould generate the MENU page title, page numbers, lineheaders, 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 analternative to the radio tuning capability provided as partof a dedicated radio management panel. Navigation radiotuning should be integral to MCDU design where allnormal radio management is accomplished by a FlightManagement Computer (FMC). The navigation radiotuning page should be accessible via a dedicated functionbutton appearing on the FMC pages of the MCDU.

4.2.2.2 General Operation

The MCDU radio tuning data should be sent to theappropriate transceiver via a dedicated tuning busfollowing the activation of the standby radio tuning mode.

The MCDU should be capable of retaining selectedportions of the last FMC transmission of data when thestandby tuning mode of operation has been activated. TheMCDU monitors its Source Destination Identifier (SDI)pins to determine which corresponding radio data will becontinued to be displayed and transmitted. The tuningpage should display information which indicates thetuned frequency, course, mode, etc., as well as theauto/manual/remote tuning status of the radios.

COMMENTARY

The MCDU should monitor its SDI pins todetermine when and if a function should be active.For example, the MCDU would inhibit the back upnavigation, radio tuning and EFIS/EICAS displayfunctions for MCDU installations which supportmaintenance systems only.

The MCDU should continue to maintain the correct datastatus and transmit data to the radios following theselection of any other MCDU menu or functions.

4.2.2.3 Navigation Tuning Page Functions

The navigation radio page should provide the capabilityto tune VOR, ADF, ILS and MLS ground stations. Thepage format should include the display of line headerssuch as VOR, ADF, ILS-MLS, etc. as appropriate for thespecific radio being tuned.

Valid data entry should be monitored on the basis offrequency range, course azimuth, elevation, andincrement as appropriate for each radio type. Validentries may also be accompanied by an indication that itis a manual selection (this would provide consistencywith an FMC radio page which will provide bothautomatic and manual selection indications). Incorrectentry to the MCDU should result in the display of anINVALID ENTRY message. Deletion of an ILS/MLSentry should result in reversion to the PARK mode.

For ADF radios the MCDU should be capable ofcommanding the Beat Frequency Oscillation (BFO),Antenna (ANT), and ADF modes.

For ILS or MLS receivers the MCDU should be capableof determining radio type automatically from manualentry.

The MCDU should have the capability to determineDME frequency pairing with VOR, ILS or MLS by usingthe mode data from external sources such as EFIS controlpanel 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 selectedILS/MLS frequency when a tune inhibit condition exists.It is expected that this condition would exist only duringauto-land conditions.

4.2.2.4 Interface Requirements

The MCDU should transmit radio tuning data on adedicated low speed ARINC 429 output port. Inaddition, the MCDU may provide the following discretes:

a. L-DME and R-DME audio discretes where an openstate represents DME paired with VOR, and aground condition represents DME paired with ILS orMLS.

b. ILS/MLS select discrete where an open staterepresents ILS station selected and a groundcondition represents MLS station selected.

c. ILS/MLS PARK discrete where an open staterepresents NOT PARK and a ground conditionrepresents PARK. An external source should be ableto inhibit changes to ILS/MLS tuning (i.e., duringautoland) using the PARK discrete.

d. Normal/Standby to enable radios to determine whichinput port to select for tuning control.

The MCDU should have the capability to receive andprocess the following analog discretes:

a. ILS Tune Inhibit

The radio tuning command and digital discrete datawords generated by the MCDU should conform to theguidelines of the appropriate ARINC Characteristics towhich the radio is designed.

COMMENTARY

The analog discrete interfaces described hereinshould also have corresponding digital discretes toallow for appropriate flexibility for variousinstallation configurations. In addition, analogdiscretes such as PARK may not be necessary if thebackup radio control design automatically defaults tofull featured operation in order to avoid exposure toany other faults.

4.2.3 Standby Navigation

4.2.3.1 Mode Selection

The standby navigation mode, if provided, should becapable of being activated either manually by crewintervention, or automatically, if for example, the MCDUdetects a failure in the selected FMC/GN(L)U. TheMCDU should monitor the activity of the selected

FMC/N(LG)U data bus to determine when the loss ofactivity occurs.

COMMENTARY

Provision of a manual activation capability in theMCDU should be given careful consideration tofactors such as: a. clear and unambiguous indicationsthat the standby capability is being used; b. means toensure no potential confusion by flight plan changesin the standby mode which are not reflected in theFMC/GN(L)U; and c. a means to return to normaloperation 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 asindependent (stand-alone) navigator using the InertialReference System (IRS) and/or a GNSS receiver or aGPIRU as the means of navigation.

COMMENTARY

When multiple positioning sources are allowed, itmay be necessary for the MCDU to provide anindication of it’s navigation source, depending on thesystem integration and implementation.

4.2.3.2.2 Navigation and Guidance

Under normal operation each MCDU receives flight plandata from its onside FMC/GN(L)U, consisting of activeroute waypoint latitudes/longitudes and waypoint names.If there is a valid FMC/GN(L)U available the MCDUshould receive an update to a flight plan upon sequencingthe active waypoint or following the activation of amodification to a flight plan (i.e., direct-to, approachchange, waypoint deletions/additions, etc.).

When the standby navigation mode becomes active due tothe detection of an FMC/GN(L)U failure, the MCDUshould use the last received FMC/GN(L)U flight plan andIRS/GNSS data to maintain an active standby flight plan.If the MCDU detects no valid IRS or GNSS input whenthe standby navigation mode becomes active, it shouldgenerate an appropriate failure indication by removingthe affected MCDU page display or by disabling accessto the affected page. When operating in the standbynavigation mode, the MCDU should allow only flightplan changes using direct-to waypoint, entered and lineselected lat/long waypoints, line select closure ofdiscontinuities, and line selected insertion and deletions.Direct-to selections should be made by line selection of awaypoint identifier or lat/long on the appropriate MCDUpage.

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 ofdisplay pages for flight plan data, radio tuning and flightprogress status, as appropriate.

When the MCDU standby navigation mode is activated,all purely FMC/GN(LU) push button functions shouldbecome inoperative. The MCDU pages which display



4.2.3.2.3 CDU Page Access (cont’d)

standby flight plan data generated by the standbynavigation function should be available, but should beclearly identified as displaying standby data. The standbyflight plan data pages should be displayed in response tothe corresponding MCDU function keys.

With an invalid FMC/GN(L)U, the selection of a functionkey, which would normally be used to access an activeflight plan related page, should provide direct access tothe active standby navigation pages.

The desired course to the current active waypoint, asdisplayed on the active standby flight plan related pages,should be referenced to magnetic north if IRS magneticreferenced data is available. Otherwise, the course to anywaypoint should be displayed relative to true north. A Tor M should be displayed by all course information todenote the reference being used.

COMMENTARY

It may be desired that the course indications (M orT) be selected by a program pin. One possibleapproach is that a ground (logic “0”) represents alltrue heading courses and logic “1” representsmagnetic heading for desired course and blank forall others.

4.2.3.2.4 Navigation Computations

The MCDU should be capable of generating informativenavigation parameters for display on its own screenand/or transmitted to other displays as specified by theoperator. The parameters, specified by the operator, aregenerated using data primarily from the IRS and/or aGNSS receiver, and the flight plan most recently receivedfrom the FMC. The standby navigation function mayprovide for integration of the inertial and GNSS sensordata in a manner that allows “coasting” throughtemporary loss of GNSS information. The parameterscomputed by the standby navigation function may includeany or all of the following, or others as determined by therequirements 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 routewaypoints (if GNSS data is unavailable), otherwiseestimated 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 tothe guidelines established by SC-181 MASPS for RNPNavigation. The standby navigation function, at aminimum, 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 rateappropriate to the data’s function, using inputs from theIRS and/or GNSS receiver, and the last FMC cross-loadflight plan data. The data will be available for advisorydisplay and other functional use when the standbynavigation mode is active.

4.2.3.2.5 Map Display

The MCDU may be capable of generating formatted datawhich can be used by an EFIS type system to generate amap display on the Navigation Display (ND) unit. Mapdata should be consistent with vectors, waypoints,identifiers, etc., as computed by the FMC/GN(L)U. TheMap Display interface should be as described in Section3.9 of this Characteristic.

The EFIS and the MCDU may be configured in a varietyof ways to effect a map display on the ND which isresponsive to the selected mode and range commands.One preferred way is for the MCDU to receivemode/range commands directly from the EFIS controlpanel and transmit map data to the EFIS accordingly. Inthis case the MCDU may have the capability of providinga page to serve as backup to the EFIS control panel if itfails.

Another preferred way is to configure the EFIS and theMCDU such that the MCDU transmits the entire flightplan as most recently received from the FMC, and theEFIS produces the map display in accordance with themode/range commands received from the control panel.The MCDU, in this case, does not necessarily have thecapability of providing backup EFIS control panelcapability.

If GNSS data is available, the standby navigation functionshould compute and display ETAs associated withwaypoints and destination, otherwise the time should bedisplayed as the Time To Go (TTG) when in the StandbyNavigation mode.

4.2.3.3 Interface Requirement

The MCDU should process data received from adedicated Inertial Reference System (IRS) and/or GNSSreceiver or GPIRU. Additionally, the MCDU should bedesigned with the capability to process the same dataformat transmitted on the current FMC/IRS hi-speedARINC 429 interface.



The MCDU should monitor the status of the analogdiscrete interface to determine the selection of thestandby navigation mode, by an open/ground indication.It should be capable of processing mode and rangereceived 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 verticaldeviation to no-computed data when the standbynavigation mode has been activated.

4.2.4 Alternate EFIS Control

4.2.4.1 General

The MCDU may provide the capability to generateMENU selectable display pages as an alternate to theEFIS control panel. The alternate EFIS control panelpage function should automatically activate when a totalbus loss has been detected for an EFIS control panelinput. When the failure is detected, the MCDU shouldinitialize its EFIS control panel pages using the lastprocessed EFIS panel selection. The page data caninclude 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 amenu prompt on the MENU page. The MCDU shouldrestrict page access based upon the bus status of the EFIScontrol panel (CP) input. If the EFIS CP is valid, theMCDU should have the capability to list the EFIS controlitem but preclude page access. If the EFIS CP is invalid(loss of all data activity for one second), the EFIS controlfunctions should automatically become active and pageaccess should be allowed. Access between the EFIScontrol panel pages will be provided by line select keyprompts on each page.

The MCDU should automatically return to the MENUpage if an alternate EFIS control panel page is beingdisplayed and the EFIS CP bus becomes valid for onesecond. If an alternate EFIS control panel page is notbeing displayed, the MCDU page display will not beaffected.

The NEXT/PREV keys should be the only function pushbuttons associated with the ALTN EFIS CONT page.

COMMENTARY

The page access restriction is intended to prevent theselection of different conflicting modes, ranges, etc.,if both the EFIS CP and MCDU were availablesimultaneously. The unnecessary complication ofback-driving the primary unit (EFIS CP) from theback-up MCDU is thus avoided.

Consideration should also be given to the busfail/page access criteria. An alternate approach is tohave the MCDU monitor selected parameters. Forexample, if the barometric altimeter data word hasno-computed-data, or failure warning sign status,only access to the EFIS control panel pages wouldbe allowed.

4.2.4.3 Interface

The MCDU should transmit the alternate EFIS controlpanel page data on its display control panel bus. Datatransmission will begin when the page function becomesactive. Data transmission should cease if the EFIS CPbecomes valid for one second.

The digital data characteristics should be the same as theoriginal EFIS control panel inputs.

COMMENTARY

A good design approach would consider automaticbus switching within the MCDU. With this design,if the EFIS CP is valid, the MCDU will pass theEFIS CP data directly onto its control panel bus. Ifthe MCDU detects the loss of data for one second,its bus monitor should then switch control of the busto its internal control panel function.

4.2.5 Alternate EICAS Control

4.2.5.1 General

The MCDU may provide the capability to generateMENU selectable display pages as an alternate to theEICAS control panel. The alternate EICAS control panelpage function will become active automatically when theMCDU detects a total bus loss for its control panel input.The MCDU will initialize its alternate EICAS controlpanel pages for no selections.

4.2.5.2 Page Access

The EICAS MODES page should be accessible only bythe menu prompt on the MENU page, after a loss ofcontrol panel input is detected. Access between theEICAS MODES and SYNOPTICS pages should beprovided by line select key prompts on each page.

The MCDU should automatically return to the MENUpage if an alternate EICAS control panel page is beingdisplayed and the control panel bus becomes valid for onesecond. If an alternate EICAS control panel page is notbeing displayed, the MCDU page display should not beaffected.

The NEXT/PREV keys should be the only function pushbuttons associated with the ALTN EICAS CONT page.

4.2.5.3 Interface

The MCDU should transmit the EICAS page data on itsdisplay control panel bus. Data transmission will beginwhen the page function becomes active. A MCDUmaintenance word, label 351, should be the discrete wordwhich is transmitted to the EICAS to indicate that a non-selected system is requesting attention.



4.2.5.3 Interface (cont’d)

COMMENTARY

System integrators may find it desirable to utilize ananalog discrete interface to identify requestingsystems on the EICAS. If implemented, the analogdiscretes signals should utilize pins 31-33 andidentify them as FMC Request, ACARS Request,and Menu Request respectively.

The MCDU should suspend transmission of data if itscontrol panel bus becomes valid for one second. TheMCDU should respond to mode function line selectionsby momentarily setting the appropriate digital discrete fora period of one-half to one second.

The digital data characteristics should be the same as forthe original EICAS input data.

Similar to the alternate EFIS controls, the MCDUdesigner should consider automatic bus switching in theMCDU.

4.2.6 System Communication

4.2.6.1 Inter-System

The handshake and digital data transfer communicationbetween the MCDU and all other interfacing avionicssystems (including the FMC) should be based on ARINC4.2.6.1 Inter-System (cont’d)

Specification 429, “Mark 33 Digital Information TransferSystem (DITS)”.

COMMENTARY

The MCDU should be able to receive updates to itsflight plan and/or radio tuning data even when it isunder active control of another system. It isrecommended that this be accomplished by the useof a priority level such as the system ID labels. Eachbroadcast label should be the initial word of a blockdata transmission. This approach will allow theMCDU to have essentially transparent foregroundprocessing of flight plan and/or radio data whichmay occur concurrently with the basichandshake/log-on protocol.

4.3 Hardware Requirements

4.3.1 General

The following enhancements to the existing ARINCCharacteristic 739A would enable the MCDU to providefunctions of radio tuning and standby navigation.

4.3.2 Interwiring Definition

If the functions described in Section 4 of thisCharacteristic are implemented in the MCDU, it shouldhave two interwiring connectors.

The basic connector is described in Section 2.2. Anadditional connector should be provided for the interfacesand physical/functional isolation required for radio tuningand standby navigation functions. The optional connector

is also defined in Section 2.2. The pin assignments forboth the Basic Connector and Optional Connector aredefined in Attachment 1.

4.4 Standby Navigation Lateral Guidance

Some users may desire the MCDU to compute a lateralsteering signal for use by the Flight Control Computers(FCC). The steering signal should be continouslycomputed when there is an active waypoint identitifed.The steering signal should be based upon the samecontrol laws as used for lateral steering in the FMC,considering cross-track deviation, track angle error,ground speed and track intercept. Lateral turnanticipation should be included for waypoint transition.The data should be transmitted on a low-speed ARINC429 bus in the same format as that produced by the FMC.

COMMENTARY

It should be noted that the aircraft systemarchitecture, operating modes and configurations,failure rates, undetected failure rates, and systemsafety assessment are among the considerationsnecessary to determine when and how thesecapabilities may be utilized.


ATTACHMENT 1STANDARD INTERWIRING

BASIC CONNECTOR:

FUNCTION MCDU AIRCRAFT WIRE I-R [5]

Future Spare 1 oOnside FMC A 2 o Onside FMC D-5Onside FMC B 3 o (High Speed) D-5Future Spare 4 oOffside FMC A 5 o Offside FMC D-5Offside FMC B 6 o (High Speed) D-5Future Spare 7 oInput Port #3 A 8 o Aircraft D-5Input Port #3 B 9 o Subsystem D-5Future Spare 10 oInput Port #4 A 11 o Aircraft D-5Input Port #4 B 12 o Subsystem D-5Future Spare 13 oInput Port #5 A 14 o Aircraft D-5Input Port #5 B 15 o Subsystem D-5Future Spare 16 oInput Port #7 A 17 o Aircraft D-5Input Port #7 B 18 o Subsystem D-5Future Spare 19 oFuture Spare 20 oFuture Spare 21 o28 VDC Inst. Power C 22 oProgram Return 23 oInput Port #6 A 24 o Aircraft D-5Input Port #6 B 25 o Subsystem D-5Shield Ground 26 oOutput Port A 27 o Aircraft D-5Output Port B 28 o Subsystem D-5Act Port Prog 29 oCDU Location 30 oCDU Location 31 oCDU Fail Discrete 32 oLamp Test 33 oChassis Ground 34 o DC Ground 1-0.1Ann. Bright/Dim Hi 35 oAnn. Bright/Dim Lo 36 o5 Vac Light H 37 o 5 VAC Panel5 Vac Light C 38 o Light Supply28 Vdc Inst. Power H 39 o 2A115 Vac, 400HZ H 40 o 115 VAC 400 Hz 2-0.1115 Vac, 400HZ C 41 o Aircraft Power 2-0.1

]]]]]]]]]]]]

]]]]

]]]]]]


ATTACHMENT 1 (cont’d)STANDARD INTERWIRING

OPTIONAL CONNECTOR:

FUNCTION MCDU AIRCRAFT WIRE I-R [5]

Future Spare 1 oOnside IRU (GPIRU) A 2 o Onside IRU D-5Onside IRU (GPIRU) B 3 o (High Speed) D-5Future Spare 4 oEFIS Cont. Panel A 5 o EFIS Control D-5EFIS Cont. Panel B 6 o D-5Future Spare 7 oDisplay Output A 8 o Aircraft D-5Display Output B 9 o Subsystem D-5Future Spare 10 oGen. Bus Output A 11 o Aircraft D-5Gen. Bus Output B 12 o Subsystem D-5Future Spare 13 oEFIS Cont. Output A 14 o Aircraft D-5EFIS Cont. Output B 15 o Subsystem D-5Future Spare 16 oFuture Spare 17 oDiscrete Input (Spare) 18 oDiscrete Input 19 oDiscrete Input 20 oDiscrete Input 21 oFuture Spare 22 oDiscrete Input 23 oDiscrete Output 24 oDiscrete Output 25 oDiscrete Output 26 oDiscrete Input 27 oDiscrete Output 28 oFuture Spare 29 oDiscrete Input 30 oDiscrete Output 31 oDiscrete Output 32 oDiscrete Output 33 oFuture Spare 34 oOnside GNSS A 35 o GNSSOnside GNSS B 36 oFuture Spare 37 oFuture Spare 38 oFuture Spare 39 oFuture Spare 40 oFuture Spare 41 o

]]]]]]]]]]

]]


ATTACHMENT 1 (cont'd)NOTES ON STANDARD INTERWIRING

1. Pins 30 and 31 should be used for encoding MCDUposition in the aircraft and the appropriate MCDUAddress Label (MAL) for identification. Thefollowing encoding scheme should be employed onthe connector.

MAL PIN30 31

220 To Pin 23 Open221 Open To Pin 23222 To Pin 23 To Pin 23230 Open Open

2. When Pin 29 is open, the MCDU shouldcommunicate with the subsystem (FMC) on inputport #1. When Pin 29 is connected to Pin 23Program Return, the MCDU should communicatewith the subsystem (FMC) on input port #2.

3. A “ground” on pin 33 should cause a lamp test to beexecuted.

4. When the MCDU has detected an internal failure, aninternal ground should be made on pin 32.

5. The “I-R” values define the maximum current (I) inamperes and effective resistance (R) in ohms forwhich the installation and equipment should bedesigned. It is anticipated that installation designerswill use these figures, together with the lengths of thecable runs in a given airframe, to calculate the gaugeof each wire in the installation. Where theircalculations reveal the possibility of using highergauge numbers than #22 AWG, they are asked tostop and consider whether the mechanical strength ofthis wire is adequate for the installation beforedeciding to use it. The airlines report recent sadexperiences with such wire, and although they are, ofcourse, interested in the weight saving its use affords,they will quickly point out that these savings arerapidly nullified by maintenance costs if frequentbreakage occur.

NOTE: Wires for which a “D” symbol is shown inplace of a current rating may be used for any functionranging from “Dry Circuits” (hence “D”) to 5 ampereapplications.

Both installation and equipment designers shouldgive due regard to special cases wherein parallel orseries-parallel connected circuits may result in highercurrents or voltage drop (effective resistance) than insimple circuits. Unless otherwise noted, the currentlimit set forth applies to all elements of parallel orseries-parallel circuits.


ATTACHMENT 2ADDRESS LABELS

MCDU NO. MCDU ADDRESS LABEL (OCTAL)

1

2

3

4

220

221

222

230

NOTE: See Attachment 1 for MCDU number pin coding.


ATTACHMENT 3DIGITAL 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 1P 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 1P 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 1P STX 0 RECORD SEQUENCE

NUMBER0 RECORD WORD COUNT MAL

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 1P CNTRL F COLOR

SEEBELOW

LINENUMBER

FUNCTIONSEE

BELOW

INITIALCHARACTER

POSITION

MALMSB

BITS COLOR BITS FUNCTION16 15 1423

0

22

0

21

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


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 1P 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 1P 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 1P ETX 0 RECORD

SEQUENCE NUMBER0 MAL

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 1P EOT 0 LAST

RECORD NUMBER0 MAL

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 1P DC1 R PUSH BUTTON

CODE0 SEQUENCE

NUMBERSAL

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 1P DC1 F CHARACTER COLOR

SEEBELOW

INITIALCHARACTER

POSITION

MALMSB

BITS COLOR

16 15 14

0

0

0

0

1

1

1

1

0

0

1

1

0

0

1

1

0

1

0

1

0

1

0

1

BLACK

CYAN

RED

YELLOW

GREEN

MAGENTA

AMBER

WHITE



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 1P ACK/NAK 0 RECORD

SEQUENCE NUMBER0 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 1P 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 1P DC4 DISCRETE BITS

(SEE BELOW)MAL

MSB

BIT FUNCTION (when set to “1”) 9*10111213141516171819*

2021222324

Self-Test (Subsystem from which the MCDU receives the word is in self-test)Blank ScreenClear Display BufferClear FMC RequestClear Subsystem Request (not used with FMC and ACARS)Clear ACARS RequestEXEC AnnunciatorDSPY Annunciator Applies only to MCDUs with AnnunciatorMSG Annunciator - Receipt of logic “1” lights AnnunciatorOFST Annunciator - Receipt of logic “0” extinguishes AnnunciatorMCDU Test Request Receipt from allowed subsystem causes MCDU to execute self-test - Inputs to MCDU during self-test are ignoredSpareSpareSpareSpareSpare

* 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



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 1P ENQ 0 SEE BELOW MAL

MSBSAL

MSB

BITS FUNCTION

20 19 18 17

0

0

0

1

0

0

0

•

•

1

0

0

1

1

0

1

0

1

NORMAL REQUEST

MENU TEXT REQUEST

SPARE

•

•

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 SALMSB

SUBSYSTEM ID(LABEL 172)

Optional DataBit 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“3”

DECIMAL“9”

SUBSYSTEM ID(LABEL 377)

Optional DataBits 19&20 indicate selected FMC port of 1 or 2, where 20/19 = 0 1 = 1, 1 0 = 2Bits 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 17 6 5 4 3 2 1

P 0MCDU INPUT PORT

ACTIVE = 1

SDIOF

MCDUEICAS ID

(LABEL 351)

0 = Port Selected or Inactive1= Non-Selected Port Request for Attention



MCDU NORMAL DISCRETE WORD (270)BIT NO. FUNCTION BIT STATUS

1 01 X2 X3 X4 LABEL 270 (OCTAL) X5 X6 X7 X8 X9 NOT USED

10 NOT USED11 PORT #1 RECEIVER FAILED NORMAL12 PORT #1 DATA INPUT FAILED NORMAL13 PORT #214 PORT #2

15 PORT #316 PORT #317 PORT #418 PORT #419 PORT #520 PORT #521 PORT #622 PORT #623 PORT #724 PORT #72526 *OPTIONAL PORTS (SEE BELOW)2728 SPARE29 MCDU STATUS FAILED NORMAL30 SSM31 SSM32 PARITY

OPTIONAL PORTS HEALTH STATUSBIT 27 26 25NORMAL 0 0 0PORT A FAILED 0 0 1PORT B FAILED 0 1 0PORT C FAILED 0 1 1PORT D FAILED 1 0 0PORT E FAILED 1 0 1PORT F FAILED 1 1 0PORT G FAILED 1 1 1

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

c-1


ATTACHMENT 4CHARACTER CODE ASSIGNMENTS (DERIVED FROM ISO #5)

BIT 7-----------------------------------------------> BIT 6----------------------------------------> BIT 5-------------------------------->

00

0

00

1

01

0

01

1

10

0

10

1

11

0

11

1

BIT4

BIT3

BIT2

BIT1

Column

→→Row ↓↓

0 1 2 3 4 5 6 7

0 0 0 0 0 NUL SP 0 PMCDUMENU SEL1

0 0 0 1 1 CNTRL DC1 ! 1 A QSPECIAL

FUNCTION SEL2

0 0 1 0 2 STX DC2 " 2 B RKEYS

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

0 1 1 0 6 ACK SYN & 6 F VPREVPAGE

0 1 1 1 7 / 7 G WNEXTPAGE

1 0 0 0 8 CLRLOGOFF ( 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 oo - = M ]] SER6

1 1 1 0 14 ↓↓ . > N ↑↑ ∆∆

1 1 1 1 15 →→ ? O ←← or ∆∆ CLR/DEL

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

Shaded codes are button push codes.


ATTACHMENT 5ENVIRONMENTAL TEST CATEGORIES

The following environmental specifications for the Multi-Purpose Control and Display Unit (MCDU) reflect RTCADO-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

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 turbinepowered fixed-wing aircraft. Refer to RTCA DO-160D directly.

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

c-1


ATTACHMENT 6TYPICAL 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).

••

•

• •

• • •


ATTACHMENT 7

TYPICAL FRONT PANEL LAYOUT

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

SCRATCH PAD

NEXTPAGE

MAINMENU CALL

A B EC D

F G H I J

K L M N O

P Q R S T

U V W X Y

Z + - SP CLR

1 2 3

4 5 6

7 8 9

/ 0 .

ANNUNCIATOR FOR THE SYSTEM HAVING PRIORITY


ATTACHMENT 8GLOSSARY

ACARS Aircraft Communications Addressing and Reporting SystemACK Acknowledge TransmissionAIDS Aircraft Integrated Data SystemBITE Built-In Test EquipmentCDU Control/Display UnitCFDIU Central Fault and Display Interface UnitCLR ClearCTS Clear to SendDEL DeleteEFIS Electronic Flight Instrumentation SystemEICAS Engine Indication and Crew Alerting SystemENQ EnquireEOT End of TransmissionETX End of TextCFDS Central Fault and Display SystemFMC Flight Management ComputerGN(L)U GNSS Navigation (and Landing) UnitIRS Inertial Reference SystemISO International Organization for StandardizationMAL MCDU Address LabelMCDU Multi-Purpose Control and Display UnitNAK Not-Acknowledge TransmissionRNP Required Navigation PerformanceRTS Request to SendSAL System Address LabelSATCOM Satellite CommunicationSDI Source Destination IdentifierSSM Signed Status MatrixSTX Start TransmissionSYN Transmission Not Understandable/Recoverable


ATTACHMENT 9OPTIONAL MCDU FUNCTIONS

BASIC 7 ARINC 429 MCDU HANDSHAKE OUTPUTINPUTS FROM BASIC ARINC 739 TO SYSTEMSSYSTEMS 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-UPMONITOR EICAS CP * EICAS CONTROL * EICAS ALTERNATEand EFIS CP OUTPUT FUNCTION CONTROLBUS *

NEW, BACK-UP EFIS CONTROL * EFIS ALTERNATE FUNCTION CONTROL

*


ATTACHMENT 10MCDU DISPLAY CONSIDERATIONS

1.0 General

This attachment is considered as guidance and isprovided only for example. Specific implementationsmay vary.

1.1 Display

The MCDU screen will accommodate 14 rows of 24characters each. The top line can be referred to as thetitle line and the bottom line can be referred to as thescratch pad. The title line should normally be used toindicate the active subsystem and function beingaccessed. The scratch pad should be used to displaymessages to the crew and to reflect keyboard entry of datawhich can then be shifted to an appropriate field on thedisplay by pressing the adjacent line select key, asdescribed in Section 2.4.1.

The 12 middle rows on the display should be viewed assix paired lines where each pair consists of a “headerline” and a “data line”. A line select key is positionedadjacent to each end of each data line. In describingformats and operations, it is convenient to refer to thepairs as lines 1 through 6 and the line select keys as 1Lthrough 6L and 1R through 6R. If a display applicationrequires lengthy text messages, multiple lines may beused. However, the remaining lines should preserve theheader line and data line distinction.

Each line can be divided into one, two or three fields asdesired. When a center field is defined, it should be adisplay only field. Field widths are variable and shouldbe sized by the data they will contain. At least two spacesshould be left between fields. In laying out fields,consideration should be given to display readability. Toomuch data on a page can make scanning difficult, therebyrendering it ineffective inflight and undesirable formaintenance 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 identifythat subsystem and/or the function being accessed. Thepage title should be displayed using the large fontalphanumeric characters. This convention ensures that inthe case of typical cockpit operations, the flight crew willalways have a clear indication of the active subsystemand function to aid in the mental reorientation requiredafter any number of interruptions. For example,“ACARS” would appear in the title of an ACARS controlpage. Similarly, “ACMS” would appear on ACMS pages,etc. To avoid confusion, use of another subsystem’s keywords must be avoided in the title line.

When a subsystem consists of two identical units, eithermaster/slave, or master/hot spare, or both units operatingat the same time and performing complimentaryfunctions, the subsystem may generate an introductory ortop level menu page that provides capability to selectand/or display which of the two units is active or isprimary. In these cases, the MCDU-generated menu pageshould 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 TITLELINE should clearly identify the subsystem without anindication of “L” or “R”, or onside/offside, etc. Forexample “ACARS”. An indication such as “ACTIVE” orother distinct indication in a HEADER or DATA line(Sections 2.2 and 2.3) or a combination of the two, maybe used on the subsystem-generated menu page todesignate which unit is in control, if appropriate. If thearchitecture is such that the two subsystem units areperforming complimentary functions and a master/slaveor similar hierarchy does not apply, then the subsystem-generated menu page can simply provide access to eitherunit without indication of a primary or master.

Use of a subsystem-generated menu page for display andcontrol of dual subsystem units reduces space demandson the MCDU-generated menu page by requiring onlyone, rather than two, line select positions.

In a dual unit subsystem installation where one of theunits has been selected for display, (via line selectionfrom either the MCDU menu page or the subsystem-generated menu page) the particular unit should be clearlyidentified in the TITLE LINE of the subsystem page forease of identification. For example: “ACARS - L”. Ifappropriate for the architecture, an indication in anotherlocation on the subsystem page may indicate whether ornot that unit is “primary” or “master”. When one unit in adual installation is the active MCDU subsystem, thesubsystem will be designated as “ACTIVE” on theMCDU-generated menu page as described in Section3.4.2. Selection of the subsystem prompt on the MCDU-generated menu page in this case should result in directaccess to the active unit subsystem page without having togo to the subsystem-generated menu page.

Many pages overflow the screen space. When thishappens, a display page can be considered to consist ofmultiple screens/pages of data and should be numberedon the right end of the title line. For example, if there aretwo pages they should be numbered “1/2” and “2/2” usingnumbers in small font. In cases where the total number ofpages may be variable, the total pages available must bedetermined and identified. The NEXT PAGE and PREVPAGE keys should be used to move back and forththrough these multiple pages. Unless some uniquerequirement dictates otherwise (such as scrolling),pressing NEXT PAGE when viewing the last page shouldroll the display to page 1/xx and pressing PREV PAGEwhen viewing page 1/xx should roll the display to the lastpage. When there will never be more than one page for agiven title, the page number (i.e., 1/1) need not bedisplayed. However, “1/1” should be displayed in caseswhere more than one page could exist under differentcircumstances.

Titles should be static (invariant). However, some maychange or be enhanced with superimposed words toindicate a submode, submenu, etc. Use of dynamic titlesshould be avoided. Also, titles should be kept as short aspossible rather than strive to identify every function onthe page. It should be recognizable at a glance. A

c-1

c-1


ATTACHMENT 10 (cont’d)MCDU DISPLAY CONSIDERATIONS

consistently used abbreviation is preferable to a longword (e.g., use MAINT rather than MAINTENANCE).The title should not overflow onto the next line. If asubtitle is absolutely necessary, it should be centered onthe 1C header line (i.e., in field 1C) and use of the 1L and1R header and data lines restricted to keep the subtitleidentifiable.

2.2 Header Line

For line pairs one through six, the header line should belocated above its corresponding data line. Header text ordata should be displayed using the small alpha-numericfont. The use of a small font header line in relation to theposition, and size of the corresponding data line field isintended to optimize both visual and search performance.

Field of view aspects of the header line may be a basisfor establishing that left headers be left adjusted startingin column 2. However, right headers could be rightadjusted to column 24. The positioning for center fieldsshould be on the basis of adequate identification anddiscrimination of the information to be displayed.

2.3 Data Line

The data line may have varied attributes depending upondata type and function. A data field may be characterizedas 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 bevalidated 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 overwrittenby data from the scratchpad and cannot be selected to thescratchpad. Selection of the adjacent line select keyshould 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 lineselection of the displayed data to the scratchpad orfunctional selections as described in paragraph 2.3.3.Data entry to and deletion of this type of field is notallowed. A select only, special procedure field, may existwhen the attributes of the field are such that it can only beselected after specific criteria have been satisfied

b. Enter Only

This type of data field only allows for the line selection ofdisplayed data from the scratchpad to the data field. Lineselection of this data to the scratchpad and deletion of this

type of field is not allowed.

In cases where a unique field structure allows the entry ofmore than one piece of data and entry of either part canbe mutually exclusive, special entry criteria may berequired; For example the field data may be “xxx/yyy”where the entry of “aaa” will automatically be consideredfor the the x-part only and where an entry including aspecial delimiter such as “/bbb” should be required toonly enter the data into the y-part of the data field.

An enter only, special procedure field, may exist when thedata field has more than one function governed byspecific pre-existing conditions, or as a normal alternativefor the field.

c. Select/Enter

This type of data field allows for the line selection ofdisplayed data both to and from the scratchpad. Deletionof this type of field is not allowed. The special procedureaspects, of the field are as described for the select onlyand enter only fields.

d. Enter/Delete

This type of data field allows for the line selection ofdisplayed data from the scratchpad and the capability todelete data entered.

e. Delete

This type of data field allows for deletion of data in thefield. It may be combined with any of the above types.The special procedure capabilities for selection and entryinto the field are as described for the select only andenter only fields. A special delete procedure would existin the case where deletion of a data field resulted in thedisplay of a selection prompt instead of the display of ablank or default value data field.

2.3.3 Prompts

a. Select

A data field may be used to display a prompt whichemphasizes the selectability of another mode, option,page, parameter, or menu item.

Select prompts on the left side of the display should beginwith a large font caret “< ” in column 1 followed by theleft justified prompt starting in column 2. Select promptson the right side of the display must be right justified tocolumn 23 followed by a large font caret “> ” in column24.

When a line selectkey associated with a prompt ispressed, the system should execute the action required bythe prompt selection. A display indication in response tothis action could be in the form of a noticeable change inindicated system mode, activation/deactivation of afunction, a new page display, etc. The title of a pagedisplay should include the prompt name which selectedthe page. The use of prompt names which reflect thepage to be displayed is intended to eliminate anyambiguity regarding the consequences of selecting aprompt.

c-1



2.3.3 Prompts (cont’d)

The data field font size should be as defined in paragraph2.3. However, a small font prompt may be used in thecase where the prompt must be validated or supersededby a line select entry from the scratchpad. In this case,there should be a change in character font size as aconsequence of validation, the caret prompt should beremoved, and the validated prompt should be left or rightadjusted as appropriate. In special applications, theheader field may also be used to either accentuate theprompt or reflect the condition/status of the promptselection.

These type of select prompts should be located at thebottom of a page (e.g., positioned on lines 6L and/or 6R).If the number of required select prompts exceeds thecapacity of a line, the menu/list of select prompts shouldbe built from the bottom line up for any remainingprompts. The select prompts should have a distinctseparation boundary from other page display data, in theform of a page width, dashed line located in the headerline of the uppermost select prompt.

b. Enter only

An entry of this type may be required or optional for thedisplay field and should be indicated by the use of dashesor box prompts to solicit the data. Typically this type ofentry would be associated with and dependent on anotherdisplay field or possibly function/mode. In this case, achange in the dominant field or function/mode shouldcause 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 thedata entry is required before a function can be performedor before a mode change can be completed, box promptsshould be displayed to solicit data to be entered. Thenumber of dashes or boxes used for the prompt shouldcorrespond to the maximum number of alpha-numericcharacters which can be entered.

c. Enter/Delete Only -

An entry of this type may be optional and should beindicated by the use of dashes to solicit the data. Thistype of entry could be associated with an on/off typefunction or the insertion of a reference value or limit.After data has been entered, deletion of the data fieldshould return to dash prompts or default value for thedata field. The number of dashes used for the promptshould 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 thedisplay data field. This type of entry could be required oroptional. The use of this field should be oriented towardsetting limits, adding a bias to a default setting, setting areference, etc. It should be used where the systems pagedesigns allow for the transfer of data from one field toanother to facilitate data entry. The number of dashesused for the prompt should correspond to the maximumnumber of alpha-numeric characters which can beentered.

2.4 Scratch Pad Line

The scratch pad line at the bottom of the display shouldbe used for two purposes:

a. To temporarily display data being entered via thekeyboard 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 shouldbe kept available for data entry. Since it may be timeshared with the display of system messages, any messagebeing displayed may require being cleared by pressing theCLR key before data entry is allowed. The subsystemmust keep track of when the scratch pad contains amessage and when it contains either a blank line orpreviously entered data.

If a subsystem designer determines that the 24 characterline can be subdivided to allow simultaneous data entryand message display without interference, the data entryfield should be considered on the left. Its maximum sizeshould 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 entriesand messages but has the advantage of avoiding the needto clear messages before data entry.

Starting with a blank scratch pad, the first characterentered should be displayed in column 1. Eachsubsequent character entered should appear to the right ofthe last character already be in the scratch pad. Allcharacters should be displayed in large font. The lastcharacter on the right of the scratch pad entry should beremoved when the CLR key is pressed and released. Thenext character on the right should be removed when theCLR key is pressed again and so on. The complete dataentry should be removed when the CLR key is held downfor more than one second.

2.4.2 Scratch Pad Data Entry via Line Select

If the scratch pad is clear, pressing the line select keyadjacent to a selectable data field should cause the data inthat field to be duplicated in the scratch pad, left adjusted.Once in the scratch pad, it should be treated just asthough it had been entered via the keyboard. In otherwords, characters can be added on the right and/orcleared 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 keyshould cause the subsystem computer to:

a. Check that data entry is permissable for the adjacentdata field. If not, the line select key press should beignored.

b. Check the validity of the data for use in the adjacentdata field. In other words, validity checking of dataoccurs when the transfer is attempted, not when thedata is keyboarded into the scratch pad. If the



validity check fails, an indication of an invalid entryshould be generated.

c. Transfer valid data from the scratch pad to the datafield, replacing previous contents and clearing thescratch pad.

If an entry is reformatted when it is moved from thescratch pad to a data field, it must be returned to the entryformat when it is moved from data field to scratch pad.For example, a latitude/longitude might be entered asN4720.3W12245.2 in the scratch pad and be reformattedas N47 20.3 W122 45.2 in a data field. It must bereturned to the N4720.3W12245.2 form when movedback to the scratch pad.

The requirements for the display may specify specialresponses/indications resulting from the data entry into afield. For example, in the case where a list is beingdisplayed and it is desired to insert a new item in the list,the line select entry to a specific field should produce theresult of inserting the entry and pushing all previous listdata down one data line versus overwriting the field intowhich the entry is made.

2.4.4 Data Transfer From Field to Field

Data can be moved from one field to another via thescratch pad. First the scratch pad should be cleared if notalready clear. Next the line select key adjacent to the datato be moved should be pressed. This action duplicatesthe selected data in the scratch pad. Finally, the lineselect key adjacent to the destination field should bepressed to move the data up from the scratch pad. Itshould be possible to move data from page to page usingthe same technique unless the pages are sufficientlydissimilar that no need for this capability exists.However, data cannot be moved across subsystemboundaries 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 subsystemcomputer detects a condition which must be brought tothe crew’s attention. It would be displayed in the scratchpad of each operating MCDU in communication with thesubsystem regardless of prior contents of the scratch pad.The prior contents of the scratch pad, if any, should besaved in a message stack/buffer and redisplayed when thealerting message is cleared.

An advisory message could be used to indicate data entryerrors or other lower priority information. It should notdisplace alerting messages but should be displayed whenthe scratch pad is cleared. Therefore, it should beinserted in a message stack below any alerting messagesin the stack. Data entry error advisory messages wouldtake precedence over other advisory messages and scratchpad data entries. Other advisory messages should only bedisplayed when the scratch pad is cleared. As withalerting messages, scratch pad contents should be savedin a message stack when replaced by an advisorymessage.

Messages are expected to be cleared automatically fromthe display and message stack when the subsystem setlogic is no longer satisfied. Any displayed messageshould be cleared and associated message set logic resetwhen the CLR key is pressed. The next message in thestack should then be displayed. Holding the CLR keydown should not cause all messages and data to bedisplayed and cleared in a continuous sequence. Clearedmessages must not be redisplayed until the appropriate setlogic has again been satisified or some appropriateredisplay or recall logic is satisfied. In general, messagesshould be avoided wherever possible since they can beperceived as more of a nuisance than an aid to flightcrews.

When more than one MCDU is in communication with asubsystem at the same time, a scratch pad data entryshould only appear on both MCDUs if they are on thesame page. If they are on different pages, it should bepossible to make an independent data entry on eachMCDU. Data entry error advisory messages must only bedisplayed on the MCDU displaying the offending entry.Other advisory messages should only be displayed when arelated page is displayed.

Copyright 1998 byAERONAUTICAL RADIO, INC.

2551 Riva RoadAnnapolis, 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

This Supplement introduces changes and additions toARINC Characteristic 739A to accommodate MCDUswitching between dual subsystems, for example dualFMSs.

B. ORGANIZATION OF THIS SUPPLEMENT

The first part of this document, printed on goldenrod-colored paper, contains descriptions of the changesintroduced in Characteristic 739A by this Supplement.The second part consists of replacement white pages forthe Characteristic modified to reflect these changes.The modified and added material on each replacementpage is identified by the “c-1” symbol in the margins.Existing copies of Characteristic 739A may be updatedby simply inserting the replacement pages wherenecessary and destroying the pages they replace. Thegoldenrod-colored pages should be inserted inside therear cover of the Characteristic.

C. CHANGES TO ARINC CHARACTERISTIC 739A INTRODUCED BY THIS SUPPLEMENT

This section presents a complete tabulation of thechanges and additions to Characteristic 739Aintroduced by this Supplement. Each change or additionis defined by the section number and the title that willbe employed when this Supplement is incorporated. Ineach case, a brief description of the change or additionis included.

1.6 Relationship to ARINC 739

This section was updated to include dual subsystemconsiderations.

2.2 Form Factor

Connector part number was revised to reflect currentmilitary specifications.

3.4.3 Subsystem Specific Menu

This section was modified to describe a typical firstpage of a subsystem menu in a dual subsysteminstallation. This may include the capability to select aspecific unit to be primary, master, or the operationalunit.

3.6 MCDU Inputs

This section was reorganized and subdivided into threesubordinate sections for the purpose of defining SevenBasic Input Ports (3.6.1), Additional Subsystem InputPorts (3.6.2) and MCDU Interfaces Involving DualSubsystem Devices (3.6.3).

3.6.1 Seven Basic Input Ports

This section was renumbered. The content is unchangedfrom the former Section 3.6.

3.6.2 Additional Subsystem Input Ports

New section was added to describe five optionalARINC 429 input ports for receiving identificationinformation and display data from either a second unit

in a dual unit subsystem installation, or from otherindividual subsystems.

3.6.3 MCDU Interfaces Involving Dual Subsystem Devices

This section was added to describe dual subsysteminstallation techniques.

3.7.2.3 Alternate Menu Display

A note was added to alert the reader to Section 4.2.1,System Selection and Control.

ATTACHMENT 3, DIGITAL WORD FORMATS

The MCDU Normal Discrete Word (Label 270) wasmodified to include health status reporting for port 7(omission) and optional paired ports.

ATTACHMENT 5, ENVIRONMENTAL TESTCATEGORIES

This attachment was update to reflect the currentenvironmental test requirements defined in RTCA DO-160D.

ATTACHMENT 10, MCDU DISPLAYCONSIDERATIONS

2.1 Title Line

New material was added to provide guidance onsubsystem-generated menu pages and MCDU-generated menu pages for dual subsystemconfigurations.

Date post:	30-Oct-2014
Category:	Documents
Upload:	scribber111
View:	47 times
Download:	0 times

55629551-Arinc739A-1

Documents