Appendix F : Display Standard

F.1 PURPOSE

The purpose of this NASA technical requirement appendix is to provide consistent and uniform technical requirements for the design, selection, and application characteristics and capabilities for the development of displays across spaceflight programs that support operator task performance. Adherence to these technical requirements will improve mission safety by enabling operators to effectively plan for, identify, and take action in response to evolving operating conditions; and maintain the situation awareness, mental resources, and adaptive capacity to make decisions and solve problems. In addition, following these requirements will promote error reduction, ease of learning, and ease of use.

Consistency refers to the level of similarity in visual style and operation within and among different crew interface designs. Systems that have been designed with consistency in mind require less training and feel familiar. The number of different codes and ways of operating are minimized, which reduces cognitive workload and operational errors. Cross-system consistency is achieved by incorporating threads of similarity in key components across designs. Higher levels of consistency across vehicles will decrease the risk of errors and result in a safer spacecraft environment.

A program established Labeling Plan and Icon Library will be a complement to this document. Individual spaceflight programs may also have more detailed design information in their corresponding As-Built Display Framework type of documents.

F.2 SCOPE

The display technical requirement applies to Contractor Furnished Equipment (CFE), Government Furnished Equipment (GFE), and items provided by International Partners for flight elements only (not ground). This technical requirement applies to displays on fixed units, as well as those on portable computers, including laptops and tablets.

Commercial-off-the-Shelf (COTS) applications that provide vehicle insight and commanding shall adhere to the requirements listed in this document. COTS applications that do not provide vehicle insight and commanding shall provide an assessment of compliance in order to perform a risk assessment of the non-compliant items as well as determine what inconsistencies need to be added to crew training.

This technical requirement does not currently apply to Augmented Reality (AR) displays.

This technical requirement is applicable to all programs, including future programs. Spaceflight programs are expected to adopt this display technical requirement instead of developing a separate lower-level document. Any deviations or waivers to the requirements of this document should be coordinated with NASA Standards OCHMO and approved by the Chief Health and Medical Officer Management Board.

This technical requirement is intended to serve two primary audiences: 1) Designers and developers who will use the technical requirements when providing software user interfaces, and 2) Verification teams who will verify delivered software interfaces against these technical requirements.

The convention used in this Display Standard are as follows:

1. “Must” — Used to indicate a requirement to be implemented and the associated implementation verified. These requirements can be tailored in additional program requirement documents and written as “shall” where needed;
2. “Should” — Used to indicate a goal that the designer is expected to follow, if possible, but that is not formally verified;
3. “Will” — Used to indicate a statement of fact and is not verified.

F.3 DOCUMENTS

F.3.1 Reference Documents

The following documents contain supplemental and background information that may be helpful in implementing these technical requirements

Government

NASA/SP-20103407	Human Integration Design Handbook (HIDH)
HF-STD-001	Human Factors Design Standard (HFDS)
NUREG-0700	Human-System Interface Design Review Guidelines
MIL-STD-1472	Department of Defense Design Criteria Standard: Human Engineering

International Electrotechnical Commission (IEC)

IEC/TC 100	Audio, video and multimedia systems and equipment
IEC/TC 100	Electronic displays

International Organization for Standardization (ISO)

ISO/IEC JTC 1/SC 29

Coding of audio, picture, multimedia and hypermedia information

F.4 GENERAL

This section covers the crew interfaces through which dynamic information is exchanged between the crew and the system (primarily through controls and displays). Well-designed crew interfaces are critical for crew safety and enabling the crew to learn, anticipate, monitor for, and respond safely and efficiently to that dynamic information. Appropriate consistency across crew interfaces can also minimize training.

Displays may be visual, audible, or haptic. Visual displays deliver information by using visible media to present text, graphics, colors, indicator lights, images, video, animations, and symbols. This information can also be provided on dynamic displays such as control panels.

F.4.1 General

1. The amount of information displayed should be limited to what is needed to perform required tasks or to provide situation awareness necessary to make decisions.
2. A display should provide the information needed to perform the task at hand without requiring the operator to navigate to additional displays.
3. Vertical scrolling should be limited to procedures or lists.
4. Horizontal scrolling should be avoided.
5. Information must be presented in a directly usable form that does not require mental transposition or computation by the operator.
6. Each display within a predefined suite (i.e., set of related GUIs) should have consistency with other formats in the suite regarding the appearance, location, and interact.
7. Modes (e.g., test mode, edit mode) in the interface should be used sparingly because they restrict operator control of the system and can cause frustration and errors.
8. Operator actions that are irreversible (e.g., could result in the loss of data) must be safeguarded via confirmation dialog boxes or the equivalent (i.e., two (2) independent operator actions).

F.4.2 Layout and Appearance

1. Layout of information on a display must support task flow (e.g., left-to-right or topto-bottom orientation aligned with procedure flow, or located according to architecture).
2. Recurring data fields should be displayed in consistent relative positions across formats.
3. Display elements to be used together should be grouped in close proximity on the screen.
4. A grouping of related characters (e.g., letters, numbers, and symbols) should be visually separated from other groupings, or from graphical or virtual borders.
5. The primary display navigation menu bar must be located at either the top or bottom of each display.
6. All displays must have a common dedicated area for the display of key information to be visible at all times (e.g., time, system messages, alerts, communication status: Loss of Signal / Acquisition Of Signal).
7. Each display must have a unique title in a consistent location that is visible at all times.
8. When more information is available for display than can be shown (e.g., multiple pages, or multiple items in a scrollable list), the system must provide an indication of the portion being viewed, and the total amount of information.
9. Elements that are selectable (e.g., buttons, menu options), elements that are static (e.g., labels), elements for embedded navigation, and elements designed for alphanumeric input (e.g., data entry fields) must be visually distinct from one another.
10. Displays for different modes of operation (e.g., test/sim mode vs. flight/mission mode) must be visually distinct.

F.4.3 Interacting with the Vehicle

F.4.3.1 Telemetry

1. If a display element has states or modes, the current state must be indicated.
2. The capability to show the violation of any operational limit or telemetry threshold of a display element must be provided.
3. There must be an indication when data are stale.
4. A yellow or red up or down arrow following a telemetry value must be used to indicate that telemetry is outside of upper or lower thresholds that trigger a Caution or Warning alarm.
5. The system must provide an indication that a telemetry value is off-scale high or low when that information is necessary to address a malfunction.
6. Telemetry fields should have sufficient fixed placeholder width to show the longest possible value, including the size of any data quality indicators.
7. When text data overflow occurs, each character of the entire field must be replaced by yellow asterisks.
8. When numeric data overflow occurs, each character of the entire field must be replaced by yellow asterisks, except for the signed field and the decimal point.

F.4.3.2 Commanding

1. Commanding should be accomplished via a “Command Popup” (popup menu) to minimize operator memory load and number of actions.
2. Command Popups must contain a unique name, options list, indication of current selection, and indication of the option to be selected.
3. Operator actions that are irreversible (i.e., could result in the loss of data) must be safeguarded via confirmation dialog boxes or the equivalent.
4. The system must require at least 2 independent commands to activate/execute mission critical and safety critical controls.
5. Commands with an arm control must be accompanied by a safe control (that removes the armed condition) located to the right or beneath the arm control.
6. Commands that change vehicle state must provide a positive indication of control activation (e.g., telemetry change, message indicating completed, running, failed, or unknown).
7. Command names for different commands must be distinguishable from one another.
8. If command operations have counterparts, congruent pairs of command names must be used in a consistent vertical order (e.g., on/off, enable/inhibit, yes/no, open/close, high/low, Max/Min, Auto/Man).
9. Commands that are irreversible or hazardous should include a black and yellow diagonally striped border (i.e., hazard tape).
10. Controls that are used to send commands to change vehicle state must be visually distinct from other controls.
11. The display must indicate that a command was accepted by the Flight Software.

F.4.3.3 Status and Error Messages

1. Status and error messages must be displayed in a consistent, designated location.
2. Status and error messages should contain the information necessary for situation awareness, to make a decision, or complete the related action.
3. Error messages should convey what is wrong, what corrective actions can be taken, and what caused the error.
4. Status data should indicate when routine maintenance activity is required.
5. Stored data should be searchable to assist in anomaly resolution.
6. Popup messages should be able to be moved/cleared by crew or cleared automatically.

F.5 DISPLAY COMPONENTS

F.5.1 Text

1. Text should use the American Standard Code for Information Interchange (ASCII) character set.
2. Sans serif font should be used.
3. The font must allow discrimination of similar characters (e.g., letter l/number 1; letter O/number 0).
4. A fixed-width font must be used on numerical and tabular data.
5. A proportional font must be used for content that is narrative, such as electronic crew procedures.
6. The system should provide an optical zoom function that allows an area within the display to be temporarily magnified.
7. Character height must be a minimum of 0.25 deg, with 0.4 deg or greater is preferred. (Note that Font height in degrees refers to the angle subtended at the eye by the height of an upper-case letter in the font. For example: 0.25 deg is 10-point type at 32 in).
8. Non-acronym text must be mixed case (e.g., uppercase and lowercase letters).
9. Acronyms and abbreviations must be as specified in the Operations Nomenclature Plan.

F.5.2 Labels

1. Labels should be shown with data fields.
2. The wording and grammatical structure of labels should be consistent throughout a display.
3. Labels should be shown in horizontal orientation.
4. Data field labels must appear to the left of data values, or above data values when data are in a columnar format.
5. When vertical orientation of the label is necessary, labels must be rotated counterclockwise, (see Figure F.5-1—Examples of Horizontal Text (Preferred) and Vertical Text).

Figure F.5-1—Examples of Horizontal Text (Preferred) and Vertical Text

F.5.3 Menus

1. Popup and drop-down menus should appear near components related to the menu selections.
2. Popup and drop-down menus should default to a location that does not obscure associated data on the referencing display.
3. Popup menus must not cover critical information or information needed to perform the task.
4. Information should be no more than 4 levels deep (i.e., no more than 4 actions to access) to acquire from a display.
5. Menu items should be listed in an order based on sequence of operations, urgency, functionality, or frequency of use. If no basis for menu item order exists, items should be listed in alphabetical order.

F.5.4 Buttons

1. Buttons must be labeled, either on the button surface or just outside the button edge.
2. Buttons must have labels that are visible in all states.
3. Buttons when actuated must change appearance.
4. A grouping of related buttons should be visually separated from other groupings or from graphical or virtual borders.

F.5.5 Alphanumeric Inputs

1. When a specific data entry format is required, format cues must be provided (e.g., mm/dd/yyyy).
2. The system must provide an indication when crew enters invalid entries.
3. Text within data entry fields must be left aligned with sufficient width to show the longest possible word.
4. Numbers within data entry fields should be right aligned with sufficient width to show the longest possible value, including the size of any data quality indicators.

F.5.6 Numbers

1. Values for the same type of parameters must be shown in the same units.
2. Units of measure must be displayed for each numeric value or for each group of numeric values where the units are the same.
3. The number of decimal places shown must be the number required by operators to perform the associated task.
4. Where numeric data is presented as a vertical group, the decimals should be vertically aligned.
5. Where numeric data is presented as a vertical group, whole numbers should be vertically aligned with the implied decimal place.
6. Numbers that have absolute values less than 1 must be displayed with a leading zero prior to the decimal point (e.g., 0.25 rather than .25).
7. Numbers that have absolute values greater than or equal to 1 must be displayed with leading zeroes suppressed (e.g., 3.14 rather than 03.14).
8. The plus “+” sign for numerical data must be suppressed, except when required for the performance of the associated task.
9. The minus “-” sign must always be displayed for negative numbers.
10. When a numeric value contains five or more digits, a comma should be displayed before every third digit, counting to the left from the decimal point. (e.g.,XX,XXX.YY).

F.5.7 Icons and Symbols

1. Standard, universally recognized iconography and symbology should be used wherever possible (e.g., trash can for “delete”, media control symbols for “play” and “pause”).
2. Icons must be visually distinct from one another.
3. Symbols must be visually distinct from one another.
4. Icons and symbols must be selected from the standard Icon and Symbol library.

F.5.8 Graphs

1. Each graph must have a unique title located above the graph.
2. Graphed data that is historical must be distinguishable from live data via labeling.
3. A label and units must be provided for each axis of a graph.
4. Each parameter must be labeled or accompanied by a legend.
5. Value labels at major tick marks on the x- and y-axis must be provided.
6. When it is important to identify out-of-range or off-nominal values, they must be highlighted (e.g., via color and a numeric/text indicator or limit line).
7. Graphs should allow for re-scaling or zooming upon user request.

F.5.9 Schematics

• Each schematic must have a unique title.
• Each object on the schematic must be labeled or have an identifier available on request.
• Lines representing flows that cross and are not physically connected must be shown as crossing lines (see Figure F.5-2—Lines Not Physically Connected).

Figure F.5-2—Lines Not Physically Connected

• Lines representing flows that cross and are physically connected must be shown as crossing lines with a dot at the conjunction (see Figure F.2-3—Lines Physically
  Connected).

Figure F.5-3—Lines Physically Connected

• When a schematic depicts a single type of line (for example, data, video, or power transmission path), the line should be solid. However, if there is more than one line type, mixed line types (e.g., dashed, dotted, colored, etc.) must be used.
• Each line type must be identified with a label or a legend.
• Line types should be consistent within a subsystem.
• Lines used to represent organization and system boundaries must be visually distinct from lines used to represent flow.
• Where flow is important and cannot be inferred by display layout, arrows must be used to indicate the direction of flow.

F.5.10 Color

• Color must be used to convey meaning, and not for decoration or aesthetic purposes.
• The meanings in Table F.5-1—Required Color Usage and Its Meaning, must be represented with the colors shown.

• The meanings in Table F.5-2—Recommended Color Usage and Its Meaning, should be represented with the colors shown.

• Colors selected outside of Table F.5-1 and Table F.5-2 must be applied in accordance
  with a provider-defined standard color table to ensure consistency.
• For critical information and critical tasks when color is used to convey meaning, the system must provide an additional cue.
• Contrast between characters and background must be 6:1 or greater (10:1 preferred). Note: contrast ratio may be calculated using an online contrast analyzer (e.g.,
  webaim.org). Verification standards can also be found in the ISO (International Organization for Standardization) documents [ISO/IEC JTC 1/SC 29] for coding of picture/multimedia information, IEC (International Electrotechnical Commission) [TC100 + TC110] for video, display quality assessment and measurement methods. Specific contrast issues related to the use of transparent displays have not been
  addressed in this revision but will be addressed in future revisions.
• Reverse video (e.g., inverted background/foreground color) must be reserved for
  events that require immediate crew attention or action.

F.5.11 Flashing

1. Flash coding must be reserved for events that require immediate crew attention or action.
2. Low flash rate must be reserved for lower priority notifications or text at a frequency of 0.8 Hz with duty cycle of 70% on.
3. High flash rate must be reserved for higher priority notifications (non-text) at a frequency of 3 Hz with duty cycle of 50% on.
4. Flashing must be synchronized across all cockpit display units.
5. The display must allow crew-controlled termination of flashing that persists more than 10 seconds.
6. If text that must be read flashes, the text must alternate intensities with a lower intensity that remains legible.

F.6 SPECIAL PURPOSE ELEMENTS

F.6.1 Time

1. Time in the standard format must always be displayed. Standard format is listed in bullet f.
2. Timers based on an absolute reference time (a Global Positioning System (GPS) time for example) must show negative time, counting to zero, before the reference time is reached, then positive time, counting up from zero, after the reference time has passed.
3. Timers with a set countdown (or count up) interval, must start immediately when the user commands it. For example, a timer can be set for a 30minute countdown and started based on the occurrence of a certain event.
4. Additional time systems, (e.g., Phased Elapsed Time (PET), Mission Elapsed Time (MET)) must be available for display.
5. All displayed times must be labeled with the time system used.
6. Time must be displayed using a 24-hour clock in the following format (Note: leading zeros are suppressed in day field): label dddd/hh:mm:ss (e.g., MET 57/14:08:33, or MET 1089/13:03:01).

F.6.2 Automation

1. The system must provide an indication of the current level of automation (e.g., full/partial/none, auto/manual, enabled/ inhibited).
2. The system should indicate whether the human operator or the system is supposed to perform a particular task at a specific time.
3. The status of an automated process must be shown (e.g., running, paused, faulted, completed, overridden, stopped).
4. Historical performance information on automated processes must be available for display.
5. Information from the automated system must avoid anthropomorphic phrasing.
6. The system must provide the human operator the ability to check information and configurations used for automated systems.
7. Automated systems that provide decisions or recommendations must provide explanation with rationale for the decision or recommendation.
8. When a human operator attempts to override or shut down an automated system, a message describing consequences (e.g., impacts to safety, hardware or software damage, timely completion of the task) must be displayed prior to executing the selected command.
9. The system must alert the human operator when a problem or situation is beyond its capability to assist with resolution or provide consequence guidance.
10. Source of control should be clearly indicated (Autonomous system vs Crew software commanding vs Crew manual commanding vs Remote operator commanding) for all systems (i.e., flight path, attitude, etc.).

F.6.3 Electronic Crew Procedures

1. The system must indicate to the crew which step in an electronic crew procedure is currently being executed.
2. The system must indicate to the crew which steps in the electronic crew procedure have been completed.
3. The system must allow the user to manually indicate the step being executed.
4. The system must allow the user to manually indicate that a step has been completed.
5. The system must notify the crew whenever crew attention is required to initiate or return to an electronic crew procedure.
6. The system must provide a method for viewing prior and future steps in the electronic crew procedure.
7. The system must provide a method for the crew to provide comments or notes about electronic crew procedures.
8. The system should provide a method for the crew to make real-time insertion, deletion, and rearrangement of electronic procedures.

F.6.4 Alerts

1. Emergency (E) and Warning (W) alerts must be associated with red symbology/text.
2. Caution (C) alerts must be associated with yellow symbology/text.
3. Advisory (A) alerts must be associated with blue symbology/text.
4. The Alerts display must display or make available on request the following parameters: Active Emergency Count, Active Warning Count, Active Caution Count, Unacknowledged/New Event Count, and a queue of unacknowledged events.
5. The Alerts display must allow crewmembers to search for events by ID or name. This search includes both active and inactive events.
6. The Alerts display must display the following for each event: Event Priority (E, W, C, A), Name, Event ID, Timestamp, System, Module/Element, Active State (active events are displayed by default), Annunciation State (Inhibit, Suppress), Acknowledge State, and event details including root cause (if available).
7. The Alerts display must allow active messages to be sortable by: Event Priority (E, W, C, A), Timestamp, System, Module/element, and root cause, if available.
8. Emergency, warning, and caution events must provide a link to access associated malfunction procedures.
9. The Alerts display must allow crewmembers to perform the following actions for each event: Acknowledge, Suppress, Inhibit, Enable.
10. The Alerts display must allow crewmembers to suppress indicators for individual events.
11. The Alerts display must allow crewmembers to silence audible annunciations for all events with a single action.