Arinc739A-1

A

MULTI-PURPOSE CONTROL AND DISPLAY UNIT ARINC CHARACTERISTIC 739A-1 PUBLISHED: DECEMBER 16, 1998

AN

A DOCUMENT

Prepared by AIRLINES ELECTRONIC ENGINEERING COMMITTEE Published by AERONAUTICAL RADIO, INC. 2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401

Copyright 1998 by AERONAUTICAL RADIO, INC. 2551 Riva Road Annapolis, Maryland 24101-7465 USA

ARINC CHARACTERISTIC 739A-1 MULTI-PURPOSE CONTROL AND DISPLAY UNIT Published: December 16, 1998

Prepared by the Airlines Electronic Engineering Committee Characteristic 739A Characteristic 739A

Adopted by the Airlines Electronic Engineering Committee: Adopted by the Industry:

October 22, 1996 December 10, 1996

Summary of Document Supplements Supplement

Adoption Date

Published

Characteristic 739A-1

October 26, 1998

December 16, 1998

A description of the changes introduced by each supplement is included on goldenrod paper at the end of this document.

FOREWORD Activities of AERONAUTICAL RADIO, INC. (ARINC) and the Purpose of ARINC Characteristics

Aeronautical Radio, Inc. is a corporation in which the United States scheduled airlines are the principal stockholders. Other stockholders include a variety of other air transport companies, aircraft manufacturers and non-U.S. airlines. Activities of ARINC include the operation of an extensive system of domestic and overseas aeronautical land radio stations, the fulfillment of systems requirements to accomplish ground and airborne compatibility, the allocation and assignment of frequencies to meet those needs, the coordination incident to standard airborne compatibility, the allocation and assignment of frequencies to meet those needs, the coordination incident to standard airborne communications and electronics systems and the exchange of technical information. ARINC sponsors the Airlines Electronic Engineering Committee (AEEC), composed of airline technical personnel. The AEEC formulates standards for electronic equipment and systems for the airlines. The establishment of Equipment Characteristics is a principal function of this Committee. An ARINC Equipment Characteristic is finalized after investigation and coordination with the airlines who have a requirement or anticipate a requirement, with other aircraft operators, with the Military services having similar requirements, and with the equipment manufacturers. It is released as an ARINC Equipment Characteristic only when the interested airline companies are in general agreement. Such a release does not commit any airline or ARINC to purchase equipment so described nor does it establish or indicate recognition of the existence of an operational requirement for such equipment, not does it constitute endorsement of any manufacturer’s product designed or built to meet the Characteristic. An ARINC Characteristic has a twofold purpose, which is: (1)

To indicate to the prospective manufacturers of airline electronic equipment the considered opinion of the airline technical people, coordinated on an industry basis, concerning requisites of new equipment, and

(2)

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

ii

ARINC CHARACTERISTIC 739A TABLE OF CONTENTS ITEM

SUBJECT

PAGE

1.0 1.1 1.2 1.3 1.4 1.4.1 1.4.2 1.4.3 1.5 1.6

INTRODUCTION AND DESCRIPTION Purpose of This Document Functions System Description Interchangeability General Interchangeability Desired for the ARINC 739A MCDU “Generation Interchangeability” Consideration Regulatory Approval Relationship to ARINC 739

1 1 1 1 1 1 1 1 2 2

2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.7 2.8

INTERCHANGEABILITY STANDARDS Introduction Form Factor Environmental Conditions Interwiring Thermal Interface and Design Power Circuitry Primary Power Input Power Control Circuitry The Common Ground The AC Common Cold Weights Grounding and Bonding

3 3 3 3 3 3 3 3 4 4 4 4 4

3.0 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8 3.5 3.6 3.7 3.7.1 3.7.2 3.7.2.1 3.7.2.1.1 3.7.2.1.2 3.7.2.2 3.7.2.3 3.7.3 3.7.3.1 3.7.3.1.1 3.7.3.1.2 3.7.3.2 3.7.3.3 3.7.3.4 3.7.3.5 3.7.3.6 3.7.3.7 3.7.3.8

MCDU DESCRIPTION General Display Keyboard Basic Function Keys Specific Function Keys Alpha-Numeric Keys Panel Illumination and Annunciator Lights MCDU Operation and Display Typical MCDU Initiation MCDU Menu Subsystem Specific Menu Non-Menu Operation Scratchpad and Data Field Entry Clearing Data Fields Exiting Proposed Philosophy to Menu Stepping MCDU Outputs MCDU Inputs System Communication Subsystem and MCDU Identification Menu Generation Initial Menu Addressing and Responses Protocol Timing and Responses Menu Changes Alternate Menu Display Data Communication Subsystem Initiated Messages Subsystems Not Currently Active Active Subsystems MCDU Communication with Inactive Subsystem and Data Request Message Transfer Control (CNTRL) Word Data Word Background/Vector Words Discrete Word Button Push Word iii

5 5 5 5 5 5 5 5 6 6 6 7 7 7 7 7 7 8 8 8 8 8 8 8 9 9 9 10 10 10 10 10 10 11 11 11 11 12

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

SUBJECT

PAGE

3.0 3.8 3.8.1 3.8.2 3.8.3 3.9 3.9.1 3.9.2 3.9.3 3.9.4 3.9.5 3.9.6 3.9.7 3.9.8

MCDU DESCRIPTION (cont’d) Built-In Test Equipment (BITE) BITE Considerations BITE Display Self-Test Electronic Flight Instrument System Interface MCDU Outputs to EFI MCDU Inputs from EFI MCDU Map Inputs from FMC Flight Plans and Guidance Map Display Edit Area Background Data Prioritizing Data Type Word Formats Flight Plan Retention

12 12 12 12 12 12 12 12 12 12 12 13 13

4.0 4.1 4.2 4.2.1 4.2.2 4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.3.1 4.2.2.4 4.2.3 4.2.3.1 4.2.3.2 4.2.3.2.1 4.2.3.2.2 4.2.3.2.3 4.2.3.2.4 4.2.3.2.5 4.2.3.3 4.2.4 4.2.4.1 4.2.4.2 4.2.4.3 4.2.5 4.2.5.1 4.2.5.2 4.2.5.3 4.2.6 4.2.6.1 4.3 4.3.1 4.3.2 4.4

NAVIGATION AND DISPLAY CONTROL Introduction Functional Requirements System Selection and Control Navigation Radio Tuning Mode Selection General Operation Navigation Tuning Page Functions Tuning Inhibit Interface Requirements Standby Navigation Mode Selection Operation General Navigation and Guidance CDU Page Access Navigation Computations Map Display Interface Requirement Alternate EFIS Control General Page Access Interface Alternate EICAS Control General Page Access Interface System Communication Inter-system Hardware Requirements General Interwiring Definition Standby Navigation Lateral Guidance

14 14 14 14 14 14 14 14 15 15 15 15 15 15 15 15 16 16 16 17 17 17 17 17 17 17 17 18 18 18 18 18 18

Standard Interwiring Address Labels Digital Word Formats Character Code Assignments (Derived from ISO #5) Environmental Test Categories Typical System Configuration Typical Front Panel Layout Glossary Optional MCDU Functions MCDU Display Considerations

19 22 23 28 29 30 31 32 33 34

ATTACHMENTS 1 2 3 4 5 6 7 8 9 10

iv

ARINC CHARACTERISTIC 739A - Page 1 1.0 INTRODUCTION AND DESCRIPTION 1.1 Purpose of This Document

1.3 System Description

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

As a minimum, the MCDU should contain the circuitry and processing necessary to accept alpha-numeric message codes and display them on the screen, and circuitry for transmitting command codes relating to line keys or keyboard keys. Data communication is determined by standard protocols and message formats, within the selected system.

Equipment manufacturers should note that this document encourages them to produce maintenance-free, high performance equipment rather than that of minimum weight and size. They are at liberty to accomplish this objective by means of the techniques they consider to be the most appropriate. Their airline customers are interested primarily in the end result rather than the means employed to achieve it.

The structure and content of messages, menus and interpretation of commands is carried out by software in the user system and not in the MCDU. 1.4 Interchangeability 1.4.1 General

Avionics systems optimization can be achieved on board modern aircraft by minimizing the cost, weight and size of avionics. The use of one or more MCDUs will contribute to this goal. By the use of identical MCDUs, the specific control and display units for ACARS/CMU, AIDS, CFDS and other systems can be eliminated. There would be substantial savings due to: a. Elimination of CDU spares b. Simplification of cockpit

One of the primary functions of an ARINC Equipment Characteristic is to designate, in addition to certain performance parameters, the interchangeability desired of aircraft equipment produced by various manufacturers. The manufacturer is referred to Section 1.6 of ARINC Report 414 for definitions of Terms and General Requirements for the airline industry for interchangeability. As explained in that report, the degree of interchangeability considered necessary and attainable for each particular equipment is specified in the pertinent ARINC Equipment Characteristic.

c. Easier crew operation training (common procedures)

1.4.2 Interchangeability Desired for the ARINC 739A MCDU

d. Flexibility to accommodate other systems (e.g., SATCOM, Mode S, etc.)

Unit interchangeability is desired for the MCDU regardless of manufacturing source. The physical attributes, the electrical interfaces and operation of the MCDU were defined to accommodate application to a wide variety of avionics. The standards necessary to achieve this level of interchangeability are set forth in this Characteristic.

e. MCDU can be applicable to any aircraft. 1.2 Functions The MCDU is expected to communicate with multiple systems one at a time (equivalent to multi-purpose switch). System selection is by use of keys on the MCDU (dedicated keys or by menu item key) and is achieved by sending different user system address labels on a common output command data bus. See Attachment 6. The MCDU should provide means for manually selecting subsystems connected and for inserting system control parameters and modes of operation. In addition, it should provide display capability for various subsystems outputs as well as for the verification of data entered into memory. Certain annunciations related to system operation may also be included. Providing that the standardized protocols and message structures are used, the MCDU can be used with any system regardless of application. It is therefore truly multi-purpose.

1.4.3 “Generation Interchangeability” Considerations In defining the equipment described in this Characteristic, the air transport industry has chosen to depart from several of its previous control function standards. In order to achieve the full benefit of the economies offered by these changes, the industry desires that no provisions be made in this equipment for backward compatibility with earlier generations of equipment. Unchanged, however, is the industry's traditional desire that future evolutionary equipment improvements and the inclusion of additional functions in new equipment in the next few years do not violate the interwiring and form factor standards set forth in this document. Provisions to ensure forward-looking “generation interchangeability” (as best can be predicted) are included in this document to guide manufacturers in future developments.

ARINC CHARACTERISTIC 739A - Page 2 1.0 INTRODUCTION AND DESCRIPTION (cont’d) 1.5 Regulatory Approval The MCDU should meet all applicable FCC and FAA regulatory requirements. Manufacturers are urged to obtain all necessary information from the FAA and the FCC on such regulatory approval. This information is not contained in this Characteristic, nor is it available from ARINC. 1.6 Relationship to ARINC 739 This document was developed from ARINC Characteristic 739, “Multi-Purpose Control and Display Unit”, originally developed to support the installation of MCDUs in FMS-equipped airplanes. This document builds on the ARINC 739 philosophy and includes several capabilities viewed to be necessary to satisfy airline desires for CNS/ATM equipment installations in their existing fleets of airplanes. The ARINC 739A MCDU retains the same textual man-machine interface conceived for the ARINC 739 unit. This documents c-1 includes new material describing: Dedicated Function Select Key GNSS Interface Optional Smaller Form Factor 28 Vdc Power Connection MCDU Display Considerations Dual Subsystem Considerations

ARINC CHARACTERISTIC 739A - Page 3 2.0 INTERCHANGEABILITY STANDARDS 2.1 Introduction

Characteristic tabulates the relevant environmental categories.

This section sets forth the specific form factor, mounting provisions, interwiring, input and output interfaces and power supply characteristics desired for the MultiPurpose Control and Display Unit. These standards are necessary to ensure the continued independent design and development of both the equipment and the airframe installations. Manufacturers should note that although this Characteristic does not preclude the use of standards different from those set forth herein, the practical problems of redesigning a standard airframe installation to accommodate a special equipment could make the use of that equipment prohibitively expensive for the customer. They should recognize, therefore, the practical advantages of developing equipment in accordance with the standards set forth in this document. 2.2 Form Factor The MCDU should be packaged as a standard dzusmounted control panel 9.0 inches high by 5.75 inches wide. The depth behind the panel should not exceed 10.5 inches, excluding the connector. An alternative form factor intended to support installation in older aircraft, should be packaged as a standard dzusmounted control panel 7.125 inches high by 5.75 inches wide. The depth behind the panel should not exceed 6.0 inches, excluding the connector. A connector type MS 24264R 20 B 41PN should be used having pin assignments shown in Attachment 1. When the optional navigation and display control functions are included in the MCDU, a second connector type MS 24264 20 B 41P6 should be used. c-1

COMMENTARY Cost, weight, and electrical power consumption reduction may be achieved by developing a smaller and simpler MCDU. Use of flat screen technology will undoubtedly allow design of smaller units. Thus, equipment manufacturers may offer MCDUs of lesser dimensions. However, certain attributes such as screen size and required keys should be maintained. The SAE S-7 Flight Deck and Handling Qualities Subcommittee has expressed concern with the notion of smaller form factor MCDUs. Manufacturers are encouraged to consider human factor implications resulting from a reduction in keyboard, character or display sizes. General Aviation (GA) may require smaller form factors.

2.4 Interwiring The standard interwiring for the MCDU is set forth in Attachment 1 to this Characteristic. This interwiring is designed to provide the degree of interchangeability specified in Section 1.4. The equipment manufacturer is cautioned not to rely upon special wires, cabling or shielding for use with his particular units because they will not exist in the standard installation. COMMENTARY Why Standardize Interwiring? The standardized interwiring is perhaps the heart of all ARINC Characteristics. It is this feature which allows the airline customer to complete his negotiation with the airframe manufacturer so that the latter can proceed with installation engineering and initial fabrication prior to airline commitment on a special source of equipment. This provides the equipment manufacturer with many valuable months in which to put final “polish” on his equipment in development. 2.5 Thermal Interface and Design The internal power dissipation of the MCDU should not exceed 92 watts. The MCDU cooling and thermal design should be in accordance with ARINC Specification 408A, Sections 2.3, 3.6 and 3.10. These sections define case temperature limits, the equipment cooling method, the thermal appraisal procedure and expected high temperature exposure conditions which should be considered for the equipment design. However, it may be desirable (and may be imperative for some installations) that the equipment be designed for passive cooling. COMMENTARY ARINC Specification 408A defines the standard interface between the aircraft and indicators; however, the thermal interface described should also be applied to the MCDU. 2.6 Power Circuitry 2.6.1 Primary Power Input The MCDU should be designed to use 115 volt 400 Hz single phase power from a system designed for Category (A) utilization equipment per ARINC Specification 413A. Optionally the equipment may be designed to operate with 28Vdc. Manufacturers should determine the most appropriate power source for each installation.

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

The primary power input to the MCDU should be protected by a circuit breaker of the size shown in Attachment 1 to this Characteristic. NOTE: Airframe installation designers should verify that

ARINC CHARACTERISTIC 739A - Page 4 2.0 INTERCHANGEABILITY STANDARDS (cont’d) the aircraft power systems satisfy the primary power interruption criteria of ARINC Specification 413A. 2.6.2 Power Control Circuitry There should be no master on/off power switching within the CDU. Any user desiring on/off control should provide, through the medium of an external switching function installed in the airframe, a means of interrupting the primary ac power to the system. 2.6.3 The Common Ground The wire connected to the MCDU connector pin labelled “Chassis Ground” should be employed as the dc ground return to aircraft structure. It is not intended as a common return for circuits carrying heavy ac currents, and equipment manufacturers should design their equipment accordingly. 2.6.4 The AC Common Cold The wire connected to the MCDU connector pin labelled “115 Vac Cold” should be grounded to the same structure that provides the dc chassis ground but at a separate ground stud. Airframe manufacturers are advised to keep ac ground wires as short as practicable in order to minimize noise pick-up and radiation. 2.7 Weights System manufacturers should take note of the guidance information on weights contained in ARINC Specification 600. 2.8 Grounding and Bonding The attention of equipment and airframe manufacturers is drawn to the material in Section 3.2.4 of ARINC Specification 600 and Appendix 2 of ARINC Specification 404A on the subject of equipment grounding and bonding. COMMENTARY A perennial problem for the airlines is the location and repair of airframe ground connections whose resistances have risen as the airframe ages. A high resistance ground usually manifests itself as a system problem that resists all usual approaches to rectification, and invariably consumes a wholly unreasonable amount of time and effort on the part of maintenance personnel to fix. Airframe manufacturers are urged, therefore, to pay close attention to assuring the longevity of ground connections. Close attention to the above-referenced specification material should be their first step.

ARINC CHARACTERISTIC 739A - Page 5 3.0 MCDU DESCRIPTION 3.1 General

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

As a minimum, a “NEXT PAGE” pushbutton should be provided to advance the display. User systems are expected to design their display formats such that use of the “NEXT PAGE” key is the only specific key function required for its operation as it may be the only key guaranteed on some MCDUs. A depression of “NEXT PAGE”, when the last page is being displayed, should cause the MCDU to return to the first page. As an alternative, line keys can be used to select basic functions.

COMMENTARY

COMMENTARY

The Multi-Purpose Control and Display Unit (MCDU) should comprise a keyboard and a display with associated line select keys as described in the following sections.

The MCDU display should provide sufficient data display space to provide efficient, yet uncluttered, display of all data required for the mode or function selected. 3.2 Display In general, the MCDU display should be adequate in size to provide the greatest amount of information to flight crew without needless clutter. The top line of the display should be the title line describing the page contents. The remaining lines should be arranged so as to provide ease in reading the display. The bottom line of the display should be used as the “scratch pad” for entering data. Line keys should be provided on either side of the display in order to support menu driven functions. Section 3.4 describes a typical MCDU display. As an option MCDU designers may consider the use of color displays in order to enhance readability. Additional considerations for display and operation are provided in Attachment 10. 3.3 Keyboard The MCDU keyboard should include the following:

Although a “PREVIOUS PAGE” button is not specifically called out in this Characteristic, a dedicated button for this purpose appears to have merit particularly when more than three pages are being accessed by the MCDU. A “PREVIOUS PAGE” key code has been assigned in this Characteristic in order that manufacturers can provide this option if they so desire. Similarly, slewing keys are considered optional. However, not all avionics connected to the MCDU will be able to slew text up or down on the display. Pressing the slew key, if provided, would have no effect when these avionics are communicating with the MCDU. 3.3.2 Specific Function Keys Up to thirteen specific-function keys may be provided on the MCDU to accommodate special functions on some avionics (e.g., flight management computer/GN(L)U). At a minimum, one of these keys should be programmable as to which user it is dedicated. Selection of a dedicated function key should result in the immediate display of the functional page from the defined user system. This implies automatic activation of the defined user and deactivation of the prior active user.

a. Basic function keys COMMENTARY b. Specific function keys c. Alpha keys d. Numeric keys

Thirteen specific function key codes have been assigned in this Characteristic. However, it should not be misconstrued as industry support for these “dedicated” keys on the MCDU. Their use by avionics burdens the MCDU by cluttering its front panel and essentially preempts its desired role as a truly flexible multi-purpose CDU. Dedicated function keys should only be used when rapid access to a function is deemed important.

e. Annunciators 3.3.3 Alpha-Numeric Keys All keys should provide tactile feedback to the operator to indicate a contact has been made.

A full set of alphanumeric keys should be provided on the MCDU. The MCDU should have the capability to support the available key codes illustrated in Attachment 4.

3.3.1 Basic Function Keys COMMENTARY A “MCDU MENU” key should be provided to return the MCDU to the main subsystem menu. A “CLEAR” key should be provided to clear the information displayed in the “scratch pad”.

The provision for a “space” key is optional. The “space” key is desired for ACARS and other “free text” applications. The SAE S-7 Committee has found that the space key is necessary for enhancing readability of free text applications.

ARINC CHARACTERISTIC 739A - Page 6 3.0 MCDU DESCRIPTION (cont’d) 3.3.4 Panel Illumination and Annunciator Lights The MCDU should be integrally lighted and be powered by the 5 volt panel light dimmer bus. The annunciator light brightness control should be accommodated by a 5 volt supply. The MCDU should accommodate both ac and dc light sources. COMMENTARY Separate panel light and annunciator light pins have been assigned to accommodate separate control. The panel lights would be connected to the normal 5 volt power source use for instrument panel lighting. Two different methods to vary annunciator brightness are commonly used. The first uses fixed dc ground on the “LO” side and varies the voltage (up to 5 Vdc) on the “HI” side. The other uses a fixed 5 Vdc on the “HI” side and varies the voltage in the “LO” side (0 Vdc for full brightness). Adequate isolation of the annunciator lights should be provided in the MCDU to accommodate both methods. An annunciation may be provided to alert the operator that a subsystem is waiting to send a message. An “FMC” annunciator could be dedicated to ports #1 and #2, and a general “call” or “MCDU Menu” annunciator could be provided to alert the operator for the lower priority (#3-#7) ports. COMMENTARY The MCDU integration with an aircraft flight deck may result in the need for equivalent but different methods of providing the annunciations. For example in the case where there is a centralized crew indication and alerting system, each subsystem may be required to produce a distinct indication to the flightcrew via the indicating and alerting system as the attention getting mechanism. This indication could be produced via a separate digital data interface or analog discrete interface. A lamp test input from the master control should be provided where necessary.

symbols and should be displayed either at the first character position if a left line key is used or at the twenty-fourth character position if right line key is used. If more than one page is involved the sending system should display a “more to come” symbol for the next page. The 23rd and 24th characters of the first line should be used for “more to come” symbol display. When slewing is used, up and down arrows should indicate that vertical slewing is available. They should appear in columns 23 and 24 in the scratch pad. Variations of the procedure may occur according to display and keyboard presentation used by different manufacturers. Additional considerations for MCDU displays are provided in Attachment 10. 3.4.1 Typical MCDU Initiation As described in Section 3.7.2.1, the MCDU after PowerUp would normally display the “first page” of the highest priority subsystem. This would typically be a menu of the subsystem functions. Selection of functions on subsystem “pages” is described in the following sections. 3.4.2 MCDU Menu To communicate with a subsystem other than the one currently active, the operator should push the “MCDU MENU” button. This should result in the presentation of a list of all subsystems connected to the MCDU. Likewise single key access may be provided by selection of dedicated function keys without the need to use the menu page. The MCDU should generate subsystem status adjacent to the subsystem menu text (i.e., after the system name). The current active system should be annunciated by “Active” or equivalent being displayed near or after the subsystem name. Any other subsystems having sent a “Request To Send” to the MCDU should be annunciated by “Req” or equivalent near or after the subsystem name. The operator should press the line key to establish communications with the desired subsystem.

3.4 MCDU Operation and Display COMMENTARY The following sections describe typical MCDU operation and display based on a front panel layout as shown in Attachment 7. The preferred display should contain fourteen lines, each having twenty-four characters. The top line (line 1) should normally be used as a title line to the display data to which the operator does not have access. The bottom line (line 14) should be the “scratch pad” line for entering data. Columns 23 and 24 of the title line and of the scratch pad line may be used as an option for “Slew” indications. Lines 2 through 13 should be data lines arranged into six pairs. The six line keys on each side of the display should be adjacent to the odd data lines. When selection by way of line key is anticipated the symbols (< left, > right) should be used as activation

Historically, the MENU page subsystem selection operation has taken two forms: a. If no line key is pressed within 60 seconds after the MCDU Menu is displayed, the MCDU should revert to the active subsystem display, if there is an active subsystem, otherwise it should display an appropriate time-out page. b. Once the MENU page is selected for display, the MCDU should remain on the MENU page until a

ARINC CHARACTERISTIC 739A - Page 7 3.0 MCDU DESCRIPTION (cont’d) selection is made. If the active system is selected on the menu, the last active subsystem page display should return. In this case, the subsystem, though not visible, is expected to compute current information as appropriate for the display. If the menu selection results in a changeover to a new active subsystem, the MCDU displays the subsystem’s initial page or menu as appropriate. Following selection of a subsystem, an indication should be provided to inform the operator that the selection of the subsystem is acknowledged. Typical methods would be to erase all other subsystems from the menu or color, blink or highlight the selected subsystem.5

necessary. In situations where the available field does not accommodate a scratchpad entry, an appropriate message should be displayed on the MCDU. If the data is incorrect, the system should leave the previous data in the data field and display the associated message indicating the error in the scratchpad. To enter the correct data, the operator should clear the message from the scratchpad. To clear the scratchpad of entered data or incorrect data, the “Clear” key can be used. One press of the key should erase the last character entered in the scratchpad. If the key is held down for two seconds the entire scratchpad should be cleared of any data.

COMMENTARY Occasionally there could be the inadvertent push of a line key which has no function. There has been some desire expressed to “blink” the display for a short period simply to let the operator know that a button push was recognized. MCDU manufacturers are urged to consider this function in their design. When communication has been established with a subsystem, the “first page” as transmitted by the subsystem should be displayed to the operator.

NOTE: Normally all twenty-four characters of the line can be used. If slewing indications (arrows) are used then only twenty-two message characters are available per line. Whenever the MCDU is waiting for a response from a subsystem or is in a situation which could be ambiguous to the operator, an appropriate message should be displayed in the scratchpad line. 3.4.6 Clearing Data Fields

If communication is not established within the maximum time stated in Section 3.7.3.2, a “Time-out” indication should be provided by the MCDU and an instruction should be displayed to the operator to press the “MCDU MENU” key. 3.4.3 Subsystem Specific Menu The first page of a subsystem menu should be a menu of functions which may include the capability to select a c-1 particular unit in a dual subsystem installation to be the primary, “master”, or operational unit. Selection of a menu item by the operator should result in an indication to operator that the input was recognized as described in Section 3.4.2. 3.4.4 Non-Menu Operation Non-menu display pages sent by the subsystem could contain data or requests for action from the operator. When data or other inputs are needed by the subsystem, they should be entered by the alphanumeric keyboard. See Section 3.4.5 for the procedure.

Data fields on the MCDU can be cleared using the “CLR” key. Pressing the “CLR” key when the scratchpad is empty should result in “CLR” being displayed in the scratchpad. If a “DEL” key exists then it would be used to clear data fields. Then, pressing the line select key adjacent to the data field should result in clearing that data and “Clear/Delete” is removed from the scratchpad. Not all data fields may be cleared. 3.4.7 Exiting The operator can exit from communication with a subsystem by pushing the “MCDU MENU” button and selecting another subsystem or by pressing a special function key for a different subsystem, which should cause the MCDU to perform the sequence described in Section 3.7.3.2. 3.4.8 Proposed Philosophy to Menu Stepping The general philosophy is that the avionics subsystem connected to the MCDU manages the stepping forwards and backwards through the sequence of menus.

3.4.5 Scratchpad and Data Field Entry COMMENTARY The following describes the typical procedure for entering data into the MCDU: Data should be entered through the MCDU keyboard. The data should be entered from left to right into the scratchpad by pressing the alphanumeric keys on the keyboard. After entry of the data into the scratchpad, the data can be moved from the scratchpad into the correct data field by pressing the adjacent line select key. The system should check the data for format and acceptability (out of range, entry not allowed into the field, etc.). An ability to move rapidly through multiple lines of data is

It is very important to standardize the chosen word for backing into previous menus. The most used in today’s applications is generally “RETURN”. Any connected system should allocate a line key for the “RETURN” control. Therefore, there is no need for a specific function key on the MCDU key board. “INDEX” is also typically used for returning to original information. Although it may be commonplace, use of “RETURN” is recommended instead to minimize the potential for confusion.

ARINC CHARACTERISTIC 739A - Page 8 3.0 MCDU DESCRIPTION (cont’d) 3.5 MCDU Outputs The MCDU should have a single output port to provide its own identification and commands to the individual subsystems communicating through the MCDU using thirty-two bit words as defined in ARINC Specification 429, “Digital Information Transfer System (DITS)”. The words transmitted by the MCDU should include MCDU identification (octal label 377), Discrete Word #1 (octal label 270) Maintenance Word #1 (octal label 350) and all words identified by “SAL” in bits 1-8. See Attachment 3 for word formats. Maintenance Word #1 data format is not defined specifically and can be used as the MCDU manufacturer desires.

3.6.3 MCDU Interfaces Involving Dual Subsystem Devices Dual subsystems should consider the following guidelines when controlled by a MCDU. COMMENTARY

3.6 MCDU Inputs 3.6.1 Seven Basic Input Ports The MCDU should provide seven input ports as defined by ARINC Specification 429 for receiving identification information and display data from individual subsystems. Ports #1 and #2 should operate at the high-speed rate (100 Kb/s) and ports #3 and #4 should operate at the lowspeed rate (12-14.5 Kb/s). The ports should have priorities with the highest for #1 and the lowest for #7. The data words listed in Attachment 3 identified with MAL in bits 1-8 should be recognized by the MCDU. It should also recognize the word identified by label 172 as the subsystem identifier. COMMENTARY

c-1

that can operate on multiple airplane models within an airline fleet. For older aircraft that do not have common MCDU dual subsystem switching configurations, it is possible to program the various switching configurations into the MCDU software and use one or more of the unreserved discrete inputs as program pins to identify the aircraft model.

The flight management computer would normally be connected to ports #1 and #2. Communications with a flight management computer is expected to be “generic”. In other words, when an MCDU is communicating with a flight management computer, it would be through the port designated by the program pin status as described in Note 2 of Attachment 1. When this Characteristic refers to the highest priority port (normally #1) and the pin programming has selected port #2, then port #2 should be considered the highest priority port. 3.6.2 Additional Subsystem Input Ports The MCDU may optionally provide additional ARINC 429 input ports for receiving identification information and display data from either a second unit in a dual unit subsystem installation, or from other individual subsystems. These ports may be used to provide MCDU menu selections for additional single-unit subsystems, or may be associated with the subsystems on ports #3 through #7, to create port pairs (e.g., 3A/3B, 4A/4B) to provide a single MCDU menu selection for control of dual-unit subsystems as described in Section 3.6.3. An equivalent number of input discretes may be provided to be used either as program pins to indicate to the MCDU that a particular port pair will handle a dual-unit or subsystem or as a discrete whose state indicates the active unit in a dual-unit subsystem. Further guidance appears in Section 3.6.3. COMMENTARY It is desirable to have a common MCDU part number

In addition to dual FMC or GNLU installations, other subsystems such as SATCOM and CMU may be installed as dual subsystems. There are a variety of techniques used in current aircraft installations and MCDU designs for subsystem displays for these dual device subsystems. These include dedicating separate MCDU input ports and line select keys to each subsystem device or using aircraft wiring-based switching to select between the similar devices, then routing the selected unit to a single port and line select key on the MCDU. Although the use of two line select keys for a dual subsystem provides a simple implementation, using this approach with dual subsystems depletes the number of MCDU menu prompt locations available. This is not desirable from c-1 a flight crew operations viewpoint. Aircraft wiringbased switching reduces the dual subsystem inputs to a single MCDU input port. However, this is undesirable due to design complexity, introduction of new cockpit switching controls, and introduction of a single point failure potential (the switching device). Although implementation of additional input ports and related discrete inputs and software support is optional, MCDU manufacturers should be prepared to handle exposure to multiple subsystem devices such as dual SATCOM, dual CMU, and other possible dual subsystems. It is intended that these additional ports be used for this purpose, as necessary, in conjunction with associated discrete inputs, if applicable. Port pairs may be assigned in the software and use automatic detection of the master or active unit (for example, presence or absence of subsystem label 172, or of the master/slave bit 17 in label 172). In this case, no associated input discrete is required. Port pairs may be assigned in the software and use an input discrete to determine the master or active unit. Typically, this discrete would be controlled by aircraft switching. Two ports may be operated either as single subsystem inputs or as a port pair depending on the state of an input discrete or “program pin”. In this case, if the program pin indicates a port pair, then determination of the master or active unit will most likely use automatic detection or be controlled manually on the subsystem menu page.

ARINC CHARACTERISTIC 739A - Page 9 3.0 MCDU DESCRIPTION (cont’d) COMMENTARY Manufacturers should carefully consider the potential for subsystem failure modes if the automatic detection of master or active unit is selected. For example, if neither unit in a dual unit subsystem declared itself to be the master or active unit, then pilot access may be denied. This method of determining the master or active unit may be more appropriate only for lower priority and/or nonessential subsystems. Attachment 10, MCDU Display Considerations, provides guidance for subsystem-generated menu pages when dual subsystem devices are installed. 3.7 System Communication Communication between the MCDU and the avionics subsystems should be accomplished by serial digital data transmission described in ARINC Specification 429. Specific system interconnection and data transfer protocol are described below. See Attachment 2 for MCDU Address Labels (MALs), Attachment 3 for Word Formats and ARINC Specification 429 for System Address Labels (SALs). These sections describe the MCDU digital protocol as it relates to the initialization data for subsystem interfaces with the MCDU (Section 3.7.1), generation of the MCDU MENU page display (Section 3.7.2), and non-MENU communication with active or inactive systems (Section 3.7.3). 3.7.1 Subsystem and MCDU Identification The MCDU should monitor its ARINC 429 input ports from the aircraft subsystems and decode the 32-bit word identified by octal label 172. This word will contain the System Address Label (SAL) of the avionics in bits 9-16 and will be transmitted at approximately one second intervals. See Attachment 3 for word layout. The MCDU should transmit its MCDU address label (MAL) to an aircraft subsystem using the subsystems SAL in the address field of the “ENQ” word. The specific data communication sequence should be as described in the following sections. See Attachment 3 for the “ENQ” word layout.

3.7.2.1.1 Addressing and Responses Upon power-up the MCDU should attempt communication with aircraft subsystems after a delay period of thirteen seconds. COMMENTARY The delay was defined to allow aircraft subsystems to execute BITE routines and other functions associated with their initiation upon power-up. Ten seconds is considered adequate time for the subsystems to stabilize and three additional seconds to start sending their System Address Label (SAL) identification (label 172) to the MCDU. This Characteristic does not attempt to specify the actual sequence in which the MCDU will start initial menu interrogation of the individual subsystems. Depending on internal circuitry, different MCDUs could interrogate them sequentially. If a sequential method is used, it is recommended that the highest priority port be interrogated first in order that the “first page” of the priority subsystem can be displayed as soon as possible. The MCDU should monitor the input ports for words identified by octal label 172 and determine the subsystem SAL therein. After receiving the valid word, the MCDU should send an “ENQ” command coded for a Menu Text Request and with the label field set to the subsystem SAL A “Request to Send (RTS)” with the MCDU’s MAL in the label field and coded for Menu Text Request would be the normal response of the subsystem. The MCDU should respond with a “Clear-To-Send (CTS)”. The subsystem and MCDU’s RTS and CTS responses should be as defined in the communication protocol described in Section 3.7.3.2 of this Characteristic. Communication with the subsystem should continue with data words and an end-of-transmission word until the menu text has been determined by the MCDU. If the initial communication with the highest priority port (#1, or #2 as determined by the program pin) is successful, then the MCDU should send another “ENQ” word as soon as possible coded for “normal” communications with the priority subsystem as described in Section 3.7.3.2. The “first page” of the highest priority subsystem should be presented on the MCDU display after “normal” communication has occurred.

3.7.2 Menu Generation COMMENTARY 3.7.2.1 Initial Menu The MCDU should attempt to obtain the text for the MCDU menu from the subsystems. The maximum text length should be 18 characters, with the exception described in Section 3.7.2.3. Subsystems on the MCDU menu should be listed in order by port number. If a port does not respond properly or is not active, a space should be left in the menu list. NOTE: when FMCs/GN(L)Us are connected to ports #1 and #2 only a single FMC/GN(L)U menu should be shown since only one FMC/GN(L)U would be active at a time.

The original version of ARINC Characteristic 739 defined bits 17-24 of the RTS word to be set to zero. Supplement 1 to ARINC 739 defines bits 17-20 to be used to distinguish between a response to a normal request and menu text request (see Attachment 3). All MCDUs designed to conform with ARINC Characteristic 739A should encode the RTS word accordingly. The preferred implementation of the RTS word is the version specified by this Characteristic. MCDU manufacturers should exercise caution as some subsystems have defined their protocol using the

ARINC CHARACTERISTIC 739A - Page 10 3.0 MCDU DESCRIPTION (cont’d) 3.7.2.1.1 Addressing and Responses (cont’d)

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

COMMENTARY (cont’d) original version of the RTS word defined in ARINC Characteristic 739. If after thirteen seconds “normal” communications has not been established for ports #1 or #2, then “normal” communications should be attempted for the next highest priority port that had completed the menu text interrogation successfully. If after one additional second, “normal” communications cannot be established with that system, the next highest priority system should be attempted. This procedure should be repeated until “normal” communications has been established with a subsystem. 3.7.2.1.2 Protocol Timing and Responses During initial menu text interrogation, if on an input port a word with label 172 is received by the MCDU, but the 3.7.2.1.2 Protocol Timing and Responses subsystem fails to respond with an “RTS” within one second after the MCDU sends the initial “ENQ”, then a second “ENQ” should be sent. If unsuccessful, a third “ENQ” should be sent one second later. One second after the third (unsuccessful) “ENQ”, the MCDU should assume that the subsystem is faulty. However, once the menu has been created, the MCDU should attempt the menu text interrogation with the non-responding system periodically (every 10 to 60 seconds).

Similarly, a system experiencing intermittent problems could reestablish communication with the MCDU as its health permits. Although it may be considered a nuisance by the crew to have a main menu item disappear and reappear from time to time, it alerts them that a problem does exist with that system. 3.7.2.3 Alternate Menu An alternate menu display format should be used for MCDUs designed for back up navigation data, radio control, and display control. The alternate display format is described in Section 4.2.1. The display menu should be capable of listing all menu items. It is recommended that the MCDU display contain menu items on both sides of the page to accommodate the maximum number of selectable functions and modes. The text for each menu item should be limited to eleven characters. Two menu items per line is permitted, and each menu item should be selected by its respective pushbutton switch, (i.e., item c-1 selected by left button and right menu item selected by right button). COMMENTARY The MCDU should be capable of accommodating up to 18 characters of menu text. In some instances, the available field length may be less than 18 characters and the description of such menu items may need to be shortened to fit in the available space. 3.7.3 Data Communication

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

The following sections describe the protocol when normal communication is desired between an MCDU and an aircraft subsystem.

3.7.2.2 Menu Changes 3.7.3.1 Subsystem Initiated Message Subsequent to the creation of the initial menu, aircraft subsystems operating with the MCDU may be turned on or off by the crew’s use of breakers or by some abnormal condition. The following text describes the desired MCDU reaction in such abnormal situations. After the initial menu has been established and label 172 is lost from a subsystem for three seconds, the MCDU should consider that subsystem to be inoperative and should not attempt to communicate with the system. The MCDU should remove (or flag) the text on the main menu for that particular subsystem. If label 172 suddenly appears on an MCDU input bus after the initial menu has been established (whether or not the communication had previously been established), the MCDU should attempt to establish the subsystem on the main menu using the “Initial Menu” procedure described above. COMMENTARY The ability to change menu dynamically has been provided to handle abnormal situations. A typical situation is that the crew may have elected to keep a system turned off until after take-off. If the menu could not be changed after the initial menu routine

ACARS/CMU and the FMC/GN(L)U are systems typically wanting to send a message to the MCDU without a crew-initiated request. The following sections describe the procedure for subsystem-initiated requests. 3.7.3.1.1 Subsystems Not Currently Active After a system has been established on the menu list, but is not in “active” communications with the MCDU and it has a message for the MCDU, it should send a “Request to Send” (RTS) to each MCDU using the “MCDU Address Label” (MAL) in the label position of the data word (bits 1-8) and coded for a “normal request”. If the system is connected to three MCDUs, it should send the RTS three times successively (once for each different MAL). When the MCDU is not in active communication with that subsystem, this “RTS” message should cause the annunciator lights on the MCDU to come on to alert the crew of a message waiting and should cause the MCDU to display the request status described in Section 3.4.2 when the MCDU menu is on the screen. The MCDU should respond to a “RTS” within 200 milliseconds with a “CTS” with the “Maximum Record Count” set to zero. The subsystem should wait until an “ENQ” is received from the MCDU. The MCDU should

ARINC CHARACTERISTIC 739A - Page 11 3.0 MCDU DESCRIPTION (cont’d) then use the procedure described in Section 3.7.3.2 to initialize communications with the “requesting” subsystem.

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

After an “ENQ” is received from a MCDU, the subsystem should send a Discrete Word (DC4) to the other MCDUs with the appropriate clear request bit set, as defined in Attachment 3. The clear request should extinguish the annunciator light and then delete the request status from the associated subsystem name on the MENU page. The clear request bit should remain set (to “1”) for each MCDU until an “ACK” is returned from the respective MCDUs.

In response to a “RTS” the MCDU should send a “CTS” with the maximum record number and the subsystem’s SAL. The normal subsystem response would be the “STX” providing the initial data as described in Section 3.7.3.3. If a “CTS” word is not received within 200 milliseconds, the subsystem should repeat the “RTS” word. The “RTS” should be repeated 10 times without receiving a “CTS” before dropping the message.

3.7.3.1.2 Active Subsystems When the MCDU is already in active communication with a subsystem and a “RTS” is received from the subsystem, the MCDU should send a “CTS” containing the maximum number of records receivable and the subsystem’s SAL. A zero in the maximum record count should cause the subsystem to wait for a valid “CTS” word for up to one second at which time the message should be dropped.If the maximum record count in the “CTS” word is non-zero and less than the record count in the “RTS” word, the “RTS” should be repeated every 200 milliseconds after each invalid “CTS” word up to ten times before dropping the message. If a “CTS” word is not received from the MCDU within 200 milliseconds, the subsystem should repeat the “RTS” word. The “RTS” should be repeated 10 times without receiving a “CTS” before dropping the message. The subsystem upon receiving a valid “CTS” word should send its transmission to the responding MCDU using the “STX” word and continue as described in Section 3.7.3.3 of this Characteristic. 3.7.3.2 MCDU Communication with Inactive Subystem and Data Request When a new subsystem is selected via the MENU page or special function key, the MCDU should repeat a “LOGOFF” word to the already active subsystem every 200 milliseconds for 1 second or until an “ACK” word is received and then send an “ENQ” with the new SAL, its MAL and coded for a Normal Request. On power-up the logoff is not needed (see Section 3.7.2.1). The subsystem should respond with a “RTS” within 200 milliseconds. COMMENTARY Some MCDUs may be designed to ‘hold’ the prior active user obviating the need to “LOGOFF” the current active user. This avoids the time required to “LOGOFF” the active user and reinitiate communication using “ENQ” if the ‘held’ user is subsequently returned to. If a system is in a ‘held’ state, then this status should be reflected on the menu page. This operation can be beneficial when the system architecture dictates that the crew must frequently toggle between two of the user systems. If no “RTS” is received within 200 milliseconds, the MCDU should repeat the “ENQ” message every 200 milliseconds until a “RTS” is received or a period of one second has elapsed since the first “ENQ”. If no response

If the maximum record count in the “CTS” word is nonzero and less than the record count in the “RTS” word, the “RTS” should be repeated every 200 milliseconds after each invalid “CTS” word up to ten times before dropping the message. 3.7.3.3 Message Transfer Normal message transfer should begin with an “STX” word from the subsystem. See Sections 3.7.3.1 and 3.7.3.2 for message initialization. Every “STX” word should contain the “record word count” to designate the number of ARINC 429 words comprising a record (one record for each line of text). The count should be the number of words between the “STX” and “EOT/ETX” words inclusive. The “record sequence number” should indicate the record sequence within the entire message, e.g., the third record should have a “three”. The “STX” word should be followed by one or more control words and one or more data words. The last word of a record should use the “ETX” word and should repeat the “record sequence number. Unused character positions at the end of a record prior to record sequence number and EOT/ETX should be padded with zeros. The last word of the last record should use an “EOT” word in place of the “ETX” to designate the end of the message. Following the successful reception of a complete message, the MCDU should send an “ACK” within 1.5 seconds. During the subsystem transmission of a message, if a parity check fails or expected word counts and actual word counts are not equal, the MCDU should send a “NAK” word containing the subsystem’s SAL and the record sequence number of the record exhibiting the problem. The subsystem should complete its transmission and attempt to repeat the NAKed portion of the message by using the subsystem initialization procedure described in Section 3.7.3.1. The MCDU should retain the valid records. If an “ACK” or “NAK” is not received by the subsystem within 1.5 seconds, the subsystem should repeat the entire message starting with the first “STX” word. The message should be attempted three times before discontinuing further transmission of the message. If no data words containing the remaining portion of the message are received for a period of 200 milliseconds or the MCDU becomes “confused” in the word counting process, a “SYN” word should be sent to the subsystem. The subsystem should discontinue its message, attempt a

ARINC CHARACTERISTIC 739A - Page 12 3.0 MCDU DESCRIPTION (cont’d) 3.7.3.3 Message Transfer (cont’d) “RTS” as described in Section 3.7.3.1.2 and repeat the entire message. If three successive “SYN” words are received by the subsystem, it should drop the message.

COMMENTARY Since the “DC4” word addresses each MCDU individually, the word would not completely disappear from the subsystem output bus until all MCDUs have responded.

COMMENTARY A “SYN” differs from a “NAK” in that the MCDU can recover portions of the message by using the “NAK”. “SYN” announces to the subsystem that essentially no portion of the message is recoverable and that the entire message must be retransmitted. However, for the purpose of error processing, there is virtually no difference between “SYN” and “NAK” responses. 3.7.3.4 Control (CNTRL) Word The control word should specify the initial character position, the color, the font and the line number at which to start filling the MCDU display. This word may be repeated within a record as necessary. The Display field identifies the characteristic of displayed characters, e.g., reverse video, underscore, blinking. See Attachment 3 for bit assignments. COMMENTARY Not all displays, due to inherent design limitations, have the capability to provide all of the special display effects designated by the bits of the control word. Care should be taken in subsystem design to ensure that operator confusion does not occur if any special display effect cannot be produced by the MCDU. 3.7.3.5 Data Word The data word should specify up to three characters of the set listed in Attachment 4. Carriage return or line feed should not be sent. The control word should be used to accomplish these functions. 3.7.3.6 Background/Vector Words The Standby Navigation capability described in Section 4.2.3 includes an optional map display interface. Section 3.9 of this characteristic describes the interface standards which will enable the MCDU to be used with any manufacturer’s electronic display, designated Electronic Flight Instrument (EFI) herein.

The blanking displays and buffers capabilities have the following intent. When a DC4 word is received with the clear display buffer bit set, the MCDU should clear the input memory buffer used to update the active display buffer. The current MCDU display should not be affected by clearing this buffer. This capability could be applied in cases where there is a need to completely erase the input buffer, allowing for a quick build of a different display. When a DC4 word is received with a blank screen bit set, the MCDU should blank the display via hardware or by the active display buffer The blank screen capability could be used in between page changes to provide a more visible indication of a display page change. 3.7.3.8 Button Push Word The button push word identified by DC1 in bits 19-25 should be sent by the MCDU in response to all alphanumeric, mode keys, and select enter button pushes on the MCDU. The exceptions are that the “MCDU Menu” button and the “line select” keys (while in the Main Menu Mode) will not generate a button push word. The pushbutton code field should contain the code for the button pressed. The valid codes are highlighted in Attachment 4. The sequence number field ranges from 0 to 15 decimal and should be incremented for each new key pressed. A retransmission of a button push should have the same sequence number as the previous transmission. The repeat field is normally a zero and should be set to one key if a key is held continuously for one second. If the key is held for greater than one second the button push word should be repeated at a one second rate with this indicator set. Note that a button push without the repeat indicator set should always precede one with the indicator set. The button push word should always be ACKed by the subsystem unless a parity error is detected. In this case the subsystem should send a “NAK” and the MCDU should repeat the word. If an “ACK” is not received within 200 milliseconds the button push word should be repeated. 3.8 Built-In Test Equipment (BITE) 3.8.1 BITE Considerations

3.7.3.7 Discrete Word A discrete word identified by “DC4” should be sent as needed from the subsystem to all MCDUs at one second intervals. It informs the MCDU of the self-test status of the subsystem and provides the MCDU with commands to blank the display/buffer, extinguish the FMC annunciator light and extinguish the MCDU menu light. The MCDU after recognizing a bit set for a command and executing it should send an “ACK” to the subsystem at which time the subsystem should discontinue sending the “DC4” word to that MCDU.

The MCDU should contain Built-In Test Equipment (BITE) capable of detecting (and optionally annunciating) faults or failures which can occur within the MCDU. 90% BITE coverage should be a design goal. BITE should operate continuously during flight. Monitoring should be automatic and BITE should have the capability to test, detect, isolate and identify intermittent and steady state failures. BITE should display system conditions and indicate the presence of a fault upon the activation of self-test described in Section 3.8.3. The design should minimize the effect of BITE failure on normal MCDU operation.

ARINC CHARACTERISTIC 739A - Page 13 3.0 MCDU DESCRIPTION (cont’d) 3.8.2 BITE Display

3.9.5 Map Display Edit Area

BITE information may be made available on a low speed ARINC 429 bus for use in the centralized fault display as described in ARINC Report 604, “Guidance for Design and Use of Built-In Test Equipment (BITE)”. Alternate MCDUs could be used to display BITE data to the flight crew or maintenance technician while controlling BITE from another unit.

The MCDU may limit the data sent to the EFI to that needed for the viewing window. Editing should only be considered if there is a likelihood of MCDU data exceeding the size of the map data block. 3.9.6 Background Data Prioritizing The MCDU background data priority should be as follows:

3.8.3 Self-Test At the time of MCDU turn-on, a power-up self-test should be automatically initiated as described in ARINC Report 604. Failure conditions should be displayed where possible on the MCDU display.

1. 2. 3.

Primary Flight Plan Flight Plan changes Waypoints

3.9.7 Data Type Word Formats COMMENTARY It is highly desirable that subsystems that are software loadable consider including in their software kernal the ability for an unloaded unit to indicate its unloaded state on the MCDU. This indication could be on the MENU page or a subsystem page depending on the extent of the software kernal in the subsystem. 3.9 Electronic Flight Instrument System Interface The standards in this section represent a subset of those described in ARINC Characteristic 702A. This section addresses the unique subset requirements for the MCDU, leaving ARINC 702A as the complete standard for the EFI interface.

The data type word formats specified in Attachement 6 of ARINC 702A should apply for the MCDU. However, the only data type identification codes expected to be used are as follows: Octal Label 000 014 070 100 164 264 300 301 302 303 330 364

Parameter Fill-in Words Discrete Word-Range Active Standard Waypoint plus Identifier Vector-Active Flight Plan Map Reference Group-Longitude Map Reference Group-Latitude Vector-Active Flight Plan Changes Start of Transmission End of Transmission Start of Dynamic Data Standard Waypoint plus Identifier Discrete Word-Map Mode

3.9.1 MCDU Outputs to EFI 3.9.8 Flight Plan Retention The MCDU should provide one high speed ARINC 429 output port for an EFI. Dynamic data is comprised of ARINC 429 labelled data and may include situational information such as time to go, distance to go, desired track and cross track distance. 3.9.2 MCDU Inputs from EFI The MCDU provides one low speed ARINC 429 data input port through which map mode, scale and option selections are transferred from the EFIs to the MCDU. 3.9.3 MCDU Flight Plan Inputs from FMC The MCDU may provide a capability to receive flight plan information from the FMC/GN(L)U. 3.9.4 Flight Plans and Guidance If the MCDU is capable of receiving information from an FMC, the flight plan data will consist only of fixes, fix identifiers, vectors and conics. The data sequence of lines and conics will be represented by great circle paths between waypoints and a curved transitions between the first path legs only. The MCDU may contain guidance algorithms which generate the guidance commands to a flight control system to track the flight plan.

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

ARINC CHARACTERISTIC 739A - Page 14 4.0 NAVIGATION AND DISPLAY CONTROL 4.1 Introduction

4.2.2.2 General Operation

This section defines the optional features of the Multipurpose Control and Display Unit (MCDU) to provide alternate navigation data source, back-up navigation radio management, and back-up display control. Attachment 9 illustrates optional functions of the MCDU which would be used in addition to the basic functions.

The MCDU radio tuning data should be sent to the appropriate transceiver via a dedicated tuning bus following the activation of the standby radio tuning mode.

As an option, the MCDU may perform the following specialized functions in addition to the multi-purpose operations currently defined in the previous sections of this Characteristic. If the MCDU implements these features, they should be performed as specified herein. a. Standby frequency and tuning control for navigation radio systems such as VHF Omni-Range (VOR), Distance Measuring Equipment (DME), Automatic Direction Finder (ADF), Instrument Landing System (ILS), Microwave Landing System (MLS). b. Independent (stand-alone) navigation with the capability to support the display of simple map on a display system using position data from the Inertial Reference System (IRS) and/or GNSS receiver or GPIRU. The availability of the standby navigation mode of operation provides the ability to improve dispatch reliability and minimum certification requirements for dispatch with long range navigation equipment. c. Mode and selection controls for Electronic Flight Instrument System (EFIS) and Engine Indication and Crew Alerting System (EICAS). COMMENTARY Future updates to this Characteristic may include the need for Differential GNSS (DGNSS) selection. 4.2 Functional Requirements 4.2.1 System Selection and Control The selection of the MENU push-button should result in the MCDU display of a menu page, listing the interfacing systems and available alternate modes. The MCDU should generate the MENU page title, page numbers, line headers, and line text for the MCDU’s alternate modes. 4.2.2 Navigation Radio Tuning

The MCDU should be capable of retaining selected portions of the last FMC transmission of data when the standby tuning mode of operation has been activated. The MCDU monitors its Source Destination Identifier (SDI) pins to determine which corresponding radio data will be continued to be displayed and transmitted. The tuning page should display information which indicates the tuned frequency, course, mode, etc., as well as the auto/manual/remote tuning status of the radios. COMMENTARY The MCDU should monitor its SDI pins to determine when and if a function should be active. For example, the MCDU would inhibit the back up navigation, radio tuning and EFIS/EICAS display functions for MCDU installations which support maintenance systems only. The MCDU should continue to maintain the correct data status and transmit data to the radios following the selection of any other MCDU menu or functions. 4.2.2.3 Navigation Tuning Page Functions The navigation radio page should provide the capability to tune VOR, ADF, ILS and MLS ground stations. The page format should include the display of line headers such as VOR, ADF, ILS-MLS, etc. as appropriate for the specific radio being tuned. Valid data entry should be monitored on the basis of frequency range, course azimuth, elevation, and increment as appropriate for each radio type. Valid entries may also be accompanied by an indication that it is a manual selection (this would provide consistency with an FMC radio page which will provide both automatic and manual selection indications). Incorrect entry to the MCDU should result in the display of an INVALID ENTRY message. Deletion of an ILS/MLS entry should result in reversion to the PARK mode. For ADF radios the MCDU should be capable of commanding the Beat Frequency Oscillation (BFO), Antenna (ANT), and ADF modes.

4.2.2.1 Mode Selection The MCDU should provide the capability to tune DME, VOR, ADF, ILS and MLS radios. This function is an alternative to the radio tuning capability provided as part of a dedicated radio management panel. Navigation radio tuning should be integral to MCDU design where all normal radio management is accomplished by a Flight Management Computer (FMC). The navigation radio tuning page should be accessible via a dedicated function button appearing on the FMC pages of the MCDU.

For ILS or MLS receivers the MCDU should be capable of determining radio type automatically from manual entry. The MCDU should have the capability to determine DME frequency pairing with VOR, ILS or MLS by using the mode data from external sources such as EFIS control panel and/or cockpit switches.

ARINC CHARACTERISTIC 739A - Page 15 4.0 NAVIGATION AND DISPLAY CONTROL (cont’d) 4.2.2.3.1 Tune Inhibit The MCDU should inhibit any changes in the selected ILS/MLS frequency when a tune inhibit condition exists. It is expected that this condition would exist only during auto-land conditions. 4.2.2.4 Interface Requirements The MCDU should transmit radio tuning data on a dedicated low speed ARINC 429 output port. In addition, the MCDU may provide the following discretes:

FMC/N(LG)U data bus to determine when the loss of activity occurs. COMMENTARY Provision of a manual activation capability in the MCDU should be given careful consideration to factors such as: a. clear and unambiguous indications that the standby capability is being used; b. means to ensure no potential confusion by flight plan changes in the standby mode which are not reflected in the FMC/GN(L)U; and c. a means to return to normal operation with the FMC/GN(L)U. 4.2.3.2 Operation

a. L-DME and R-DME audio discretes where an open state represents DME paired with VOR, and a ground condition represents DME paired with ILS or MLS. b. ILS/MLS select discrete where an open state represents ILS station selected and a ground condition represents MLS station selected. c. ILS/MLS PARK discrete where an open state represents NOT PARK and a ground condition represents PARK. An external source should be able to inhibit changes to ILS/MLS tuning (i.e., during autoland) using the PARK discrete. d. Normal/Standby to enable radios to determine which input port to select for tuning control. The MCDU should have the capability to receive and process the following analog discretes: a. ILS Tune Inhibit The radio tuning command and digital discrete data words generated by the MCDU should conform to the guidelines of the appropriate ARINC Characteristics to which the radio is designed. COMMENTARY The analog discrete interfaces described herein should also have corresponding digital discretes to allow for appropriate flexibility for various installation configurations. In addition, analog discretes such as PARK may not be necessary if the backup radio control design automatically defaults to full featured operation in order to avoid exposure to any other faults.

4.2.3.2.1 General The MCDU should be capable of performing a role as independent (stand-alone) navigator using the Inertial Reference System (IRS) and/or a GNSS receiver or a GPIRU as the means of navigation. COMMENTARY When multiple positioning sources are allowed, it may be necessary for the MCDU to provide an indication of it’s navigation source, depending on the system integration and implementation. 4.2.3.2.2 Navigation and Guidance Under normal operation each MCDU receives flight plan data from its onside FMC/GN(L)U, consisting of active route waypoint latitudes/longitudes and waypoint names. If there is a valid FMC/GN(L)U available the MCDU should receive an update to a flight plan upon sequencing the active waypoint or following the activation of a modification to a flight plan (i.e., direct-to, approach change, waypoint deletions/additions, etc.). When the standby navigation mode becomes active due to the detection of an FMC/GN(L)U failure, the MCDU should use the last received FMC/GN(L)U flight plan and IRS/GNSS data to maintain an active standby flight plan. If the MCDU detects no valid IRS or GNSS input when the standby navigation mode becomes active, it should generate an appropriate failure indication by removing the affected MCDU page display or by disabling access to the affected page. When operating in the standby navigation mode, the MCDU should allow only flight plan changes using direct-to waypoint, entered and line selected lat/long waypoints, line select closure of discontinuities, and line selected insertion and deletions. Direct-to selections should be made by line selection of a waypoint identifier or lat/long on the appropriate MCDU page. 4.2.3.2.3 CDU Page Access

4.2.3 Standby Navigation 4.2.3.1 Mode Selection The standby navigation mode, if provided, should be capable of being activated either manually by crew intervention, or automatically, if for example, the MCDU detects a failure in the selected FMC/GN(L)U. The MCDU should monitor the activity of the selected

When the MCDU activates the standby navigation mode, it should be capable of generating at least two types of display pages for flight plan data, radio tuning and flight progress status, as appropriate. When the MCDU standby navigation mode is activated, all purely FMC/GN(LU) push button functions should become inoperative. The MCDU pages which display

ARINC CHARACTERISTIC 739A - Page 16 4.0 NAVIGATION AND DISPLAY CONTROL (cont’d) 4.2.3.2.3 CDU Page Access (cont’d)

k. Track Angle Error

standby flight plan data generated by the standby navigation function should be available, but should be clearly identified as displaying standby data. The standby flight plan data pages should be displayed in response to the corresponding MCDU function keys.

l. Cross Track Acceleration

With an invalid FMC/GN(L)U, the selection of a function key, which would normally be used to access an active flight plan related page, should provide direct access to the active standby navigation pages. The desired course to the current active waypoint, as displayed on the active standby flight plan related pages, should be referenced to magnetic north if IRS magnetic referenced data is available. Otherwise, the course to any waypoint should be displayed relative to true north. A T or M should be displayed by all course information to denote the reference being used. COMMENTARY It may be desired that the course indications (M or T) be selected by a program pin. One possible approach is that a ground (logic “0”) represents all true heading courses and logic “1” represents magnetic heading for desired course and blank for all others.

The standby navigation function should be designed to the guidelines established by SC-181 MASPS for RNP Navigation. The standby navigation function, at a minimum, should provide for RNP default and entry, computation of Estimated Position Uncertainty (EPU), and the associated alerting displays. The MCDU should continuously update data at the rate appropriate to the data’s function, using inputs from the IRS and/or GNSS receiver, and the last FMC cross-load flight plan data. The data will be available for advisory display and other functional use when the standby navigation mode is active. 4.2.3.2.5 Map Display The MCDU may be capable of generating formatted data which can be used by an EFIS type system to generate a map display on the Navigation Display (ND) unit. Map data should be consistent with vectors, waypoints, identifiers, etc., as computed by the FMC/GN(L)U. The Map Display interface should be as described in Section 3.9 of this Characteristic.

4.2.3.2.4 Navigation Computations The MCDU should be capable of generating informative navigation parameters for display on its own screen and/or transmitted to other displays as specified by the operator. The parameters, specified by the operator, are generated using data primarily from the IRS and/or a GNSS receiver, and the flight plan most recently received from the FMC. The standby navigation function may provide for integration of the inertial and GNSS sensor data in a manner that allows “coasting” through temporary loss of GNSS information. The parameters computed by the standby navigation function may include any or all of the following, or others as determined by the requirements of the operator: a. Present Position b. Present Track

The EFIS and the MCDU may be configured in a variety of ways to effect a map display on the ND which is responsive to the selected mode and range commands. One preferred way is for the MCDU to receive mode/range commands directly from the EFIS control panel and transmit map data to the EFIS accordingly. In this case the MCDU may have the capability of providing a page to serve as backup to the EFIS control panel if it fails. Another preferred way is to configure the EFIS and the MCDU such that the MCDU transmits the entire flight plan as most recently received from the FMC, and the EFIS produces the map display in accordance with the mode/range commands received from the control panel. The MCDU, in this case, does not necessarily have the capability of providing backup EFIS control panel capability.

c. Desired track to the next waypoint d. Heading (if IRS is available) e. Cross Track Deviation f. Distance to next waypoint g. Time to go to the next waypoint and between route waypoints (if GNSS data is unavailable), otherwise estimated time of arrival (if GNSS data is available) h. Wind speed and direction (if IRS is available) i. Waypoint alert j. Ground Speed

If GNSS data is available, the standby navigation function should compute and display ETAs associated with waypoints and destination, otherwise the time should be displayed as the Time To Go (TTG) when in the Standby Navigation mode. 4.2.3.3 Interface Requirement The MCDU should process data received from a dedicated Inertial Reference System (IRS) and/or GNSS receiver or GPIRU. Additionally, the MCDU should be designed with the capability to process the same data format transmitted on the current FMC/IRS hi-speed ARINC 429 interface.

ARINC CHARACTERISTIC 739A - Page 17 4.0 NAVIGATION AND DISPLAY CONTROL (cont’d) The MCDU should monitor the status of the analog discrete interface to determine the selection of the standby navigation mode, by an open/ground indication. It should be capable of processing mode and range received on the EFIS control panel interface. When the standby navigation mode has been activated, the MCDU should set the Signed Status Matrix (SSM) bits for flight path angle, range to altitude and vertical deviation to no-computed data when the standby navigation mode has been activated.

4.2.4.3 Interface The MCDU should transmit the alternate EFIS control panel page data on its display control panel bus. Data transmission will begin when the page function becomes active. Data transmission should cease if the EFIS CP becomes valid for one second. The digital data characteristics should be the same as the original EFIS control panel inputs.

4.2.4 Alternate EFIS Control COMMENTARY 4.2.4.1 General The MCDU may provide the capability to generate MENU selectable display pages as an alternate to the EFIS control panel. The alternate EFIS control panel page function should automatically activate when a total bus loss has been detected for an EFIS control panel input. When the failure is detected, the MCDU should initialize its EFIS control panel pages using the last processed EFIS panel selection. The page data can include mode, range, VOR course, decision height (DH), DH reset, and barometric altimeter setting.

A good design approach would consider automatic bus switching within the MCDU. With this design, if the EFIS CP is valid, the MCDU will pass the EFIS CP data directly onto its control panel bus. If the MCDU detects the loss of data for one second, its bus monitor should then switch control of the bus to its internal control panel function. 4.2.5 Alternate EICAS Control

4.2.4.2 Page Access 4.2.5.1 General The EFIS CONTROL page should be accessible via a menu prompt on the MENU page. The MCDU should restrict page access based upon the bus status of the EFIS control panel (CP) input. If the EFIS CP is valid, the MCDU should have the capability to list the EFIS control item but preclude page access. If the EFIS CP is invalid (loss of all data activity for one second), the EFIS control functions should automatically become active and page access should be allowed. Access between the EFIS control panel pages will be provided by line select key prompts on each page.

The MCDU may provide the capability to generate MENU selectable display pages as an alternate to the EICAS control panel. The alternate EICAS control panel page function will become active automatically when the MCDU detects a total bus loss for its control panel input. The MCDU will initialize its alternate EICAS control panel pages for no selections. 4.2.5.2 Page Access

The MCDU should automatically return to the MENU page if an alternate EFIS control panel page is being displayed and the EFIS CP bus becomes valid for one second. If an alternate EFIS control panel page is not being displayed, the MCDU page display will not be affected.

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

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

The MCDU should automatically return to the MENU page if an alternate EICAS control panel page is being displayed and the control panel bus becomes valid for one second. If an alternate EICAS control panel page is not being displayed, the MCDU page display should not be affected.

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

The NEXT/PREV keys should be the only function push buttons associated with the ALTN EICAS CONT page. 4.2.5.3 Interface

Consideration should also be given to the bus fail/page access criteria. An alternate approach is to have the MCDU monitor selected parameters. For example, if the barometric altimeter data word has no-computed-data, or failure warning sign status, only access to the EFIS control panel pages would be allowed.

The MCDU should transmit the EICAS page data on its display control panel bus. Data transmission will begin when the page function becomes active. A MCDU maintenance word, label 351, should be the discrete word which is transmitted to the EICAS to indicate that a nonselected system is requesting attention.

ARINC CHARACTERISTIC 739A - Page 18 4.0 NAVIGATION AND DISPLAY CONTROL (cont’d) 4.2.5.3 Interface (cont’d) COMMENTARY System integrators may find it desirable to utilize an analog discrete interface to identify requesting systems on the EICAS. If implemented, the analog discretes signals should utilize pins 31-33 and identify them as FMC Request, ACARS Request, and Menu Request respectively. The MCDU should suspend transmission of data if its control panel bus becomes valid for one second. The MCDU should respond to mode function line selections by momentarily setting the appropriate digital discrete for a period of one-half to one second. The digital data characteristics should be the same as for the original EICAS input data. Similar to the alternate EFIS controls, the MCDU designer should consider automatic bus switching in the MCDU. 4.2.6 System Communication 4.2.6.1 Inter-System The handshake and digital data transfer communication between the MCDU and all other interfacing avionics systems (including the FMC) should be based on ARINC 4.2.6.1 Inter-System (cont’d) Specification 429, “Mark 33 Digital Information Transfer System (DITS)”. COMMENTARY The MCDU should be able to receive updates to its flight plan and/or radio tuning data even when it is under active control of another system. It is recommended that this be accomplished by the use of a priority level such as the system ID labels. Each broadcast label should be the initial word of a block data transmission. This approach will allow the MCDU to have essentially transparent foreground processing of flight plan and/or radio data which may occur concurrently with the basic handshake/log-on protocol. 4.3 Hardware Requirements 4.3.1 General The following enhancements to the existing ARINC Characteristic 739A would enable the MCDU to provide functions of radio tuning and standby navigation. 4.3.2 Interwiring Definition If the functions described in Section 4 of this Characteristic are implemented in the MCDU, it should have two interwiring connectors. The basic connector is described in Section 2.2. An additional connector should be provided for the interfaces and physical/functional isolation required for radio tuning and standby navigation functions. The optional connector

is also defined in Section 2.2. The pin assignments for both the Basic Connector and Optional Connector are defined in Attachment 1. 4.4 Standby Navigation Lateral Guidance Some users may desire the MCDU to compute a lateral steering signal for use by the Flight Control Computers (FCC). The steering signal should be continously computed when there is an active waypoint identitifed. The steering signal should be based upon the same control laws as used for lateral steering in the FMC, considering cross-track deviation, track angle error, ground speed and track intercept. Lateral turn anticipation should be included for waypoint transition. The data should be transmitted on a low-speed ARINC 429 bus in the same format as that produced by the FMC. COMMENTARY It should be noted that the aircraft system architecture, operating modes and configurations, failure rates, undetected failure rates, and system safety assessment are among the considerations necessary to determine when and how these capabilities may be utilized.

ARINC CHARACTERISTIC 739A - Page 19 ATTACHMENT 1 STANDARD INTERWIRING BASIC CONNECTOR: FUNCTION Future Spare Onside FMC Onside FMC Future Spare Offside FMC Offside FMC Future Spare Input Port #3 Input Port #3 Future Spare Input Port #4 Input Port #4 Future Spare Input Port #5 Input Port #5 Future Spare Input Port #7 Input Port #7 Future Spare Future Spare Future Spare 28 VDC Inst. Power Program Return Input Port #6 Input Port #6 Shield Ground Output Port Output Port Act Port Prog CDU Location CDU Location CDU Fail Discrete Lamp Test Chassis Ground Ann. Bright/Dim Ann. Bright/Dim 5 Vac Light 5 Vac Light 28 Vdc Inst. Power 115 Vac, 400HZ 115 Vac, 400HZ

MCDU

] AB ] ] AB ] ] AB ] ] AB ] ] AB ] ] AB ] C

] AB ] ] AB ]

] Hi Lo ]] H C ]H ] HC ]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

AIRCRAFT o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o

WIRE I-R [5]

Onside FMC (High Speed)

D-5 D-5

Offside FMC (High Speed)

D-5 D-5

Aircraft Subsystem

D-5 D-5

Aircraft Subsystem

D-5 D-5

Aircraft Subsystem

D-5 D-5

Aircraft Subsystem

D-5 D-5

Aircraft Subsystem

D-5 D-5

Aircraft Subsystem

D-5 D-5

DC Ground

1-0.1

5 VAC Panel Light Supply 2A 115 VAC 400 Hz Aircraft Power

2-0.1 2-0.1

ARINC CHARACTERISTIC 739A - Page 20 ATTACHMENT 1 (cont’d) STANDARD INTERWIRING OPTIONAL CONNECTOR: FUNCTION Future Spare Onside IRU (GPIRU) Onside IRU (GPIRU) Future Spare EFIS Cont. Panel EFIS Cont. Panel Future Spare Display Output Display Output Future Spare Gen. Bus Output Gen. Bus Output Future Spare EFIS Cont. Output EFIS Cont. Output Future Spare Future Spare Discrete Input (Spare) Discrete Input Discrete Input Discrete Input Future Spare Discrete Input Discrete Output Discrete Output Discrete Output Discrete Input Discrete Output Future Spare Discrete Input Discrete Output Discrete Output Discrete Output Future Spare Onside GNSS Onside GNSS Future Spare Future Spare Future Spare Future Spare Future Spare

MCDU

] AB ] ] AB ] A ]B ] ] BA ] ] AB ]

] AB ]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

AIRCRAFT o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o

WIRE I-R [5]

Onside IRU (High Speed)

D-5 D-5

EFIS Control

D-5 D-5

Aircraft Subsystem

D-5 D-5

Aircraft Subsystem

D-5 D-5

Aircraft Subsystem

D-5 D-5

GNSS

ARINC CHARACTERISTIC 739A - Page 21 ATTACHMENT 1 (cont'd) NOTES ON STANDARD INTERWIRING 1.

Pins 30 and 31 should be used for encoding MCDU position in the aircraft and the appropriate MCDU Address Label (MAL) for identification. The following encoding scheme should be employed on the connector. MAL 220 221 222 230

2.

PIN 30

31

To Pin 23 Open To Pin 23 Open

Open To Pin 23 To Pin 23 Open

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

3.

A “ground” on pin 33 should cause a lamp test to be executed.

4.

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

5.

The “I-R” values define the maximum current (I) in amperes and effective resistance (R) in ohms for which the installation and equipment should be designed. It is anticipated that installation designers will use these figures, together with the lengths of the cable runs in a given airframe, to calculate the gauge of each wire in the installation. Where their calculations reveal the possibility of using higher gauge numbers than #22 AWG, they are asked to stop and consider whether the mechanical strength of this wire is adequate for the installation before deciding to use it. The airlines report recent sad experiences with such wire, and although they are, of course, interested in the weight saving its use affords, they will quickly point out that these savings are rapidly nullified by maintenance costs if frequent breakage occur. NOTE: Wires for which a “D” symbol is shown in place of a current rating may be used for any function ranging from “Dry Circuits” (hence “D”) to 5 ampere applications. Both installation and equipment designers should give due regard to special cases wherein parallel or series-parallel connected circuits may result in higher currents or voltage drop (effective resistance) than in simple circuits. Unless otherwise noted, the current limit set forth applies to all elements of parallel or series-parallel circuits.

ARINC CHARACTERISTIC 739A - Page 22 ATTACHMENT 2 ADDRESS LABELS

MCDU NO.

MCDU ADDRESS LABEL (OCTAL)

1

220

2

221

3

222

4

230

NOTE: See Attachment 1 for MCDU number pin coding.

ARINC CHARACTERISTIC 739A - Page 23 ATTACHMENT 3 DIGITAL WORD FORMATS RTS WORD 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 P DC2 0 SEE BELOW 0 RECORD COUNT

9

8

7

6

5 4 MAL

3

2

1 MSB

BITS

FUNCTION

20

19

18

17

0 0 0

0 0 0

0 0 1

0 1 0

1

1

• • 1

1

NORMAL REQUEST MENU TEXT REQUEST SPARE • • 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 P DC3 0 MAX RECORD COUNT 0

9

8

7

6

5 4 SAL

3

2

1 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 P STX 0 RECORD SEQUENCE 0 RECORD WORD COUNT NUMBER

8

7

6

5 4 MAL

3

2

1 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 INITIAL P CNTRL F COLOR LINE FUNCTION CHARACTER NUMBER SEE SEE BELOW POSITION BELOW

COLOR

8

7

23 0

BITS 22 21 0 0

BLACK

16 0

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

6

5 4 MAL

3

BITS FUNCTION 15 14 0 1 REVERSE VIDEO (OPTIONAL)

2

1 MSB

ARINC CHARACTERISTIC 739A - Page 24 ATTACHMENT 3 (cont’d) DIGITAL WORD FORMATS DATA WORD 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 P CH #3 0 CH #2 0 CH #1

9

8

7

6

5 4 MAL

3

2

1 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 P CH #6 0 CH #5 0 CH #4

9

8

7

6

5 4 MAL

3

2

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

9

8

7

6

5 4 MAL

3

2

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

9

8

7

6

5 4 MAL

3

2

1 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 P DC1 R PUSH BUTTON 0 SEQUENCE CODE NUMBER

9

8

7

6

5 4 SAL

3

2

1 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 P DC1 F CHARACTER COLOR INITIAL SEE CHARACTER BELOW POSITION

BITS

COLOR

16

15

14

0

0

0

BLACK

0

0

1

CYAN

0

1

0

RED

0

1

1

YELLOW

1

0

0

GREEN

1

0

1

MAGENTA

1

1

0

AMBER

1

1

1

WHITE

8

7

6

5 4 MAL

3

2

1 MSB

ARINC CHARACTERISTIC 739A - Page 25 ATTACHMENT 3 (cont’d) DIGITAL WORD FORMATS ACK/NAK WORD From MCDU 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 P ACK/NAK 0 RECORD 0 SEQUENCE NUMBER

9

8

7

6

5 4 SAL

3

2

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

9

8

7

6

5 4 3 MAL/SAL

2

1 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 P DC4 DISCRETE BITS (SEE BELOW)

BIT 9* 10 11 12 13 14 15 16 17 18 19* 20 21 22 23 24

9

8

7

6

5 4 MAL

3

2

1 MSB

FUNCTION (when set to “1”) Self-Test (Subsystem from which the MCDU receives the word is in self-test) Blank Screen Clear Display Buffer Clear FMC Request Clear Subsystem Request (not used with FMC and ACARS) Clear ACARS Request EXEC Annunciator DSPY Annunciator Applies only to MCDUs with Annunciator MSG Annunciator - Receipt of logic “1” lights Annunciator OFST Annunciator - Receipt of logic “0” extinguishes Annunciator MCDU Test Request Receipt from allowed subsystem causes MCDU to execute self-test - Inputs to MCDU during self-test are ignored Spare Spare Spare Spare Spare * NOTE: In some installations, the functions of bits 9 and 19 are reversed.

SYN WORD 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 P

SYN

9

8

7

6

0

5

4

3

2

1

3

2

1

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 P

TBD

9

8

7

6

5

4

ARINC CHARACTERISTIC 739A - Page 26 ATTACHMENT 3 (cont’d) DIGITAL WORD FORMATS BACKGROUND WORD 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 P

9

8

7

6

5

4

3

2

1

9

8

7

6

5 4 SAL

3

2

1

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

MSB

•

•

•

• 1

1

SPARE

SUBSYSTEM IDENTIFIER (from Subsystem) 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 P

0

9

8

7

SUBSYSTEM SAL

6

5

4

3

2

1

2

1

2

1

SUBSYSTEM ID (LABEL 172)

MSB

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

MCDU IDENTIFIER (from MCDU) 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 P

0

DECIMAL “3”

9

8

7

DECIMAL “9”

6

5

4

3

SUBSYSTEM ID (LABEL 377)

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

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

0 = Port Selected or Inactive 1= Non-Selected Port Request for Attention

8

7

6

5

4

3

EICAS ID (LABEL 351)

ARINC CHARACTERISTIC 739A - Page 27 ATTACHMENT 3 (cont’d) DIGITAL WORD FORMATS MCDU NORMAL DISCRETE WORD (270) FUNCTION BIT STATUS 1 X

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

0 X

LABEL 270 (OCTAL)

X X X X X X

NOT USED NOT USED PORT #1 RECEIVER PORT #1 DATA INPUT PORT #2 PORT #2 PORT #3 PORT #3 PORT #4 PORT #4 PORT #5 PORT #5 PORT #6 PORT #6 PORT #7 PORT #7

FAILED FAILED

NORMAL NORMAL

FAILED

NORMAL

*OPTIONAL PORTS (SEE BELOW) SPARE MCDU STATUS SSM SSM PARITY

c-1

BIT NORMAL PORT A FAILED PORT B FAILED PORT C FAILED PORT D FAILED PORT E FAILED PORT F FAILED PORT G FAILED *NOTE:

OPTIONAL PORTS HEALTH STATUS 27 26 0 0 0 0 0 1 0 1 1 0 1 0 1 1 1 1

See Section 3.6.2 for description of optional ports.

25 0 1 0 1 0 1 0 1

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

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

BIT 3

BIT 2

BIT 1

0

0 0

0 0

0

0 1

1

1 1

0

1 0

1

1 0

0

1 1

1

1

0

1

Column

→ Row

↓

0

1

2

3

SP

0

4

5

6

7

P

MCDU MENU

SEL1

0

0

0

0

0

NUL

0

0

0

1

1

CNTRL

DC1

!

1

A

Q

SPECIAL FUNCTION

SEL2

0

0

1

0

2

STX

DC2

"

2

B

R

KEYS 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

V

PREV PAGE

0

1

1

1

7

/

7

G

W

NEXT PAGE

1

0

0

0

8

(

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

1

1

0

1

13

o

-

=

M

]

1

1

1

0

14

↓

.

>

N

↑

∆

1

1

1

1

15

→

?

O

←

or

CLR

LOG OFF

SER5

SER6

∆

CLR/ DEL

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

ARINC CHARACTERISTIC 739A - Page 29 ATTACHMENT 5 ENVIRONMENTAL TEST CATEGORIES The following environmental specifications for the Multi-Purpose Control and Display Unit (MCDU) reflect RTCA DO-160D categories. Designers should use the current version of RTCA DO-160.

ENVIRONMENT (DO-160D) Temperature & Altitude In-Flight Loss of Cooling Temperature Variation Humidity Operational Shock and Crash Safety Vibration (1) Explosion Proofness Waterproofness (2) Fluids Susceptibility Sand and Dust Fungus Resistance Salt Spray Magnetic Effect Power Input Voltage Spike Audio Frequency Conducted Susceptibility – Power Inputs Induced Signal Susceptibility Radio Frequency Susceptibility (Radiated and Conducted) Emission of Radio Frequency Energy Lightning Induced Transient Susceptibility Lightning Direct Effects Icing Electrostatic Discharge (ESD)

Section 4 4.5.4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Category CAT A1 CAT Z CAT C CAT A CAT B CAT S CAT X CAT X CAT X CAT X CAT X CAT X CAT Z CAT A CAT A CAT A CAT Z CAT V CAT M CATA3E3 CAT X CAT X CAT A

1.

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

2.

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

c-1

ARINC CHARACTERISTIC 739A - Page 30 ATTACHMENT 6 TYPICAL SYSTEM CONFIGURATION

•

MCDU 1

•

•

•

MCDU 2

•

•

•

• MCDU COMMAND BUSES

FMC 1

FMC 2

ACARS

SUBSYSTEM RESPONSE BUSES NOTE: These could be dedicated to theMCDU or could be normal operational data buses (shared).

ARINC CHARACTERISTIC 739A - Page 31 ATTACHMENT 7 TYPICAL FRONT PANEL LAYOUT

ANNUNCIATOR FOR THE SYSTEM HAVING PRIORITY

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

NEXT PAGE

MAIN MENU

CALL

A

B

C

D

E

F

G

H

I

J

1

2

3

K

L

M

N

O

4

5

6

P

Q

R

S

T

7

8

9

U

V

W

X

Y

/

0

.

Z

+

-

SP

CLR

ARINC CHARACTERISTIC 739A - Page 32 ATTACHMENT 8 GLOSSARY

ACARS ACK AIDS BITE CDU CFDIU CLR CTS DEL EFIS EICAS ENQ EOT ETX CFDS FMC GN(L)U IRS ISO MAL MCDU NAK RNP RTS SAL SATCOM SDI SSM STX SYN

Aircraft Communications Addressing and Reporting System Acknowledge Transmission Aircraft Integrated Data System Built-In Test Equipment Control/Display Unit Central Fault and Display Interface Unit Clear Clear to Send Delete Electronic Flight Instrumentation System Engine Indication and Crew Alerting System Enquire End of Transmission End of Text Central Fault and Display System Flight Management Computer GNSS Navigation (and Landing) Unit Inertial Reference System International Organization for Standardization MCDU Address Label Multi-Purpose Control and Display Unit Not-Acknowledge Transmission Required Navigation Performance Request to Send System Address Label Satellite Communication Source Destination Identifier Signed Status Matrix Start Transmission Transmission Not Understandable/Recoverable

ARINC CHARACTERISTIC 739A - Page 33

ATTACHMENT 9 OPTIONAL MCDU FUNCTIONS

BASIC 7 ARINC 429 INPUTS FROM SYSTEMS

MCDU BASIC ARINC 739 FUNCTIONS

ADDITIONAL INPUT

+

IRS INPUT

*

GNSS INPUT

*

NEW NAV RADIO TUNING FUNCTION * NEW, BACK-UP NAVIGATION FUNCTION * NEW, OPTIONAL LATERAL CONTROL *

MONITOR EICAS CP and EFIS CP OUTPUT BUS

*

HANDSHAKE OUTPUT TO SYSTEMS + INPUT STATUS LABEL

* NAV RADIO TUNING

* NAV DISPLAY

* AUTO PILOT

NEW, BACK-UP EICAS CONTROL FUNCTION *

* EICAS ALTERNATE CONTROL

NEW, BACK-UP EFIS CONTROL FUNCTION *

* EFIS ALTERNATE CONTROL

ARINC CHARACTERISTIC 739A - Page 34 ATTACHMENT 10 MCDU DISPLAY CONSIDERATIONS 1.0 General This attachment is considered as guidance and is provided only for example. Specific implementations may vary. 1.1 Display The MCDU screen will accommodate 14 rows of 24 characters each. The top line can be referred to as the title line and the bottom line can be referred to as the scratch pad. The title line should normally be used to indicate the active subsystem and function being accessed. The scratch pad should be used to display messages to the crew and to reflect keyboard entry of data which can then be shifted to an appropriate field on the display by pressing the adjacent line select key, as described in Section 2.4.1. The 12 middle rows on the display should be viewed as six paired lines where each pair consists of a “header line” and a “data line”. A line select key is positioned adjacent to each end of each data line. In describing formats and operations, it is convenient to refer to the pairs as lines 1 through 6 and the line select keys as 1L through 6L and 1R through 6R. If a display application requires lengthy text messages, multiple lines may be used. However, the remaining lines should preserve the header line and data line distinction. Each line can be divided into one, two or three fields as desired. When a center field is defined, it should be a display only field. Field widths are variable and should be sized by the data they will contain. At least two spaces should be left between fields. In laying out fields, consideration should be given to display readability. Too much data on a page can make scanning difficult, thereby rendering it ineffective inflight and undesirable for maintenance use as well. 2.0 Display Format Conventions 2.1 Title Line When a subsystem is in communication with the MCDU, the subsystem generated page title should clearly identify that subsystem and/or the function being accessed. The page title should be displayed using the large font alphanumeric characters. This convention ensures that in the case of typical cockpit operations, the flight crew will always have a clear indication of the active subsystem and function to aid in the mental reorientation required after any number of interruptions. For example, “ACARS” would appear in the title of an ACARS control c-1 page. Similarly, “ACMS” would appear on ACMS pages, etc. To avoid confusion, use of another subsystem’s key words must be avoided in the title line. When a subsystem consists of two identical units, either master/slave, or master/hot spare, or both units operating at the same time and performing complimentary functions, the subsystem may generate an introductory or top level menu page that provides capability to select and/or display which of the two units is active or is primary. In these cases, the MCDU-generated menu page should have a single prompt for access to the subsystem-

generated menu page where the L/R (or onside/offside, etc.) select/display capability is provided. The subsystemgenerated introductory or top-level menu page TITLE LINE should clearly identify the subsystem without an indication of “L” or “R”, or onside/offside, etc. For example “ACARS”. An indication such as “ACTIVE” or other distinct indication in a HEADER or DATA line (Sections 2.2 and 2.3) or a combination of the two, may be used on the subsystem-generated menu page to designate which unit is in control, if appropriate. If the architecture is such that the two subsystem units are performing complimentary functions and a master/slave or similar hierarchy does not apply, then the subsystemgenerated menu page can simply provide access to either unit without indication of a primary or master. Use of a subsystem-generated menu page for display and control of dual subsystem units reduces space demands on the MCDU-generated menu page by requiring only one, rather than two, line select positions. In a dual unit subsystem installation where one of the units has been selected for display, (via line selection from either the MCDU menu page or the subsystemgenerated menu page) the particular unit should be clearly identified in the TITLE LINE of the subsystem page for ease of identification. For example: “ACARS - L”. If appropriate for the architecture, an indication in another location on the subsystem page may indicate whether or not that unit is “primary” or “master”. When one unit in a dual installation is the active MCDU subsystem, the c-1 subsystem will be designated as “ACTIVE” on the MCDU-generated menu page as described in Section 3.4.2. Selection of the subsystem prompt on the MCDUgenerated menu page in this case should result in direct access to the active unit subsystem page without having to go to the subsystem-generated menu page. Many pages overflow the screen space. When this happens, a display page can be considered to consist of multiple screens/pages of data and should be numbered on the right end of the title line. For example, if there are two pages they should be numbered “1/2” and “2/2” using numbers in small font. In cases where the total number of pages may be variable, the total pages available must be determined and identified. The NEXT PAGE and PREV PAGE keys should be used to move back and forth through these multiple pages. Unless some unique requirement dictates otherwise (such as scrolling), pressing NEXT PAGE when viewing the last page should roll the display to page 1/xx and pressing PREV PAGE when viewing page 1/xx should roll the display to the last page. When there will never be more than one page for a given title, the page number (i.e., 1/1) need not be displayed. However, “1/1” should be displayed in cases where more than one page could exist under different circumstances. Titles should be static (invariant). However, some may change or be enhanced with superimposed words to indicate a submode, submenu, etc. Use of dynamic titles should be avoided. Also, titles should be kept as short as possible rather than strive to identify every function on the page. It should be recognizable at a glance. A

ARINC CHARACTERISTIC 739A - Page 35 ATTACHMENT 10 (cont’d) MCDU DISPLAY CONSIDERATIONS consistently used abbreviation is preferable to a long word (e.g., use MAINT rather than MAINTENANCE). The title should not overflow onto the next line. If a c-1 subtitle is absolutely necessary, it should be centered on the 1C header line (i.e., in field 1C) and use of the 1L and 1R header and data lines restricted to keep the subtitle identifiable. 2.2 Header Line

type of field is not allowed. In cases where a unique field structure allows the entry of more than one piece of data and entry of either part can be mutually exclusive, special entry criteria may be required; For example the field data may be “xxx/yyy” where the entry of “aaa” will automatically be considered for the the x-part only and where an entry including a special delimiter such as “/bbb” should be required to only enter the data into the y-part of the data field.

For line pairs one through six, the header line should be located above its corresponding data line. Header text or data should be displayed using the small alpha-numeric font. The use of a small font header line in relation to the position, and size of the corresponding data line field is intended to optimize both visual and search performance.

An enter only, special procedure field, may exist when the data field has more than one function governed by specific pre-existing conditions, or as a normal alternative for the field.

Field of view aspects of the header line may be a basis for establishing that left headers be left adjusted starting in column 2. However, right headers could be right adjusted to column 24. The positioning for center fields should be on the basis of adequate identification and discrimination of the information to be displayed.

This type of data field allows for the line selection of displayed data both to and from the scratchpad. Deletion of this type of field is not allowed. The special procedure aspects, of the field are as described for the select only and enter only fields.

c.

d.

Select/Enter

Enter/Delete

2.3 Data Line The data line may have varied attributes depending upon data type and function. A data field may be characterized as display only, modifiable, or selectable. In general, large alpha-numeric font should be used for the data line. However, small font should be used for: a.

Units of measurement following a data value

b.

Computer predicted data which may or must be validated by an operator

c.

Display of a default value

d.

Data of a low priority, informational nature

This type of data field allows for the line selection of displayed data from the scratchpad and the capability to delete data entered. e.

Delete

This type of data field allows for deletion of data in the field. It may be combined with any of the above types. The special procedure capabilities for selection and entry into the field are as described for the select only and enter only fields. A special delete procedure would exist in the case where deletion of a data field resulted in the display of a selection prompt instead of the display of a blank or default value data field. 2.3.3 Prompts

2.3.1 Display Only Data Fields a. Data characterized as display only cannot be overwritten by data from the scratchpad and cannot be selected to the scratchpad. Selection of the adjacent line select key should have no effect. The key press should be ignored. 2.3.2 Variable Capability Data Fields a.

Select Only

This type of data field should only allow for the line selection of the displayed data to the scratchpad or functional selections as described in paragraph 2.3.3. Data entry to and deletion of this type of field is not allowed. A select only, special procedure field, may exist when the attributes of the field are such that it can only be selected after specific criteria have been satisfied b.

Enter Only

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

Select

A data field may be used to display a prompt which emphasizes the selectability of another mode, option, page, parameter, or menu item. Select prompts on the left side of the display should begin with a large font caret “< ” in column 1 followed by the left justified prompt starting in column 2. Select prompts on the right side of the display must be right justified to column 23 followed by a large font caret “> ” in column 24. When a line selectkey associated with a prompt is pressed, the system should execute the action required by the prompt selection. A display indication in response to this action could be in the form of a noticeable change in indicated system mode, activation/deactivation of a function, a new page display, etc. The title of a page display should include the prompt name which selected the page. The use of prompt names which reflect the page to be displayed is intended to eliminate any ambiguity regarding the consequences of selecting a prompt.

ARINC CHARACTERISTIC 739A - Page 36 ATTACHMENT 10 (cont’d) MCDU DISPLAY CONSIDERATIONS 2.3.3 Prompts (cont’d)

2.4 Scratch Pad Line

The data field font size should be as defined in paragraph 2.3. However, a small font prompt may be used in the case where the prompt must be validated or superseded by a line select entry from the scratchpad. In this case, there should be a change in character font size as a consequence of validation, the caret prompt should be removed, and the validated prompt should be left or right adjusted as appropriate. In special applications, the header field may also be used to either accentuate the prompt or reflect the condition/status of the prompt selection.

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

These type of select prompts should be located at the bottom of a page (e.g., positioned on lines 6L and/or 6R). If the number of required select prompts exceeds the capacity of a line, the menu/list of select prompts should be built from the bottom line up for any remaining prompts. The select prompts should have a distinct separation boundary from other page display data, in the form of a page width, dashed line located in the header line of the uppermost select prompt. b.

Enter only

An entry of this type may be required or optional for the display field and should be indicated by the use of dashes or box prompts to solicit the data. Typically this type of entry would be associated with and dependent on another display field or possibly function/mode. In this case, a change in the dominant field or function/mode should cause the dependent field to return to the initial prompt; Where the data entry is not essential to a function/mode, dashes to solicit an entry should be displayed. Where the data entry is required before a function can be performed or before a mode change can be completed, box prompts should be displayed to solicit data to be entered. The number of dashes or boxes used for the prompt should correspond to the maximum number of alpha-numeric characters which can be entered. c.

a.

To temporarily display data being entered via the keyboard or moved from field to field, and

b.

To display system messages to the crew.

2.4.1 Scratch Pad Data Entry via Keyboard Normally, the whole 24 character scratch pad line should be kept available for data entry. Since it may be time shared with the display of system messages, any message being displayed may require being cleared by pressing the CLR key before data entry is allowed. The subsystem must keep track of when the scratch pad contains a message and when it contains either a blank line or previously entered data. If a subsystem designer determines that the 24 character line can be subdivided to allow simultaneous data entry and message display without interference, the data entry field should be considered on the left. Its maximum size should be indicated by a full-time vertical line character, whether or not a message is being displayed on the right. This alternative design restricts the size of data entries and messages but has the advantage of avoiding the need to clear messages before data entry. Starting with a blank scratch pad, the first character entered should be displayed in column 1. Each subsequent character entered should appear to the right of the last character already be in the scratch pad. All characters should be displayed in large font. The last character on the right of the scratch pad entry should be removed when the CLR key is pressed and released. The next character on the right should be removed when the CLR key is pressed again and so on. The complete data entry should be removed when the CLR key is held down for more than one second.

Enter/Delete Only 2.4.2 Scratch Pad Data Entry via Line Select

An entry of this type may be optional and should be indicated by the use of dashes to solicit the data. This type of entry could be associated with an on/off type function or the insertion of a reference value or limit. After data has been entered, deletion of the data field should return to dash prompts or default value for the data field. The number of dashes used for the prompt should correspond to the maximum number of alphanumeric characters which can be entered.

If the scratch pad is clear, pressing the line select key adjacent to a selectable data field should cause the data in that field to be duplicated in the scratch pad, left adjusted. Once in the scratch pad, it should be treated just as though it had been entered via the keyboard. In other words, characters can be added on the right and/or cleared from the right of the entry. 2.4.3 Scratch Pad Transfer to Data Field

d.

Select/Enter/Delete -

An entry of this type should use dash prompts for the display data field. This type of entry could be required or optional. The use of this field should be oriented toward setting limits, adding a bias to a default setting, setting a reference, etc. It should be used where the systems page designs allow for the transfer of data from one field to another to facilitate data entry. The number of dashes used for the prompt should correspond to the maximum number of alpha-numeric characters which can be entered.

If the scratch pad contains data, pressing a line select key should cause the subsystem computer to: a.

Check that data entry is permissable for the adjacent data field. If not, the line select key press should be ignored.

b.

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

ARINC CHARACTERISTIC 739A - Page 37 ATTACHMENT 10 (cont’d) MCDU DISPLAY CONSIDERATIONS validity check fails, an indication of an invalid entry should be generated. c.

Transfer valid data from the scratch pad to the data field, replacing previous contents and clearing the scratch pad.

If an entry is reformatted when it is moved from the scratch pad to a data field, it must be returned to the entry format when it is moved from data field to scratch pad. For example, a latitude/longitude might be entered as N4720.3W12245.2 in the scratch pad and be reformatted as N47 20.3 W122 45.2 in a data field. It must be returned to the N4720.3W12245.2 form when moved back to the scratch pad. The requirements for the display may specify special responses/indications resulting from the data entry into a field. For example, in the case where a list is being displayed and it is desired to insert a new item in the list, the line select entry to a specific field should produce the result of inserting the entry and pushing all previous list data down one data line versus overwriting the field into which the entry is made. 2.4.4 Data Transfer From Field to Field Data can be moved from one field to another via the scratch pad. First the scratch pad should be cleared if not already clear. Next the line select key adjacent to the data to be moved should be pressed. This action duplicates the selected data in the scratch pad. Finally, the line select key adjacent to the destination field should be pressed to move the data up from the scratch pad. It should be possible to move data from page to page using the same technique unless the pages are sufficiently dissimilar that no need for this capability exists. However, data cannot be moved across subsystem boundaries using the scratch pad. 2.4.5 Scratch Pad Messages Different levels of message priority may be defined e.g., alerting and advisory. An alerting message could be used when the subsystem computer detects a condition which must be brought to the crew’s attention. It would be displayed in the scratch pad of each operating MCDU in communication with the subsystem regardless of prior contents of the scratch pad. The prior contents of the scratch pad, if any, should be saved in a message stack/buffer and redisplayed when the alerting message is cleared. An advisory message could be used to indicate data entry errors or other lower priority information. It should not displace alerting messages but should be displayed when the scratch pad is cleared. Therefore, it should be inserted in a message stack below any alerting messages in the stack. Data entry error advisory messages would take precedence over other advisory messages and scratch pad data entries. Other advisory messages should only be displayed when the scratch pad is cleared. As with alerting messages, scratch pad contents should be saved in a message stack when replaced by an advisory message.

Messages are expected to be cleared automatically from the display and message stack when the subsystem set logic is no longer satisfied. Any displayed message should be cleared and associated message set logic reset when the CLR key is pressed. The next message in the stack should then be displayed. Holding the CLR key down should not cause all messages and data to be displayed and cleared in a continuous sequence. Cleared messages must not be redisplayed until the appropriate set logic has again been satisified or some appropriate redisplay or recall logic is satisfied. In general, messages should be avoided wherever possible since they can be perceived as more of a nuisance than an aid to flight crews. When more than one MCDU is in communication with a subsystem at the same time, a scratch pad data entry should only appear on both MCDUs if they are on the same page. If they are on different pages, it should be possible to make an independent data entry on each MCDU. Data entry error advisory messages must only be displayed on the MCDU displaying the offending entry. Other advisory messages should only be displayed when a related page is displayed.

Copyright 1998 by AERONAUTICAL RADIO, INC. 2551 Riva Road Annapolis, Maryland 21401-7465 USA

SUPPLEMENT 1 TO ARINC CHARACTERISTIC 739A MULTI-PURPOSE CONTROL AND DISPLAY UNIT Published: November 3, 1998

Prepared by the Airlines Electronic Engineering Committee Adopted by the Airlines Electronic Engineering Committee: October 29, 1998

SUPPLEMENT 1 TO ARINC CHARACTERISTIC 739A - Page 2 A.

PURPOSE OF THIS DOCUMENT

This Supplement introduces changes and additions to ARINC Characteristic 739A to accommodate MCDU switching between dual subsystems, for example dual FMSs. B. ORGANIZATION OF THIS SUPPLEMENT The first part of this document, printed on goldenrodcolored paper, contains descriptions of the changes introduced in Characteristic 739A by this Supplement. The second part consists of replacement white pages for the Characteristic modified to reflect these changes. The modified and added material on each replacement page is identified by the “c-1” symbol in the margins. Existing copies of Characteristic 739A may be updated by simply inserting the replacement pages where necessary and destroying the pages they replace. The goldenrod-colored pages should be inserted inside the rear cover of the Characteristic. C. CHANGES TO ARINC CHARACTERISTIC 739A INTRODUCED BY THIS SUPPLEMENT This section presents a complete tabulation of the changes and additions to Characteristic 739A introduced by this Supplement. Each change or addition is defined by the section number and the title that will be employed when this Supplement is incorporated. In each case, a brief description of the change or addition is included. 1.6 Relationship to ARINC 739 This section was updated to include dual subsystem considerations. 2.2 Form Factor Connector part number was revised to reflect current military specifications. 3.4.3 Subsystem Specific Menu This section was modified to describe a typical first page of a subsystem menu in a dual subsystem installation. This may include the capability to select a specific unit to be primary, master, or the operational unit. 3.6 MCDU Inputs This section was reorganized and subdivided into three subordinate sections for the purpose of defining Seven Basic Input Ports (3.6.1), Additional Subsystem Input Ports (3.6.2) and MCDU Interfaces Involving Dual Subsystem Devices (3.6.3). 3.6.1 Seven Basic Input Ports This section was renumbered. The content is unchanged from the former Section 3.6. 3.6.2 Additional Subsystem Input Ports New section was added to describe five optional ARINC 429 input ports for receiving identification information and display data from either a second unit

in a dual unit subsystem installation, or from other individual subsystems. 3.6.3 MCDU Interfaces Involving Dual Subsystem Devices This section was added to describe dual subsystem installation 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) was modified to include health status reporting for port 7 (omission) and optional paired ports. ATTACHMENT CATEGORIES

5,

ENVIRONMENTAL

TEST

This attachment was update to reflect the current environmental test requirements defined in RTCA DO160D. ATTACHMENT 10, MCDU DISPLAY CONSIDERATIONS 2.1 Title Line New material was added to provide guidance on subsystem-generated menu pages and MCDUgenerated menu pages for dual subsystem configurations.