Skip to contentUnited States Department of Transportation - Federal Highway Administration FHWA Home
Research Home
Public Roads
Featuring developments in Federal highway policies, programs, and research and technology.
This magazine is an archived publication and may contain dated technical, contact, and link information.
Federal Highway Administration > Publications > Public Roads > Vol. 62· No. 6 > Human Factors Recommendations for TMC Design

May/June 1999
Vol. 62· No. 6

Human Factors Recommendations for TMC Design

by Nazemeh Sobhi and Michael Kelly

Traffic incidents may have a detrimental effect on traffic congestion from the time they occur until long after the actual incident is cleared. Prompt identification and clearance of incidents can minimize this damage.

Traffic management center in Seattle, Washington.
The traffic management center in Seattle, Wash., is equipment with an array of monitors and computers to enable the operator to collect and communicate traffic data and to respond quickly to any incident.

Traditional incident detection methods, typically relying on phone notification by citizens or a fortuitous discovery by a law enforcement officer, may require relatively long periods of time to detect and begin clearing accidents. Intelligent transportation systems (ITS) technology, including closed-circuit television, traffic-flow sensors, and computer-based incident detection systems, can identify roadway incidents much more quickly. In addition, traveler information systems can alert drivers approaching an incident to the need to drive cautiously to avoid a secondary accident.

An ITS-class traffic management center (TMC) incorporates a large number of sensors to collect and communicate traffic-flow data. They may employ data fusion and automated information processing to combine and translate the information into a form that can enhance operators' knowledge of the status of the roadway environment. A TMC can automate some routine decisions and actions to help manage the operators' workload. Finally, a TMC provides new channels to communicate information to drivers and vehicles, including presentation of brief messages on variable message signs (VMS) and presentation of more complex information on short-range highway advisory radio (HAR) transmitters.

The success of advanced traffic management systems (ATMS) operations ultimately depends on how the human operator interacts with the systems' computers and devices. The human operator is a critical component whose capabilities and limitations must be integrated into the design and operation of a TMC. The need to integrate human operators into the traffic management system dictates that the principles of user-centered design and human factors engineering must be incorporated into the overall system design and system engineering process.

A series of experiments were conducted in a high-fidelity TMC human factors research simulator to address some of the important questions that were being asked about how best to integrate the human operator into the high-technology TMC. Some of the questions concerning systems for data collection and information promulgation are discussed in this article.

Methods of Controlling Remote CCTV Cameras
TMCs in many urban areas rely heavily on remote, closed-circuit television (CCTV) cameras for maintaining surveillance of the roadway system. A TMC operator in such a system may have access to dozens, or even hundreds, of remote cameras. These cameras are used to detect incidents, such as traffic accidents or debris on the roadway; to verify incident reports received by other means; to monitor incident clearance; and to maintain surveillance of the general traffic flow.

With such a large number of remote cameras in use, a TMC operator may spend considerable time selecting remote cameras for viewing on available monitors and manipulating (panning, tilting, and zooming) the camera view. If the design of the cameras affects the cameras' effectiveness and ease of use, the design will consequently affect the effectiveness of the entire traffic management system.

The human factors design issues associated with these cameras include:

  • What type of interface is best for selecting a remote camera for viewing? Some implementations require the operator to type in an identifier string on a keyboard or keypad while others allow selection of a camera icon off a map using a finger touch, mouse, or other pointing device.
  • What type of operator interface is best for manipulating the camera? Many implementations use a dedicated joystick or button-box. Although these devices are used only for camera controls, designers wonder whether keyboard or mouse controls (devices that are present anyway) could be used effectively to control the remote cameras without adding further clutter to the console.
  • Are camera presets (i.e., predefined pan, tilt, and zoom coordinates arranged in a set sequence) preferable to unrestricted manual control of cameras? These presets, usually mediated by an add-on system that increases cost, allow the user to specify the views that are of interest and preclude views of off-the-road scenery. Presets are arranged in a sequence and the operator's control actions cause the camera to progress through the sequence of preset views.

Four different manual interfaces were tested for selecting and controlling remote cameras: the joystick interface, the keyboard interface, the touch-screen interface and the mouse interface.

In the joystick interface, left and right movements of the joystick result in left or right pans of the camera view. Backward and forward movements of the joystick result in downward and upward tilts of the camera. Zooming is accomplished by simultaneously pressing a button on top of the joystick and moving the stick forward or backward. Cameras are selected for viewing by typing an identifier string using the numerical keypad of the computer keyboard. This configuration matches a common arrangement, currently in use in TMCs, that features a joystick and associated keypad to select and control cameras.

The keyboard interface is very similar to the joystick. Rather than left, right, forward, and backward movement, subjects use the left, right, up, and down arrow keys beside the keypad. Zooming is accomplished by simultaneously pressing the rightmost control key (relabeled ZOOM) and the up or down arrows.

Computer mouse interface.
The computer mouse interface is one of four manual interfaces that can be used to "call up" specific displays and maps, select and control remote cameras, and record and transmit information.

The touch-screen interface uses a set of icons on the map display for selecting cameras. The map is shown on the upper-right corner of the computer workstation beside the video window where the camera video is displayed. The subject first touches an upper-level icon that designates the desired roadway. The map then switches to a zoomed-in view of a map of the chosen roadway, and a separate icon is displayed for each camera along that roadway. The operator then touches the icon associated with the desired camera, and that camera view is displayed in the video window. A control pad at the bottom of the screen controls camera movement.

The mouse interface is similar to the touch-screen. Mouse users view a map on the workstation map display. They open a box containing a region of the overall map by clicking and dragging the cursor. Cameras are then selected by clicking on a specific camera icon. The control pad near the bottom of the screen manipulates the camera just as with the touch-screen except that users "click" with the left mouse button to press a control button rather than pressing it with their fingertips.

A relatively large number of selection errors made by the touch-screen group indicated that a touch-screen interface should not be used to select cameras. Touch-screen interfaces have inherent limitations due to the required sizes of touch zones and the possibility of errors due to visual angle. As the number of touch icons increases and their size and the distance between them decreases, the occurrence of errors increases.

The higher percentage of transition (camera movement) time for joystick users operating manual cameras is related to the tendency of joystick users to make relatively few short panning movements accompanied by fewer tilt and zoom movements. Mouse and keyboard users tend to make more tilt, zoom, and short panning movements. These findings suggest that mouse and keyboard users were likely to conduct a more thorough inspection of camera sites. It is partly on this basis that we recommend that mouse and keyboard interfaces be selected for manually controlling remote cameras.

Interfaces using preset cameras appear to be superior to pure manual controllers. The preset functions allow for a quick look at a location and prevent the operator from spending time on manually panning the camera around to view the roadway from opposite directions. The manual functions, on the other hand, allow the operator to examine a particular location in great detail when necessary. Our recommendation, therefore, is that a camera-control design should incorporate preset capabilities for approximate camera aiming along with manual control capabilities for fine aiming.

Incident Detection Algorithms
Incident detection, verification, and management are central to effective TMC operations. While remote cameras and alternative, non-camera displays of traffic-flow data will allow operators to maintain manual surveillance of a roadway network, automated incident detection support systems are likely to acquire increased importance as TMCs move toward higher levels of automation. Incident detection systems typically collect and analyze traffic-flow data and report a possible incident when the traffic-flow characteristics, such as low speed and high density in a limited area of the roadway, resemble those associated with past incidents.

TMC operators are concerned with several performance parameters of incident detection algorithms - hits, misses, false alarms, and detection latencies. A hit occurs when the system correctly detects and reports the presence of an incident. A miss occurs when the system fails to detect and report an existing incident. A false alarm occurs when the system reports that an incident has occurred when there is none. Detection latency refers to the amount of time required by the system to detect and report an existing incident. An automated incident detection system should provide a high percentage of hits, a low percentage of misses and false alarms, and a short detection latency.

In reality, these parameters interact with each other. For example, the detection algorithm can be tuned to reduce the false-alarm rate by also reducing the hit rate. The detection latency can be reduced by accepting a higher false-alarm rate or a lower hit rate. A crucial question for an automated support system designer is the effect of various approaches to this tradeoff on operator and TMC performance. One existing philosophy, for example, is that the system should be designed to eliminate the "cry wolf" problem by minimizing false alarms.

Our operator performance data suggest that automated incident detection systems enhance the operators' performance by reducing misses and decreasing the detection latency. The data further suggest that the incident detection system should be implemented with the highest hit rate and lowest detection latency that are practical to achieve.

While this will ultimately translate into a higher false-alarm rate, operators are able to compensate for this if the system provides a means to easily identify and dispose of false-alarm reports. The means might include automated identification of recommended camera sites and other sensors appropriate to evaluate the data as well as color-coded map displays and CCTV monitors to supplement the incident detection system.

In addition, the operator needs a means of easily rejecting incident reports or delaying their management. During our experiments, operators were given a menu of four choices that appeared with each incident detection system report, allowing the operator to report the incident, reject the incident as a false alarm, declare the report a duplicate of a previously reported incident, or place the report in a background log for later handling.

Management of VMS and HAR Messages
Variable message signs, also called changeable message signs, are the primary way to disseminate information from a traffic management center to the traveling public. A strength of VMS as an information dissemination channel is that it does not require special equipment in vehicles to receive the traffic information. VMS can be used to provide information about traffic conditions ahead, including incidents, construction, special events, and congestion, and about road/weather conditions.

Variable message sign.
When a TMC operator is alerted to an incident, he can provide the appropriate warning to motorists via variable message signs.

VMS systems are being increasingly used as a means of transmitting such traffic information. In areas with a large number of VMS, the TMC operators may be challenged by the task of deciding which messages to post on particular signs, when to change the messages, and when to clear the signs. Computer-based support systems may be used to assist the operator.

One major issue in controlling a combined VMS/HAR information system was a conflict between the interface for selecting VMS messages versus the interface for controlling highway advisory radio broadcasts.

An interface for controlling VMS was used as a starting point. This interface allowed the operator to see the current message posted on the VMS and provided mechanisms for clearing the message and for posting a new message.

The method for posting a new message was to select from a menu of messages. Each possible message was prepared ahead of time. An abridged form of the message appeared in the menu listing, and upon selection, the full text of the message appeared. For example, the full message might be "ACCIDENT ON I-20. THREE LANES BLOCKED. USE MLK AS ALTERNATE." The associated menu item might be "Accident, 3 lanes, alternate MLK." This approach for selecting a message for VMS was preferred by the evaluators.

When this approach was applied to the HAR broadcasts, however, it led to too many menu options. The preferred approach for the HAR broadcasts was a composition method. Composing a message began by selecting the condition to report - for example, accident or congestion. The operator continued by selecting the roadway, the direction of travel, the nearest one or two exits, the number of lanes blocked, and finally the alternate (if any) to suggest. Upon composing the message, the operator selected the HAR transmitter(s) from which the message should be broadcast.

Although the evaluators agreed in preferring the menu approach for VMS and the composition approach for HAR, they also agreed that they did not like using a separate method for managing the two information outlets. For the combined system, they recommended using the composition approach for both HAR and VMS.

A second issue was the difficulty that operators had in reviewing and understanding the response to an incident in terms of VMS and HAR messages. In one study, we simulated a support system that automatically selected and posted messages on VMS when the operator placed an incident report. Operators were informed of each action taken by the support system. We found that operators had difficulty detecting an over-response or an under-response to an incident when the individual messages were presented separately. The previous study was limited to the use of VMS and specifically did not include HAR.

Our evaluators strongly preferred that the same level of automation used for VMS should also be used for HAR broadcasts. That is, the automatic posting of VMS messages should be accompanied by automatic broadcast of comparable messages on HAR. We further found that the presence of the HAR messages exacerbated the problem of detecting support system errors. The evaluators recommended that the total response (VMS and HAR) to an incident be summarized in a single dialog on the workstation monitor.

Another issue was the complexity of clearing multiple VMS and HAR messages after an incident was cleared. We found that operators needed a streamlined way of clearing a VMS and an indication on the asset map of whether a given VMS was cleared. Additional streamlining is needed for clearing a message from HAR because, in contrast to a VMS response, a HAR broadcast can be a group of messages about multiple incidents. The clearance of a given incident means that the message associated with that incident should be cleared from HAR, but other incidents may remain. Thus, to check a HAR broadcast to see that a given message has been removed, the operator needs more information than simply the cleared versus uncleared state of HAR.

These studies highlighted the importance of providing the operator with an integrated traffic management system rather than a suite of separate support systems. The operator interface should feature a consistent "look and feel" for all of the incorporated elements.

Conclusions
The following are specific lessons learned concerning the design of user interfaces related to the selection and control of closed-circuit television cameras for monitoring roadway traffic:

  • Use of the computer mouse to click on appropriate camera icons on a map display provides an effective method of selecting cameras.
  • The cursor keys on the standard computer keyboard provide an effective method of controlling camera pan, tilt, and zoom.
  • Avoid using a touch-screen interface for selecting or controlling cameras.
  • Camera controls allow the operator to step between preselected viewing angles.

The following are lessons learned about the algorithms used for automated incident detection systems:

  • An automated incident detection support system should be designed to operate at the highest hit rate and lowest detection latency that are possible, even at the expense of a higher false-alarm rate.
  • The operator should have an easy means of rejecting any report that he/she deems to be a false alarm.
  • The viewing of one report by the operator should not be interrupted by a subsequent report.

The following are specific lessons learned concerning design of support systems related to the dissemination of information to drivers and other users of real-time traffic data:

  • The TMC operator should have the same type of interface to control VMS and HAR.
  • The level of automation of VMS and HAR management should be identical.
  • The entire response to an incident should be indicated in a single dialog between the support system and the TMC operator.
  • The TMC operator's asset map should indicate the status (cleared or not cleared) of VMS and HAR transmitters. HAR status should further reflect which incidents are associated with a broadcast message.
  • The dissemination of information to in-vehicle systems must be integrated with the incident reporting system.

Nazemeh Sobhi is a highway engineer in the Office of Safety Research and Development, Federal Highway Administration. Her expertise is in the human factors aspects of intelligent transportation systems. She received a bachelor's degree in computer science from Radford University in 1987 and a master's degree in transportation engineering from the Virginia Polytechnic Institute and State University in 1989. Currently, she is a doctoral candidate in civil engineering at the University of Maryland.

Michael Kelly is a principal research scientist and head of the Human Factors Branch at the Georgia Tech Research Institute. He is the principal investigator on the study to develop a handbook of human factors design guidelines for advanced transportation management centers based on simulator research and on lessons learned by existing centers. He received his doctorate in engineering psychology from The Johns Hopkins University in 1975.

ResearchFHWA
FHWA
United States Department of Transportation - Federal Highway Administration