IEEE Std 1474.

2™-2003
IEEE Standards
1474.2 TM

IEEE Standard for User Interface

Requirements in Communications-
Based Train Control (CBTC) Systems

IEEE Vehicular Technology Society

Sponsored by the
Rail Transit Vehicle Interface Standards Committee

Published by
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
Print: SH95140
12 December 2003 PDF: SS95140

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE Std 1474.2™-2003 (R2008)

IEEE Standard for User Interface

Requirements in Communications-
Based Train Control (CBTC) Systems

Sponsor
Rail Transit Vehicle Interface Standards Committee
of the
IEEE Vehicular Technology Society

Reaffirmed 10 December 2008

Approved 12 June 2003

IEEE-SA Standards Board

Reaffirmed 30 April 2009

Approved 17 September 2003
American National Standards Institute

Abstract: User interface requirements for communications-based train control (CBTC) subsys-
tems are established in this standard.
Keywords: automatic train control (ATC), automatic train operation (ATO), automatic train protec-
tion (ATP), automatic train supervision (ATS), communications-based train control (CBTC), graph-
ical user interface (GUI)

The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA

Copyright © 2003 by the Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published 12 December 2003. Printed in the United States of America.
IEEE is a registered trademarks in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics
Engineers, Incorporated.

Print: ISBN 0-7381-3712-X SH95140

PDF: ISBN 0-7381-3713-8 SS95140
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the
IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus develop-
ment process, approved by the American National Standards Institute, which brings together volunteers representing varied
viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve with-
out compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus devel-
opment process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information contained
in its standards.

Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other dam-
age, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting
from the publication, use of, or reliance upon this, or any other IEEE Standard document.

The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims
any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that
the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.”

The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market,
or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the
time a standard is approved and issued is subject to change brought about through developments in the state of the art and
comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revi-
sion or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to conclude
that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check
to determine that they have the latest edition of any IEEE Standard.

In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services
for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or
entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a com-
petent professional in determining the exercise of reasonable care in any given circumstances.

Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific
applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare
appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any
interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its soci-
eties and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in
those cases where the matter has previously received formal consideration.

Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with
IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate
supporting comments. Comments on standards and requests for interpretations should be addressed to:

Secretary, IEEE-SA Standards Board

445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA

Note: Attention is called to the possibility that implementation of this standard may require use of subject mat-
ter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents
for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or
scope of those patents that are brought to its attention.

Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of
Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To
arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive,
Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational
classroom use can also be obtained through the Copyright Clearance Center.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 Introduction
[This introduction is not part of IEEE Std 1474.2-2003, IEEE Standard for User Interface Requirements in Communica-
tions-Based Train Control (CBTC) Systems.]

Communications-based train control (CBTC) systems can permit more effective utilization of rail transit
infrastructure by allowing trains to operate safely at closer headways than is possible with conventional track
circuit-based systems, and by permitting greater flexibility and greater precision in train control. To fully
exploit the capabilities and benefits of CBTC technology, however, it is important that the CBTC user inter-
faces be designed to take advantage of the characteristics of CBTC systems, such as:
— The ability to determine train location, to a high degree of precision, independent of track circuits.
— The availability of a geographically continuous train-to-wayside and wayside-to-train data communi-
cations network to permit the transfer of significantly more control and status information than is
possible with conventional systems.
— Wayside and trainborne vital processors to process the train status and control data and provide con-
tinuous automatic train protection (ATP). Automatic train operation (ATO) and automatic train
supervision (ATS) functions are optional and may also be provided, as specified by the authority hav-
ing jurisdiction.

This standard has therefore been developed to establish both mandatory and optional CBTC user interface
information requirements, as well as provide guidance in how this information should be presented to the
user.

Participants

At the time this standard was completed, the Communications-Based Train Control Working Group had the
following membership:
Alan F. Rumsey, Chair
G. Achakji V. Grappone R. Pascoe
C. Braban J. Hoelscher W. Petit
F. Childs S. Hosseini V. Pindiprolu
M. Crispo G. Hubbs G. Pruitt
J. Cullen K. Karg W. Rooney
R. Dhingra J. LaForce C. Schwellnus
J. Eilenberg M. Lukes E. Taylor
N. Estivals R. MacDonald J. Vogler
N. Ghaly D. Male K. Vought
H. Gillen T. McGean N. Wallach
H. Glickenstein R. Miller R. Walsh
E. Mortlock

The following members of the balloting committee voted on this standard. Balloters may have voted for
approval, disapproval, or abstention.
C. Braban K. Karg V. Pindiprolu
F. Childs J. LaForce G. Pruitt
J. Cullen M. Lukes A. Rumsey
R. Dhingra R. MacDonald L. Sanders
N. Estivals D. Male J. Smith
H. Gillen T. McGean E. Taylor
H. Glickenstein R. Miller J. Vogler
J. Hoelscher R. Pascoe K. Vought
G. Hubbs W. Petit N. Wallach
A. Kanner R. Walsh

Copyright © 2003 IEEE. All rights reserved. iii

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 When the IEEE-SA Standards Board approved this standard on 12 June 2003, it had the following
membership:
Don Wright, Chair
Howard M. Frazier, Vice Chair
Judith Gorman, Secretary

H. Stephen Berger Donald M. Heirman Daleep C. Mohla

Joe Bruder Laura Hitchcock William J. Moylan
Bob Davis Richard H. Hulett Paul Nikolich
Richard DeBlasio Anant Jain Gary Robinson
Julian Forster* Lowell G. Johnson Malcolm V. Thaden
Toshio Fukuda Joseph L. Koepfinger* Geoffrey O. Thompson
Arnold M. Greenspan Tom McGean Doug Topping
Raymond Hapeman Steve Mills Howard L. Wolfman

*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons:

Alan Cookson, NIST Representative

Satish K. Aggarwal, NRC Representative

Andrew Ickowicz
IEEE Standards Project Editor

iv Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 Contents

1. Overview.............................................................................................................................................. 1

1.1 Scope............................................................................................................................................ 1
1.2 Purpose......................................................................................................................................... 1
1.3 Range of applications................................................................................................................... 1
1.4 Existing applications.................................................................................................................... 2

2. References............................................................................................................................................ 2

3. Definitions, abbreviations, and acronyms............................................................................................ 3

3.1 Definitions.................................................................................................................................... 3
3.2 Abbreviations and acronyms........................................................................................................ 4

4. General user interface requirements .................................................................................................... 4

4.1 Categorization of CBTC systems................................................................................................. 4

4.2 CBTC user profiles ...................................................................................................................... 4
4.3 Ergonomic requirements.............................................................................................................. 5
4.4 System safety considerations ....................................................................................................... 5
4.5 Display requirements ................................................................................................................... 6
4.6 Audible device requirements ....................................................................................................... 6
4.7 User input feedback requirements ............................................................................................... 7
4.8 Alarm and advisory message requirements ................................................................................. 7

5. Operations-related user interface requirements—trainborne subsystems............................................ 7

5.1 General......................................................................................................................................... 7
5.2 User interface information requirements ..................................................................................... 8
5.3 User interface presentation requirements..................................................................................... 9

6. Operations-related user interface requirements—non-trainborne subsystems .................................. 11

6.1 General....................................................................................................................................... 11
6.2 User interface information requirements ................................................................................... 11
6.3 User interface presentation requirements................................................................................... 12

7. Maintenance-related user interface requirements .............................................................................. 17

7.1 General....................................................................................................................................... 17
7.2 User interface information requirements ................................................................................... 17
7.3 User interface presentation requirements................................................................................... 18

Annex A (informative) Bibliography ......................................................................................................... 19

Copyright © 2003 IEEE. All rights reserved. v

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE Standard for User Interface
Requirements in Communications-
Based Train Control (CBTC) Systems

1. Overview

This standard establishes user interface requirements for communications-based train control (CBTC) sub-
systems. This standard is divided into 7 clauses. Clause 1 provides the scope and purpose of this standard.
Clause 2 lists references to other standards that are useful in applying this standard. Clause 3 provides defini-
tions that are either not found in other standards, or have been modified for use with this standard. Clause 4
defines general user interface requirements applicable to both CBTC trainborne and non-trainborne user
interfaces, including both operational and maintenance functions. Clause 5 defines specific user interface
requirements for CBTC trainborne subsystems, including what information should be displayed, and guide-
lines as to how this information should be displayed, with specific emphasis on operational functions. Clause
6 defines similar user interface requirements for CBTC non-trainborne subsystems. Clause 7 defines user
interface requirements applicable to maintenance diagnostics for CBTC subsystems.

This standard should be read in conjunction with IEEE Std 1474.1™-1999.1

1.1 Scope

This standard establishes user interface requirements in CBTC systems.

1.2 Purpose

This standard will provide for consistent user interfaces that take advantage of the characteristics of CBTC
systems to enhance service effectiveness of a rail transit system.

1.3 Range of applications

The CBTC user interface requirements defined in this standard are intended to be applicable to the full range
of transit applications, including light rail, heavy rail, and commuter rail transit systems.

1Information on references may be found in Clause 2.

Copyright © 2003 IEEE. All rights reserved. 1

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

1.4 Existing applications

Existing CBTC installations and projects in progress prior to the effective date of this standard need not
comply with the new or revised requirements of this edition, except where specifically required by the
authority having jurisdiction.

2. References

This standard shall be used in conjunction with the following publications. In case of a conflict between this
standard and the referenced document, this standard shall take precedence. Those provisions of the refer-
enced documents, which are not in conflict with this standard, shall apply as referenced.

IEEE Std 1474.1-1999, IEEE Standard for Communications Based Train Control (CBTC) Performance and
Functional Requirements.2,3

IEEE Std 1483™-2000, IEEE Standard for Verification of Vital Functions in Processor-Based Systems Used
in Rail Transit Control.

MIL-STD 1472, Revision F, Human Engineering Design Criteria for Military Systems, Equipment, and
Facilities4, the following sections::

— Control/Display Integration: Section 5.1 and all its subsections

— Visual Displays: Section 5.2 and all its subsections except 5.2.1.3.12 and 5.2.1.6.6 (NBC compatibil-
ity); 5.2.2.1.12.1 (incandescent lamp redundancy); and 5.2.6.13 (helmet mounted displays)
— Audio Displays: Section 5.3 to subsection 5.3.8.5 inclusive and subsection 5.3.14
— Controls: Subsections 5.4.3.1.3 (Keyboards), 5.4.3.2.6 (Mouse), 5.4.3.2.7 (Light Pens), 5.4.6 (Touch
Screens) and 5.4.7 (Speech Recognition)
— Labeling: Section 5.5 and all its subsections
— Anthropometry: Section 5.6 excluding subsection 5.6.2
— User-Computer Interface: Section 5.14 and all its subsections except 5.14.3.4.3 (freezing of dynamic
displays)
— Visual-Display Terminal (VDT): Section 5.15

2The IEEE standards or products referred to in Clause 2 are trademarks owned by the Institute of Electrical and Electronics Engineers,
Incorporated.
3IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway,
NJ 08855-1331, USA (http://standards.ieee.org/).
4MIL publications are available from Customer Service, Defense Printing Service, 700 Robbins Ave., Bldg. 4D, Philadelphia, PA
19111-5094.

2 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

3. Definitions, abbreviations, and acronyms

3.1 Definitions

For the purposes of this standard, the following terms and definitions apply. IEEE 100™, The Authoritative
Dictionary of IEEE Standards Terms [B2], should be referenced for terms not defined in this clause.

3.1.1 authority having jurisdiction: The entity that defines the contractual (including specification)
requirements for the procurement.

3.1.2 automatic train control (ATC): The system for automatically controlling train movement, enforcing
train safety, and directing train operations. ATC must include automatic train protection, and may include
automatic train operation and/or automatic train supervision.

3.1.3 automatic train operation (ATO): The subsystem within the automatic train control system that per-
forms any or all of the functions of speed regulation, programmed stopping, door control, performance level
regulation, or other functions otherwise assigned to the train operator.

3.1.4 automatic train protection (ATP): The subsystem within the automatic train control system that
maintains fail-safe protection against collisions, excessive speed, and other hazardous conditions through a
combination of train detection, train separation, and interlocking.

3.1.5 automatic train supervision (ATS): The subsystem within the automatic train control system that
monitors trains, adjusts the performance of individual trains to maintain schedules, and provides data to
adjust service to minimize inconveniences otherwise caused by irregularities.

NOTE—The ATS subsystem also typically includes manual and automatic routing functions.

3.1.6 auxiliary wayside system: A backup or secondary train control system, capable of providing full or
partial automatic train protection for trains not equipped with trainborne communications-based train control
(CBTC) equipment, and/or trains with partially or totally inoperative trainborne CBTC equipment. The aux-
iliary wayside system may include trainborne equipment and may also provide broken rail detection.

3.1.7 communications-based train control (CBTC): A continuous automatic train control system utilizing
high-resolution train location determination, independent of track circuits; continuous, high capacity, bidi-
rectional train-to-wayside data communications; and trainborne and wayside processors capable of imple-
menting vital functions.

3.1.8 communications-based train control (CBTC) user: Any authority-authorized personnel who receive
information from, provide information to, or perform repairs or maintenance on, a CBTC system.

3.1.9 communications-based train control (CBTC) user interface: That portion of the human computer
interface in which the CBTC user interacts with the CBTC system to observe and/or perform functions
implemented by the CBTC system. Includes, but is not limited to, displays, audible indicators, tactile entries,
cursor positioning device implementations, and voice input devices.

3.1.10 communications-based train control (CBTC) user profiles: A definition of the vision, hearing,
language and physical characteristics of the CBTC user.

3.1.11 control action: A request by a communications-based train control (CBTC) user for the CBTC sys-
tem to perform an operation. A control action may require a single user input, or a sequence of user inputs,
and a user requested control action may be subject to verification checks prior to the CBTC system perform-
ing the requested operation.

Copyright © 2003 IEEE. All rights reserved. 3

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

3.1.12 display: A visual representation of data, graphics or text, that is presented on a display screen.

3.1.13 display screen: The surface of a display device on which the visual representation of data is
presented.

3.1.14 function key: Assignable special purpose keys on a computer keyboard or keypad, which the com-
munications-based train control (CBTC) user employs to interact with the CBTC system.

3.1.15 human computer interface: The set of stimuli that a user experiences when in and around a com-
puter terminal including but not limited to the user interface, the work area furnishings and environmental
elements consisting of biomechanical stresses, light, sound, temperature, and air quality.

3.1.16 penalty overspeed condition: A condition requiring the application of the penalty brakes by the
automatic train protection subsystem in order to assure safe train operation.

3.1.17 window: In graphical user interfaces, a defined portion of the display screen that is separated by a
frame from the rest of the screen and which may be opened, closed, resized and moved by the user.

3.2 Abbreviations and acronyms

ATC automatic train control

ATO automatic train operation
ATP automatic train protection
ATS automatic train supervision
CBTC communications-based train control
GUI graphical user interface

4. General user interface requirements

4.1 Categorization of CBTC systems

This standard recognizes that different configurations of CBTC systems are possible, depending on the par-
ticular application, and that the specific CBTC configuration will impact the details of the user interface. A
CBTC system may:

a) Provide ATP functions only, with no ATO or ATS functions.

b) Provide ATP functions, as well as certain optional ATO and/or ATS functions, as required to satisfy
the operational needs of the specific application.

A CBTC system may be the only train control system in a given application, or may be integrated with other
train control systems.

4.2 CBTC user profiles

The authority having jurisdiction shall define user profiles for all CBTC users. Separate user profiles may be
defined for operations and maintenance personnel. Separate user profiles may also be defined for CBTC
trainborne equipment users and CBTC non-trainborne equipment users. Each user profile shall include:

a) Vision: the distribution among the CBTC user population of near sightedness, far sightedness and
color deficiencies.
b) Hearing: the distribution among the CBTC user population of hearing levels.

4 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

c) Language: required reading qualifications in the native language(s) of the installation location of the
CBTC system.
d) Physical: the distribution among the CBTC user population of physical capabilities.
e) Computer-literacy: the degree of familiarity with computer applications.

All CBTC users shall have received applicable rail transit operational and/or maintenance training from the
authority having jurisdiction.

4.3 Ergonomic requirements

The CBTC user interfaces shall be designed with an emphasis on proper and accepted ergonomic principles
and practices, and in accordance with the referenced ergonomic guidelines and standards (see Clause 2).

a) Male 95 percentile dimensions shall be used to set clearances and the female 50 percentile dimen-
sions shall be used to set reach envelopes.
b) Displays and controls shall be placed so that the user may view them without changing head position
from the normal line of sight; eye movements may be necessary.
c) Non-critical displays and controls may be located outside the normal line of sight.

The CBTC user interfaces are intended to:

1) Optimize, assist, and enhance the user’s performance in normal and abnormal operating
conditions.
2) Provide for simplicity of design and consistency in the presentation of information and human-
computer interaction.
3) Be intuitive, such that minimal training is required to use the system as intended.
4) Support the user in a manner consistent with the user’s skill level.

The CBTC user interfaces shall provide feedback to a user regarding the CBTC system’s automated actions,
the reasons for such actions, and the effects of the user’s manual actions on the CBTC system.

The CBTC user interfaces shall provide notification when user action is required.

The CBTC user interface designs shall accommodate a user’s expectation of logical and consistent relation-
ships between actions and results. Information shall be integrated and presented in a format or representation
that minimizes the time required to understand and act on the information, and in a form that directly sup-
ports the variety and types of decisions that the user makes.

User interface designs shall include capabilities to validate user inputs and detect user errors before they
propagate through the CBTC system, and shall allow for easy recovery from error.

4.4 System safety considerations

CBTC user interfaces can potentially introduce system hazards and the design of CBTC user interfaces shall
be considered in the hazard analyses required by IEEE Std 1483-2000. CBTC user interfaces are not
required to be implemented in a failsafe manner, however the hazard analyses shall take into account the fol-
lowing, as a minimum:

a) Probability of safety-related commands not being executed when initiated by a CBTC user.
b) Probability of the CBTC system prematurely removing safety-related commands initiated by a
CBTC user.
c) Probability of the CBTC system executing safety-related commands that were not initiated by a
CBTC user.

Copyright © 2003 IEEE. All rights reserved. 5

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

d) Probability of incorrect information being displayed by the CBTC system to the CBTC user.

4.5 Display requirements

The CBTC system shall display information to users in accordance with the prescribed color and display
symbol conventions in this standard, and the referenced sections of MIL-STD 1472. In addition, the author-
ity having jurisdiction may define the colors and display symbol conventions for compatibility with other
non-CBTC systems.

Where not in conflict with color codes specified herein, colors shall accommodate users with color deficient
vision.

General guidelines for the application of colors on CBTC displays are as follows:

a) RED—generally utilized for restrictive conditions, critical alarms and other conditions requiring
immediate attention, and for conditions well out of tolerance, as prescribed by the authority having
jurisdiction.
b) GREEN—generally utilized for normal or active states, and for conditions that are within tolerance.
c) YELLOW—generally utilized for minor alarms and conditions that are out of tolerance to a minor
extent, as prescribed by the authority having jurisdiction.
d) BLUE—generally utilized for control inhibit. Pure blue shall not be utilized on dark backgrounds or
adjacent to red without an intervening border/separator.
e) WHITE—generally including various shades of gray for background information, static informa-
tion, text, and conditions that are out of tolerance (positive), to an extent prescribed by the authority
having jurisdiction. No more than two shades of gray, in addition to white, should be utilized.
f) BLACK—may be utilized for backgrounds and for text where a contrasting background is provided.
g) MAGENTA—generally available for advisories, control-action request indication, and for non-criti-
cal functions as prescribed by the authority having jurisdiction.

Highlighting techniques shall direct the user to critical data. The display attributes of color, color intensity,
blinking/flashing, character inversion, line texture, and appended symbols shall be provided to highlight
device status, alarms, data quality, data entry locations, and error conditions

Flashing shall be utilized for control action request indication, unacknowledged alarms, and for other condi-
tions requiring immediate attention. No more than two flash rates or patterns should be utilized.

A continuous flashing icon may be used to indicate a display is operational without requiring
acknowledgement.

4.6 Audible device requirements

Non-speech signals shall be in the 200 to 5,000 Hz range and ideally in the 500 to 3,000 Hz range. Loudness
of sounds used shall be consistent with the ambient sound level, but not so loud that they startle or disrupt
the proper response. Loudness should also be consistent with the urgency of the message.

Loudness shall be no more than 30 dBA above ambient noise with a maximum overall level of 100 dBA.

A maximum of four distinct audible annunciations including variations in tone, duration and/or repetitive
on/off states (as defined by the authority having jurisdiction) shall be provided.

The use of sounds that could be confused with operational or malfunction noises (e.g., trainborne air brake
releases or inverter operations, or audible alarms from other systems in a control center environment, etc.)
shall be avoided.

6 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

4.7 User input feedback requirements

The CBTC system shall respond to all user control actions indicating whether the action was accepted, was
not accepted, or is pending. For multistep procedures, the CBTC system shall provide feedback at each step.
Indications such as text messages, color changes, and blinking may be used to provide this feedback. When
an action is not accepted the reason for the rejection shall be readily determinable by the user.

A convenient, consistent means shall be provided for displaying user guidance messages. User guidance
messages shall not require the use of a reference document for interpretation.

4.8 Alarm and advisory message requirements

Alarms and advisory messages indicate conditions that require user notification when detected. All alarms
and advisory messages shall be presented to the users in a consistent manner.

Alarm presentation shall be designed to match the level of risk or danger with the alerting nature of the
alarm.

Attributes such as color, intensity, inverse video, flashing or audible annunciation, either singly or in combi-
nation, shall be used to indicate alarm status. The alarm display/audible attributes shall indicate whether the
alarm has been acknowledged or not.

Any alarm or advisory message shall not require use of a reference document for interpretation (with the
exception of advisory messages provided solely for maintenance diagnostic purposes, when the display
device places physical limits on the amount of information that can be displayed).

Alarm and advisory message text and message attributes shall be modifiable by authority-authorized person-
nel, to the extent specified by the authority having jurisdiction.

Except where specified by the authority having jurisdiction, all alarms shall require an appropriate user
acknowledgement, either singly or in groups. When an alarm is acknowledged, distinctive attributes of the
alarm shall be eliminated. Advisory messages shall not require acknowledgement.

5. Operations-related user interface requirements—trainborne subsystems

5.1 General

The requirements of this clause are specifically applicable to CBTC-equipped trains operated by either a sin-
gle person or multiperson crews. The train operator will typically be stationed in the lead car of the train and
will be responsible for moving the train from station to station. With a multiperson crew, the conductor(s)
will normally operate from conductor position(s) within the train to operate the train’s doors. A CBTC sys-
tem shall support single person train operation by combining the conductor and train operator display infor-
mation on the train operator’s display screens. For multiperson crews, conductor display information shall
also be provided on separate conductor display screens. Conductor display information shall be a subset of
train operator display information, as defined by the authority having jurisdiction.

The extent to which this clause is applicable to support operation of trains without crews shall be established
by the authority having jurisdiction.

The trainborne operations-related user interfaces shall be capable of displaying all information as defined in
this clause, within acceptable latencies, as defined by the authority having jurisdiction.

Copyright © 2003 IEEE. All rights reserved. 7

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

5.2 User interface information requirements

The CBTC trainborne displays shall include both fixed and dynamic information. Information to be
presented shall include certain mandatory data associated with safe train movement. Optional operations-
related data may also be displayed to the extent specified by the authority having jurisdiction. The informa-
tion to be displayed, the user information inputs, and the available audible alarms shall also be dependent on
the operating mode of the train (e.g., manual or automatic train operations).

5.2.1 Mandatory display data

Mandatory data to be displayed on the CBTC trainborne display screen(s) shall include:

a) Train operating mode.

b) CBTC operational status (for example, as a result of verification checks of the trainborne CBTC
equipment performed prior to entering CBTC territory).
c) Current CBTC-determined train speed.
d) Current maximum authorized CBTC speed (i.e., ATP profile speed at the CBTC-determined train
location).
e) Overspeed condition alarm (when the current CBTC-determined train speed is within a predefined
tolerance of the current maximum authorized CBTC speed).

5.2.2 Optional display data

Optional data to be displayed on the CBTC trainborne display screen(s) may include:

a) Fixed territory related information (such as location of stations, interlockings, any highway grade
crossings, CBTC territory limits, and other fixed alignment related information, such as curves and
grade, as specified by the authority having jurisdiction).
b) Train type.
c) Train run identity/train destination.
d) Train location and/or track designation.
e) Train length.
f) Reason for movement authority limit (e.g., train ahead).
g) Target speed, i.e., value of an upcoming speed reduction (permanent or temporary) or zero speed tar-
get for upcoming movement authority limit.
h) Speed profile to an approaching movement authority limit, speed reduction or work zone.
i) Distance to an approaching movement authority limit, speed reduction or work zone.
j) Required brake rate to an approaching movement authority limit, speed reduction or work zone.
k) Time to a penalty brake application if the train operator fails to respond to an upcoming speed
reduction.
l) Penalty overspeed condition alarm (when the current CBTC-determined train speed exceeds the cur-
rent maximum authorized CBTC speed, resulting in an immediate automatic brake application).
m) Train route through interlocking(s).
n) Train regulation information such as the remaining dwell time for a train at a station platform, train
performance level and/or optimum train speed profile may also be displayed for trains traveling
between stations, to facilitate adherence to train run-time schedules.
o) Information related to unscheduled train stops between stations.
p) Train properly aligned at a designated station stopping point.
q) Station management related information such as train to stop at next station, train to skip next sta-
tion, train to hold at station, train door status (open/closed) and indication of on which side of the
train door opening is authorized.
r) Highway grade crossing warning related information to support the functional requirements of
6.1.15 of IEEE Std 1474.1-1999.
s) Detected parted consist condition.

8 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

t) Fault report-related information.

u) Text messages from a CBTC non-trainborne subsystem communicated over the CBTC wayside-to-
train datalink.
v) Time and date.

5.2.3 Mandatory user information inputs

Mandatory user information inputs shall include:

a) Operating mode selection.

b) Overspeed alarm condition acknowledgement.

5.2.4 Optional user information inputs

Optional user information inputs may include:

a) CBTC user login parameters.

b) Train type.
c) Train length.
d) Train run identification/train destination.
e) Crew identification.
f) ATO start.
g) Performance level modifications.
h) Highway grade crossing warning related inputs to support the functional requirements of 6.1.15 of
IEEE Std 1474.1-1999.

5.2.5 Mandatory audible alarms

Mandatory audible alarms shall include:

a) Overspeed condition.

5.2.6 Optional audible alarms

Optional audible alarms may include:

a) Penalty overspeed condition.

b) Transitions into and out of CBTC territory.
c) Detected parted consist condition.
d) Approaching work zone.
e) Any train length entered by the train operator, as per item c) of 5.2.4, is in conflict with train length
detected by the CBTC system.

5.3 User interface presentation requirements

For the trainborne CBTC subsystem, the user interface shall typically include a graphical display device
(and associated display screen), an audio output device, and associated switches/buttons for user input.
Optionally, as specified by the authority having jurisdiction, user interface devices may include “heads-up”
displays, touch sensitive screens and/or voice-sensitive input devices.

Copyright © 2003 IEEE. All rights reserved. 9

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

5.3.1 Display layout

Trainborne CBTC display screens shall be located based on the train operator’s position and installed as
close as possible to the operator controls that affect them. The CBTC trainborne display screens shall:

a) Display information in a consistent format for all display screens by placing each design element in
a consistent and specified location.
b) Display information in a manner that emphasizes its relative importance with critical information
displayed in the center of the operator’s field of view. Information that needs to be found quickly
shall be placed in the upper left hand corner of the field of view and items which are not time critical
shall be placed in the lower right hand corner of the field of view.
c) Display information with a minimum resolution consistent with the distance of the display from the
train operator’s position.
d) Be designed for display luminance of the foreground or background of at least 35 cd/m2 (the
displays should be capable of a minimum contrast 3:1 with 7:1 preferred, and controls should be
provided to adjust the brightness level and contrast level).
e) Where text is needed, short and simple sentences or phrases shall be used with wording that an
operator will understand. Complete words shall be used where possible. Where abbreviations are
necessary, only abbreviations acceptable to the authority having jurisdiction shall be used.

The design of the CBTC trainborne user interface shall support single or multiple display screens and shall
also support single or multiple displays on any given display screen.

The primary display on any given display screen shall present operation-critical information. The secondary
display(s), if provided, shall present non-critical information. The navigation between primary and second-
ary display(s) shall be smooth and seamless. All displays shall include the mandatory display data (per
5.2.1).

If optional time and date information is provided, it shall also be visible on all displays. Date field shall be
presented in a format as specified by the authority having jurisdiction.

The display shall employ contrasting color schemes to highlight information as per 4.5 of this standard.

5.3.2 User inputs

User input facilities shall be located to minimize the need for the train operator to change position, and
arranged according to their expected order and frequency of use.

Full QWERTY keyboards shall be avoided for data entry.

5.3.3 Access control

To prevent unauthorized personnel from gaining access to the CBTC trainborne functions, a means of pro-
viding access control based on user classification may be implemented, as specified by the authority having
jurisdiction.

10 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

6. Operations-related user interface requirements—non-trainborne sub-

systems

6.1 General

A CBTC system may optionally include, and/or interface to, operations-related user interface facilities at a
central location and/or distributed at various locations along the wayside. Certain non-trainborne, opera-
tions-related user interface facilities are considered mandatory. Whether these functions are implemented by
a CBTC subsystem, or by other non-CBTC equipment, is optional.

The authority having jurisdiction shall identify the specific display layout and user input features to be
implemented, and shall also identify those user interface characteristics which are to be modifiable by
authority authorized personnel.

Automated functions shall be predictable, offer the user an appropriate range of options, monitor user
actions to minimize, resist and tolerate errors, and be capable of being overridden by the user.

The non-trainborne operations-related user interfaces shall be capable of displaying all information as
defined in this clause, within acceptable latencies, as defined by the authority having jurisdiction.

6.2 User interface information requirements

The non-trainborne operations-related display(s) shall include both fixed and dynamic information and shall
be fully integrated with other conventional ATS and non-ATS user interface facilities, as may be specified by
the authority having jurisdiction, to support overall service management for the transit system, and provide
for a single consistent user interface.

6.2.1 Mandatory display data

Mandatory data to be displayed on the non-trainborne display screen(s) shall include:

a) Fixed territory related information such as the track plan, including interlocking configurations,
location of stations, location of any highway grade crossings, and location of CBTC territory limits.
b) Train status related information such as train attributes, train operating mode and train location
(including sequence of trains on the track relative to other trains), for all CBTC-equipped train oper-
ating in the CBTC territory.
c) Train movement authority/routing information such as CBTC movement authority information for
each CBTC-equipped train, to include authority limit, route established through interlocking(s) and
currently authorized travel direction.
d) Information related to restricted train operations such as work zone information, blocked tracks/
switches and temporary speed restriction limits and values

6.2.2 Optional display data

Optional data to be displayed on the non-trainborne display screen(s) may include:

a) Fixed alignment related information, such as permanent operating speed limits and location of emer-
gency access points.
b) Current train speeds.
c) Train crew information.

Copyright © 2003 IEEE. All rights reserved. 11

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

d) Location of trains not equipped with trainborne CBTC equipment and/or trains with inoperative
trainborne CBTC equipment may be displayed if this data is available from a secondary train loca-
tion determination system capable of establishing if a section of track is occupied by one or more
trains.
e) CBTC maximum authorized speed.
f) Service performance related information necessary to monitor and regulate the performance of
CBTC-equipped train operating in CBTC territory, in relation to schedule and/or headway adher-
ence. This may include train destinations/trip plan, train line-ups entering/leaving service, schedule
status for each train (early/late), headway status, and remaining dwell times for trains at stations, as
well as station management related information such as: train to stop at next station; train to skip
next station; train to hold at station and train door status (open/closed).
g) ATP profile violations, and any other events that result in a penalty brake application on a train.
h) Failures and out-of-tolerance conditions detected by, or input to, a CBTC system that can impact the
on-time performance of the transit system or result in some other loss of specified CBTC
functionality.
i) Status of elements of any auxiliary wayside system.

6.2.3 Mandatory user information inputs

Mandatory user information inputs shall include:

a) Inputs to request and cancel routes, including ability to control and limit movement authorities of
CBTC-equipped trains.
b) Inputs to establish and remove work zones, block track sections/switches and establish temporary
speed restrictions.

6.2.4 Optional user information inputs

Optional user information inputs may include:

a) Inputs to modify schedules/trips of one train, a group of trains and all trains including facilities to
hold and release trains at stations, as well as at other locations between stations, and facilities to
direct a train, or group of trains, to skip a station stop.
b) Inputs to adjust the train service braking profiles for CBTC-equipped trains (e.g., in response to wet
rail conditions).

6.3 User interface presentation requirements

For CBTC non-trainborne subsystems, the user interface may include one or more graphical display devices
(and associated display screens), a multi-tone audio output device, printers, and keyboards, pointing devices,
switches/buttons for user input. Optionally, as specified by the authority having jurisdiction, user interface
devices may include large-scale mimic displays, touch sensitive screens and/or other tactile or voice-sensi-
tive input devices.

6.3.1 Display layouts

An industry standard graphical user interface (GUI) design, as specified by the authority having jurisdiction,
shall be utilized for visual user interface elements (examples of GUI designs include CDE 2.1/Motif2.1 [B1]
or the Microsoft® Windows®5 User Interface [B3]).

5Microsoft® and Microsoft Windows® are registered trademarks of the Microsoft Corporation.

12 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

6.3.1.1 Display features

The user shall be able to scale display data to prescribed magnification or scale factors. For example, the
scale factors shall allow the presentation of the complete territory on one display screen (or within one win-
dow), as well as the presentation of a user-selected portion of the territory.

Using scrolling, users shall be able to view adjacent areas of the display data, in any direction, at the same
magnification or scale factor. Static and dynamic data shall be displayed and updated during scrolling
operations.

Displays shall include multiple declutter/clutter levels, which subtract/add detail to be displayed. Default
display detail, for each magnification or scale factor, shall be defined by the authority having jurisdiction.
Displays shall automatically declutter/clutter in accordance with the magnification or scale factor of a dis-
play. In addition, convenient means (such as keyboard function keys, for example) may be provided for users
to manually select which declutter/clutter levels are visible regardless of the magnification or scale factor.

Each display shall include a heading at the top of the display consisting of a title showing the unabbreviated
name of the display, and, on multi-page displays, a page number in the form PAGE N OF M.

Time and date information shall be visible at a fixed position on at least one display screen at each user loca-
tion. Date fields shall be presented in the format specified by the authority having jurisdiction.

A means for presenting CBTC system-generated user guidance messages on a display shall be provided.

Messages of the same priority level shall be in a consistent location on all displays.

6.3.1.2 Windows

All displays shall be presented on display screens in windows. Windows shall, at a minimum, consist of: a
frame, a heading area for the display title, an active/inactive status indication, and associated controls (such
as minimize, maximize, and close) where applicable. The capability for simultaneous display of multiple
windows on each display screen shall be provided, and windows shall be capable of being displayed in either
overlapping/cascade or tiled fashion depending on the window definition.

The attributes of each window for open location and size on a display screen or screens, and user capability
to size, move, and close windows shall be able to be defined by the authority having jurisdiction.

The open location and priority of visibility of windows that are defined by the authority having jurisdiction
as sizeable, moveable, and/or able to be closed on a display screen or set of display screens of a user posi-
tion, shall be definable by general criteria selected by the authority having jurisdiction.

NOTE—examples of general criteria include:

a) Dialogs, popups, and pull-down menu windows shall be visible wholly within the display screen in which it
opens. Other windows shall be sizeable across more than one display screen.
b) Once opened, a popup or pull-down menu window shall not be required to move with the window where its
associated display object is visible. A pull-down menu window shall close if a user selects another window
including the window of the associated display object.
c) Windows that are associated with display objects and that are presented to the user to initiate controls, such as
pop-up/pull-down menus, or display information such as non-critical alarms and messages:
1) shall appear on the same display screen as where the object appears,
2) shall be located on the display screen in close proximity to the display object,
3) shall not obscure the device(s) being controlled and/or device control target areas,
4) shall be sized such that all display information is visible in a window of minimum size (subject to ergo-
nomic criteria determined by the authority having jurisdiction).

Copyright © 2003 IEEE. All rights reserved. 13

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

d) Dialogs, popups, and other windows that are sizeable and/or moveable shall not open when invoked such that
they obscure areas of displays with pending or in-progress control actions. An advisory message to the user
shall be provided under such circumstances
e) Overlapping windows shall be visible (i.e., the window and its display shall not be completely obscured by
another window) according to the following priority order of visibility:
1) Windows presenting critical alarm displays shall “always be on top” whether or not the window is active,
2) Windows presenting menus, dialogs, popups, and other windows used to initiate controls,
3) Windows presenting windows displaying track displays,
4) Windows containing other displays such as reports, system status displays, non-critical alarms, etc.
5) For windows of the same visibility priority, a window selected by the user shall be “on top.” When not
selected, the last window selected by the user shall remain “on top.”
f) In multi-display screen user positions, windows may be defined to appear on just one display screen or repeat
on all screens.

Tabular and graphical displays that are larger than the window shall include up/down and/or left/right scroll
bars, as necessary, for viewing the entire display. Capability shall be provided to scroll a full screen at a time,
as well as a single step. Single step scroll increments shall be no greater than the dimension of a single line
of text. Tabular displays shall single step a row or column per step. Direction arrows in the scroll bars shall
indicate that additional information can be viewed by scrolling in the direction the arrows point.

When scrolling tabular displays horizontally or vertically, only the body of the display shall scroll. The row
and column headings of the table shall always be displayed so the user can identify the information dis-
played. Facilities shall be provided to query, filter, and sort tabular information as specified by the authority
having jurisdiction.

6.3.1.3 Display selection

Selection of CBTC non-trainborne subsystem displays shall be provided using any or all of the following
methods:

a) Selection of a display from a menu display.

b) Cursor target selection on any menu, graphic object, or tabular display.
c) Selection of an alarm or event message on a summary display or the alarm field followed by selec-
tion of a display request command.
d) Entry of a display name or page number on a display select field.
e) Forward and reverse paging and scrolling through a series of displays.
f) Selecting a display recall command. This action shall cause the display that was on view immedi-
ately prior to the current display to be recalled.
g) Scaling from an overview display to an area of interest within the display and vice versa.
h) Panning and scrolling a display to an area of interest.
i) Selecting function keys dedicated to frequently used displays.
j) Selecting a single step command that reconfigures all of the inactive windows and displays of a user
position to a default configuration defined by the authority having jurisdiction.

Menu items, tabular lists, and graphic representations that are not available for selection at that time shall be
“grayed out” on the display.

6.3.2 User inputs

6.3.2.1 Cursor position selection

Multiple methods of cursor positioning shall be provided, including a cursor positioning device, cursor
control keys and forward and backward tab keys. Cursor positioning techniques shall be consistent for all
displays. Undisplayed tab stops shall be placed at the first character of enterable data fields, at controllable
devices, and at all other cursor targets. Cursor targets on displays shall be sufficiently large to permit rapid

14 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

selection of the target without excessive movement of the cursor-positioning device. The size of each target
shall be changeable by authority-authorized personnel.

6.3.2.2 Data entry

The CBTC non-trainborne user interfaces shall include facilities that enable users to enter data into the
CBTC system as necessary. Enterable data fields shall be defined when a display is generated. All enterable
data fields shall be highlighted. The user shall be able to enter the desired value anywhere within the data
entry field. If only a portion of a data value needs to be changed, only that portion of the value shall need to
be entered.

Data entry capability shall be provided for the user to make multiple data entries before requesting that the
data be entered into the database. The CBTC system shall check all data entries on a display for validity and
consistency. If one or more data entries on a display are invalid or inconsistent, user guidance messages shall
be provided, and none of the values shall be written to the database until the errors are corrected. The form
and extent of the user guidance messages shall be agreed with the authority having jurisdiction. The user
shall not be required to re-enter valid entries. When the user successfully completes a data entry, the previ-
ous and new values shall be reported to the user in an event message.

If a display is in the data entry mode in one window, then an attempt to initiate the data entry function for
that display in another window shall be rejected and result in a user guidance message. All data entry that
could lock out another user shall be subject to a time limit. If data entry is not completed within the specified
time, the CBTC system shall revert to the previous database value, generate an event message, and display a
user guidance message. The timer shall be adjustable by authority-authorized personnel for each user action.

Ending data entry shall occur at any time if executed or if a cancel command is selected. A cancel command
shall cause the process to be terminated and the data value shall remain unchanged.

6.3.2.3 Interaction with a CBTC control device

The first step in the interaction with a control device shall be selection of the device (or devices) to be oper-
ated upon (for example: a specific switch, or a specific train or group of trains).

If control capabilities are available for the selected device, the device shall be highlighted and the device’s
identification shall be displayed. If no control capability is currently available for the selected device an
appropriate user advisory message shall be provided to the user.

For a frequently used control action (for example: “move switch”) means shall be provided to initiate the
control action with the minimum number of user inputs. In addition, the user shall also be provided a menu
of all of the control capabilities applicable and available for the selected device and the device’s current
operational state.

For each step in the sequence of user inputs required for a given control action, a set of parameters shall be
presented to the user, appropriate to the device type and to the operation to be performed.

Each step in the sequence of user inputs may be verified by the CBTC system such that if the user provides
an input other than one allowed or expected, or that will cause the sequence to be canceled, the user input
display shall return to the last successful step and a user guidance message shall appear directing the user to
request a different action. The form and extent of the user guidance messages shall be agreed with the
authority having jurisdiction.

The sequence of user input required for a given control action shall be subject to a time limit. If the user fails
to complete any step of a sequence within the required time, the CBTC system shall cancel the control action

Copyright © 2003 IEEE. All rights reserved. 15

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

being requested, generate an event message, and display a cancellation message. The timer shall be adjust-
able by authority-authorized personnel for each type of control action.

The user shall be able to cancel any control action at any time prior to completing the required sequence of
user inputs, and prior to the above referenced time limit, by entering a cancel command.

When the user has completed the sequence of user inputs, the requested control action may either begin
immediately, or may begin only after the user has selected a separate control action confirmation or “exe-
cute” command, as identified by the authority having jurisdiction. Where required, control action confirma-
tion shall automatically present a confirming notice to the user prior to initiation of control actions, and
require the user to assert an acknowledgement, for example by clicking an “OK button.”

After the CBTC system has executed the user requested control action, appropriate feedback shall be pro-
vided to the user to indicate the success or failure of the control action.

Interlocks shall be provided to prevent multiple users simultaneously entering conflicting or contradictory
inputs that could result in an operationally undesirable outcome or unintended action. Interlocks shall allow
the control actions of one user to be completed or cancelled before another control action of the same type
can be initiated by a second user. A user advisory shall be provided to an authorized CBTC ATS user
attempting control actions that are temporarily locked out.

Interactions with a control device by an authorized CBTC ATS user shall supercede and lock out control
operations (control action completion and/or conflicting controls) on the same device or function by CBTC
system automatic functions until the control operations on the device have been completed or released.

Prorities between non-trainborne and trainborne control actions shall be defined with the authority having
jurisdiction. Safety-related control actions shall have the highest priority.

6.3.3 Access control

Typically, all of the CBTC ATS functions shall be available from all non-trainborne subsystem display
screens. However, access to the CBTC ATS functions may be controlled based on user classification and
function/territory assignments, as specified by the authority having jurisdiction. Users that do not have
access to a function may view displays associated with the functions unless they are denied access to the dis-
play for other reasons, such as confidentiality of the data. Users with access to the displays but not control
actions associated with a function may not interact with the displays to change data or initiate actions.

A mechanism for defining, controlling and assigning user access to the CBTC non-trainborne subsystems
shall be provided. The CBTC system shall include a function to enable an individual(s) with sufficiently high
authorization to define and assign access capabilities for each user classification. A default set of functional
access for each user shall be able to be established and maintained as an attribute of the user. The default
functional access setting shall be the access each user shall be granted upon log-on. Users shall be able to be
granted additional access that shall be available to the user until the user logs-off, or prior to log-off, the
access is removed by an authorized individual with function assignment capability.

6.3.4 User help facilities

A convenient, consistent means shall be provided for accessing user help facilities and other authority-
defined reference documents.

16 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

7. Maintenance-related user interface requirements

7.1 General

A CBTC system is required to include local and remote maintenance and diagnostic capabilities to detect
and react to various CBTC equipment failure types, as identified in 5.4 of IEEE Std 1474.1-1999.

NOTE—These failure types may include:

a) Those failures, or combination of failures, that impact the on-time performance of the transit system.
b) Those failures, or combination of failures, that do not impact on-time performance of the transit system, but do
result in some other loss of specified CBTC functionality.
c) Those failures that do not impact on-time performance of the transit system or result in a loss of any specified
CBTC functionality (e.g. because of equipment redundancy).

The primary objective of these maintenance and diagnostic provisions is to minimize CBTC system down-
time, or unavailability of an operationally critical function, by minimizing the mean time to repair in-service
CBTC equipment (i.e., first-level repair).

The remote diagnostic capabilities of a CBTC system may take advantage of the continuous train-to-way-
side datalink to permit authority-authorized personnel to interrogate the status of trainborne equipment, and
provide active fault diagnosis and isolation. The CBTC train-to-wayside datalink may also be used for the
transfer of maintenance and diagnostic-related information for other trainborne subsystems to the wayside
for presentation, processing and/or logging. Maintenance and diagnostic-related data may be automatically
downloaded at selected locations (such as terminal stations), or on demand by authority-authorized
personnel.

To the extent specified by the authority having jurisdiction, the CBTC maintenance-related graphical user
interface provisions shall be capable of displaying all information as defined in Clause 7.

7.2 User interface information requirements

7.2.1 Display data

The CBTC maintenance-related user interfaces shall be capable of displaying:

a) A graphical representation of the current CBTC system configuration (both hardware and software).
b) A comprehensive listing of current CBTC subsystem and/or component status (to a level appropriate
for first-level repair).
c) A date/time stamped failure log (with failures listed in the sequence of occurrence).
d) Physical location of failed CBTC subsystem and/or component (to a level appropriate for first-level
repair).
e) Information that can provide an early warning of pending failures including, for example, out-of-tol-
erance conditions and any degradation in CBTC message delivery reliability.
f) Any other information essential to optimally troubleshoot failures (at first-level repair).

7.2.2 User information inputs

The CBTC maintenance-related user interfaces shall provide a means of:

a) Interrogating the status of CBTC subsystems and/or components, and

Copyright © 2003 IEEE. All rights reserved. 17

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
Std 1474.2-2003 IEEE STANDARD FOR USER INTERFACE REQUIREMENTS IN

b) Entering information on maintenance performed on the CBTC system. The format of data entry for
this purpose shall be open enough to allow for descriptive notes on maintenance performed as well
as automated entry functions (such as time of data entry) to enhance the ease and reliability of log-
ging key information.

7.3 User interface presentation requirements

The maintenance user interface shall typically include both local displays and interfaces to external equip-
ment such as a laptop PC. The user interface shall typically include a graphical display device and associated
keyboard, touch sensitive screens, switches and/or buttons for user input.

7.3.1 Display layout

Maintenance and diagnostic displays shall present maintenance-related information in an organized and log-
ical fashion.

Logged maintenance-related data shall be available to users in printed format (for off-line printing) as well
as electronic formats, with the ability to display all data fields for a record simultaneously.

7.3.2 User input

Maintenance-related user input facilities shall allow for navigation of maintenance and diagnostic displays
by trained maintenance personnel without the use of an external reference manual and with minimal memo-
rization of special keyboard sequences to execute commands. Wherever possible, descriptive, “plain
English” command options shall be presented for the user’s use in navigating and accessing information.

The maintenance log shall be sortable and searchable to allow for easy research on trends for specific loca-
tions, types of equipment, and other information of interest.

7.3.3 Access control

A means of providing several levels of authorization for maintenance functions shall be provided. Through a
secure means, the CBTC system shall prevent unauthorized personnel from performing maintenance diag-
nostic functions.

7.3.4 Modifications to CBTC displays and system databases

A convenient, consistent means shall be provided to allow authority-authorized personnel to modify CBTC
user interface characteristics and system databases, to the extent specified by the authority having
jurisdiction.

18 Copyright © 2003 IEEE. All rights reserved.

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.
 IEEE
COMMUNICATIONS-BASED TRAIN CONTROL (CBTC) SYSTEMS Std 1474.2-2003

Annex A
(informative)

Bibliography
[B1] CDE 2.1/Motif 2.1—Style Guide and Glossary, The Open Group, 1997.

This guide provides developers who design and implement new products with a framework of behavior spec-
ifications that is consistent with the Motif and Common Desktop Environment (CDE) user interface. This
behavior is established by drawing out the common elements from a variety of current behavioral models.
The document also includes a comprehensive glossary of terms used in the Desktop Documentation set.

[B2] IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition.

[B3] Microsoft® Windows® User Interface (Official Guidelines for User Interface Developers and Design-
ers), Microsoft Corporation, 1999.

This document provides the official Microsoft® guidelines for creating visually and functionally consistent
user interfaces for applications run on the Microsoft Windows® family of operating systems.

Copyright © 2003 IEEE. All rights reserved. 19

Authorized licensed use limited to: SOUTHWEST JIAOTONG UNIVERSITY. Downloaded on December 29,2011 at 12:57:10 UTC from IEEE Xplore. Restrictions apply.