|This report is an archived publication and may contain dated technical, contact, and link information|
Publication Number: FHWA-RD-95-197
Date: December 1996
Development of Human Factors Guidelines for Advanced Traveler Information Systems and Commercial Vehicle Operations: Comparable Systems Analysis
CHAPTER 7. THE TravelPilot SYSTEM
The in–vehicle component of the TravelPilot system evolved from an earlier ETAK product called Navigator. The Navigator was intended to provide information regarding the current position of a vehicle and a destination referenced to the road system. The TravelPilot then evolved as a product for commercial applications that featured route selection and two–way communications to a dispatch centerðCfunctions that were not available in the consumer–targeted Navigator system.
The Navigator relied solely on dead reckoning to determine the location of the vehicle. Inputs to the dead–reckoning algorithms include heading from a non–gimballed, solid–state (fluxgate) compass and two wheel rotation sensors, one on each non–driven wheel. Systems currently in the prototype stage also rely on dead reckoning, but can be augmented with GPS. In addition, the Navigator, like other ETAK positioning systems (including the TravelPilot) use proprietary map–matching techniques to compute the position of the vehicle.
In the case of TravelPilot, ETAK and Blaupunkt (a subsidiary of Bosch) provided the in–vehicle positioning and mapping system and the in–vehicle display to a system Integrator company (i.e., PRC). TravelPilot was a second–generation product for the after–market. It is primarily a Bosch product. Blaupunkt was primarily responsible for display design, including modifications between the Navigator system and the TravelPilot system. ETAK performed the initial design of the hardware and pilot production. Since then, many of the hardware details have been changed by Bosch. Currently, the device is produced entirely in Germany. The TravelPilot is currently in its fourth version.
TravelPilot by ETAK is currently installed and used in trucks of the Seattle Fire Department. This on–board display system provides a communications link between emergency response vehicles (e.g., fire engines) and the Seattle Fire Department Dispatch Center. Because of the similarities between the Navigator and the TravelPilot systems, the lessons learned developing the Navigator also apply to the TravelPilot system and are included here.
GENERAL SYSTEM DESCRIPTION AND OBJECTIVES
The primary objective of this application of TravelPilot is to enhance the effectiveness of the Seattle Fire Department's emergency response capability. Specifically, many calls require immediate emergency response where every minute can make the difference between life and death. In the case of cardiac arrest, the goal is for emergency response to arrive 4 to 6 minutes after the call was placed. This requirement stresses the need to quickly dispatch the closest available vehicle to the scene of the accident. The dispatchers also have the responsibility of managing the vehicles so that they may respond to emergencies around the city. This becomes difficult when severe emergencies (large fires) demand resources from across the city. In this situation, dispatchers must balance the immediate needs associated with the emergency with the need to accommodate other calls throughout the city.
A secondary objective of this system is to support record keeping that spans many functions of the fire department. The record–keeping system automates report filing, tracks response time of emergency crews, and tracks hazardous waste. The hazardous waste tracking includes identifying permits and fees required, and maintaining a record of the type, amount, and location of the material so that dispatchers and drivers are warned of dangerous materials before they arrive at the scene.
The TravelPilot system links emergency dispatchers with emergency response vehicles. Thus, the system includes units located in each vehicle and units with which dispatchers control several response vehicles/crews. The in–vehicle system provides drivers with location information regarding the emergency site and enables them to send and receive messages from the emergency dispatchers. For example, when the computer–aided dispatch sends a vehicle to an emergency, the TravelPilot in–vehicle system automatically receives a message from the dispatch center specifying the address and location. This is displayed in the vehicle on a simple map display. When the driver leaves the station, the TravelPilot automatically notifies the dispatch center that the driver has left. Thus, the TravelPilot system provides drivers with location information and it enables them to communicate their location and status to dispatchers more easily than is possible with standard radio communication. In addition, the system aids dispatchers in monitoring the status of vehicles and in dispatching the appropriate type and quantity of emergency vehicles. Furthermore, the system helps identify specific vehicles based on their location and operational status. The ATIS functional characteristics that apply to TravelPilot are listed in table 6.
Table 6. Comparison of TravelPilot functions with those from ATIS/CVO systems.
There is no auditory component to this system. A monochrome CRT located on the vehicle's dash is used to display the text–based menus and messages, and the maps showing the current position of the vehicle and the destination. The CRT is approximately 11.4 cm measured diagonally. The CRT is covered with a sheet of treated lexan. This sheet protects the occupant in the event the CRT is broken. It also is used to mitigate the effects of glare and reflection off the screen. The screen displays information in green characters and symbols on a black background.
The graphic display consists of a simplified road map of Seattle, centered on the driverð=s location and oriented in the direction of travel (i.e., heading up). The driver can select from a variety of map scales, including low–resolution views that display a large portion of the city and high–resolution views that display only a small part of the city. At the bottom of the map graphic is a text message sent by the dispatcher; generally, this message contains the address of the destination. At the top of the map display is a status line that provides information regarding map scale, straight–line direction to destination, distance to destination, direction of north, and unit status.
Buttons along each side of the CRT control the display and allow the driver to enter a menu system that guides the driver through a variety of screen configurations and message choices. Thus, the screen can contain text and graphics (a heading–up map with icons representing the current vehicle position and the destination). The functions of the buttons along the two sides of the display depend on the system state and change with menu selections. For instance, if the map is shown and the "MEN" button at the top of the left row of buttons is pressed, the display changes to show a text description of the standard system menu functions. Pressing this button again engages the "Select Destination" function. Other buttons also change function in a similar way as the driver engages different functions of the system.
Dispatchers interact with a different part of the system and their interface is substantially more complicated. The room that houses the dispatchers consists of five self–contained workstations that have identical capabilities. From each of these five workstations, dispatchers can receive telephone calls, enter information into the computer system, communicate with drivers, and monitor driver and vehicle status and position. The controls and displays that face the dispatcher include banks of buttons for manually alerting fire stations, multiple radio control channels for communicating directly with drivers, and a keyboard and two 33–cm displays for interacting with the computer–aided dispatch and automatic vehicle location functions. The dispatchersð= room also includes two large–screen monitors (approximately 122 cm diagonally) that display position information of emergency vehicles on a simplified map of Seattle.
Visual Information Display
The primary driver information display is the in–vehicle map. Their own vehicle position is fixed at a point in the middle of the screen laterally and approximately two–thirds of the way down the screen from the top edge (figure 54). Text, when displayed on the map, appears on the bottom of the screen.
The distance between the "own vehicle" symbol and the top edge of the screen defines the scale of the map display. For example, if the user selected an 8–km scale, then the distance between the vehicle symbol and the top edge of the screen would correspond to 8.0 km. If a 1.6–km scale were selected, then this distance would reflect 1.6 km. More detail is shown on the larger map scales (e.g., 0.8–km scale) than on the smaller scales (e.g., 16.1–km scale). When a destination is entered, the largest map scale (i.e., the scale showing the smallest geographic area) that allows both the destination and the own vehicle position to be displayed is automatically selected. There are some situations in which the destination may be farther away from the own vehicle than the scale would suggest. For example, the destination could be more than 8–km away when the 8–km scale is selected. This occurs when the destination is outside a circle centered on the own vehicle, but within the rectangular limits of the screen. The destination will normally be in the upper–left or upper–right corner of the screen in these situations.
As the scale of the map is changed, the level of detail also changes. At the largest scales, a small geographic area is displayed and all of the roads are depicted. As the scale is reduced, the amount of area depicted increases and the level of detail is reduced. At small scales, the road that the own vehicle is on may be removed from the map, particularly if the road is a "minor" one. The map is always displayed in a "heading–up" mode. There is no provision for presenting the map in a "north–up" orientation.
Not all of the roads are labeled. There is a provision for cycling through the streets, putting names on a different subset of the streets displayed on each cycle. (The "STR" button on the left side of the map display performs this function.) ETAK has developed a patented technique of dynamic labeling. This technique does not clip the labels at the screen edge, and does not allow labels to overwrite one another. In addition, the letters in the labels are always parallel to the street that they name, regardless of the orientation of the street. In addition the labels are always read left to right. This last constraint results in some labels being read from bottom to top, while others are read from top to bottom, depending on the orientation of the road on the screen.
To the left and right of the map display are short labels for the function buttons that are used to control the display. As mentioned earlier, these labels, and consequently the functions of the buttons, change as the operator selects different functions. The labels to the right of the map control the map scale and those to the left provide access to text screens containing menus of system functions. The buttons on the left also control the level of detail in the map display; street names can be removed to reduce display clutter. The status screen (figure 55), selected from one of the left buttons when the map is displayed, re–labels the function buttons with a short abbreviation of the text messages that the unit sends when the buttons are depressed in the "status" mode. For example, pressing a button on the left side marked "STA" sends a message to the dispatchers that the unit is available at the station. When activated, the "RSP" button on the right notifies the dispatchers that the unit is responding to the incident.
Destinations are typically received by dispatch and subsequently issued to one or more specific emergency vehicles, yet the system does allow the driver to select a destination when necessary. This procedure is based on text–based menu screens from which a driver chooses various categories of destinations. The driver may choose among the following options:
The information display for the dispatchers consists of two standard CRT's located at each workstation and two large monitors mounted at either end of the room. One CRT in each workstation displays the history of the incident and provides the dispatcher with a command line that can be used to enter information into the system (Data Entry CRT). The other CRT in each workstation displays the status of incidents and vehicles, and of the resources available to the dispatcher (Status CRT). The information on the Status CRT includes incidents that have been entered into the computer but are waiting to have emergency crews dispatched. The information also includes active incidents, which includes any incident for which crews have been dispatched. The display also shows the available vehicles and those that are classified as being on special status (in the shop for repair, out of service to conduct inspections or ceremonies and other special events).
When the dispatcher receives an emergency call, information concerning the incident is entered into the computer and simultaneously displayed on the Data Entry CRT by using the keyboard. This information includes an address and a type code that describes the type of accident or incident. For example, the type of code would differentiate between a house and an office building fire, and a heart attack. The system does not directly support the dispatcher in entering the type code; they must remember the appropriate code or find it in a separate paper–based index. After the incident has been entered into the computer, the CRT displaying the status of the vehicles and incidents adds it to the queue. In addition, the computer–aided dispatch system pairs an appropriate response (an appropriate set of vehicles selected from a location near the accident) with the incident. The information specifying the type and number of emergency vehicles appears as alphanumeric codes. The information appearing on the Status CRT appears on the status displays of all the dispatchers.
The two large monitors at each end of the room display map information concerning the location of the incident and the movement of emergency vehicles to the incident. This information can be manipulated by any of the dispatchers using the command line interface associated with the Data Entry CRT. For example, dispatchers can display parts of the map associated with each of the incidents. The operators can also specify the scale and detail included in the view (e.g., removing street names to reduce clutter).
Auditory Information Display
We are not aware of any auditory display associated with the in–vehicle portion of TravelPilot. There are conventional voice radio communication systems in the vehicles equipped with TravelPilot.
User Input (Controls)
There are six buttons arranged vertically on either side of the CRT. These buttons appear to be about 9.5 mm in diameter. The buttons are separated by about 12.7 mm (the size and separation are estimated, not measured).
The buttons along the side of the display are the primary controls available to the user. The physical characteristics of the button were described in the General Description section above. The function of each button is labeled by text on the screen adjacent to the button. Buttons that are not active have no label. Similarly, functions that do exist in the system but are not available from the current page are not displayed. If the user wants or needs to use this control, the system, or vehicle (if there is a motion interlock), must be put in the correct configuration. No system aids have been identified that assist the operator in configuring the system or vehicle.
Some features are not available when the vehicle is in motion. For example, a destination cannot be entered by the driver when the vehicle is in motion. Sensors attached to the wheel report vehicle motion. The driver need not put the transmission in "park" as is the case on another of the systems (e.g., TravTek) reviewed here. Other functions, such as being able to change the scale of the map, are available while in motion. There is an override that allows entry of a destination while in motion as part of the Navigator system. This is intended to allow a person other than the driver to enter a destination while in motion. We were not able to confirm whether this optional feature was provided in the systems used by the Seattle Fire Department. (This override feature is provided in response to user specifications.)
Since the purpose of the emergency response dispatch system is to communicate information from the dispatchers to the drivers, a critical element of this system is the communication system. The communication requirements involve both information from the dispatchers to the drivers, and information from the drivers to the dispatchers. Specifically, drivers must know where and when they are to respond to incidents. Likewise, dispatchers must efficiently allocate a limited resource (emergency response vehicles and crews). This implies that dispatchers must be able to track the location and status of vehicles under their purview.
Traditionally, dispatchers and vehicles transferred vital information using voice communication over standard radio frequencies and hardwired alarms at the stations. The TravelPilot augments this communications channel by enabling the dispatch system to track the location and status of vehicles without voice communication over radio channels. An Automatic Vehicle Location (AVL) system monitors vehicle location and status, and transmits that information to the dispatch center automatically. This information is broadcast over an RF channel, received by a radio tower, and forwarded to the dispatch center by a telephone line. In a similar manner, information such as messages deploying vehicles to an incident is transferred from the dispatch center to a broadcasting tower through a dedicated telephone line. The broadcast center forwards this information to the vehicles through an RF transmission. The drivers and dispatchers also communicate by voice using a standard radio.
The voice communication takes place in two phases. In the first phase, dispatchers send a message that informs the crew of the general area of the incident and sends them on their journey. During the journey, a second message provides specific information regarding the exact location of the incident and detailed information regarding what the crew is to expect.
Attentional Demands on Drivers
The cognitive demands associated with the TravelPilot system in the vehicles should not affect drivers because they are not meant to observe or manipulate the device while driving. However, the passenger could use the device to provide the driver with more precise location information and better directions when traveling in unfamiliar areas. In addition, the system can help reduce the workload associated with reporting the unitð=s status to the dispatcher. Conversely, the system also imposes significant cognitive demands on the vehicle operators that would not have occurred otherwise. For example, accessing the functions of the TravelPilot requires navigation through a structured menu system. This task may impose demands on long–term memory in terms of remembering the menu structure and the commands to invoke specific functions. The cognitive demands associated with learning system functions are illustrated by the training requirements. The vehicle crews participated in 8 hours of training before the system was fielded and then received another 2 hours of on–road training when the system was installed. In addition, efficient operation of the system requires that operators understand the factors that cause the location estimation ability of the device to become miscalibrated. Likewise, drivers must know how to re–calibrate the system. Otherwise, the system generates erroneous information for the vehicle operators and the dispatchers.
Cognitive Demands on Dispatchers
The system eliminates many error–prone and repetitive tasks for dispatchers (e.g., manually looking up address to determine appropriate station for response). In addition, the system provides dispatchers with the capability to manage the emergency vehicle in ways that were not possible before. For example, the system keeps an electronic log of all responses. This log includes response times and incident types. These data can be analyzed to obtain measures of system performance. In addition, the system is able to pair a set of vehicles with an incident type. For example, the system would automatically assign a different set of vehicles to a two–alarm fire, a minor brush fire, or a cardiac arrest report. Previously, the dispatcher had little support in matching incident type with an appropriate response. In addition to selecting the appropriate type or set of vehicles, the system also identifies specific vehicles for the response by using AVL to first determine if any emergency vehicles might be available and already near the scene of the incident. If no vehicles are in the immediate proximity of the incident, then the system identifies vehicles in nearby stations. In this way, the system minimizes the cognitive load on the dispatcher, while enabling the dispatcher to match the emergency response centersð= limited resources to the emergency response needs of the city.
Although the system reduces the cognitive load of the dispatcher in many ways, the new technology also introduces some new demands and potential problems for the dispatchers. For example, although the system automatically identifies sets of emergency response vehicles, the dispatcher has the ultimate responsibility for ensuring that the most appropriate team has been selected. Since the computer–aided dispatch system may not have access to the current state of all vehicles (drivers forget to place them out of service when they go to the shop for maintenance), the group of vehicles the system recommends may not actually be available. Similarly, in some circumstances, the algorithm used to select vehicles may not accurately choose the best set of vehicles. Specifically, if the system is not able to find a vehicle already in the vicinity of the incident, it selects a group of vehicles from the nearest station. However, the algorithm does not verify that those vehicles are near the station. For instance, the needed vehicle may be available, but it may be returning from a call across town. In this situation, the computer provides a poor selection of vehicles because it fails to select the closest available vehicles. Since the computer makes these types of mistakes, the system introduces a substantial cognitive load associated with monitoring the feasibility of the computer recommendations.
The introduction of the new system also changed the processing of aid requests and the interaction among the dispatchers. In the previous system, dispatchers used a card file of addresses to identify the appropriate station from which to dispatch vehicles. In the current system, the computer does this task automatically. While the previous system forced dispatchers to perform a tedious and somewhat time–consuming task, performing this task had a side benefit of increasing the awareness of dispatchers of the other calls that the center had received. When an incident was reported, this information quickly became shared knowledge; and when an incident generated multiple calls, the dispatchers were able to identify multiple aid requests associated with the same incident. Now that the dispatchers do not rely on the same common resource (the card file of addresses), multiple reports of the same incident may be entered into the system. This results in added workload as the multiple entries must be filtered so that dispatchers do not mistakenly send multiple responses to a single incident.
More generally, introducing the computer–aided dispatch generates additional cognitive demands associated with simply interacting with the system. Often the command line interface can frustrate dispatchers because it requires memory of precise syntax. For infrequently used commands, this becomes problematic. These demands may reduce dispatcher efficiency, especially when workload demands are already high and the added burden of remembering and entering the precise data or syntax can severely degrade dispatcher performance. In addition, the barrier that the command line interface imposes can inhibit the users so that they fail to use the system to its full potential. For example, the dispatch center has two monitors at either end of the room. These monitors display a city map and provide an overview of the situation by displaying the real–time location of the emergency response vehicles and the incident. The operators do not use this map, in part, because the command line interface makes changing scales and views awkward. Thus, the characteristics of the computer interface may reduce dispatcher efficiency and inhibit their use of the full capability of the system.
DESIGN GUIDELINES USED
Human Factors Design Guidelines
Development of the Navigator began in 1983 and required more than 2 years to bring to market. Roughly 2,000 Navigator systems were sold as after–market equipment through an ETAK dealer network in California. The size of the design team ranged between 15 to 35 people. The members of the Navigator design team had backgrounds in computer science, engineering, navigation, and cartography. Human factors guidelines were consulted in the development of the Navigator. The areas where the input was useful are exemplified by the selection of font size and reach envelopes for installation position guidelines. Unfortunately, the titles of the specific human factors references and guidelines were not available.
The interview with the principal engineer from the system integrator, PRC, suggested that their group has little knowledge of human factors or ergonomics. However, for many of their objectives, they feel no need for human factors guidelines. Much of their concern focuses on a systems perspective that addresses information requirements and system architecture specifications. PRC focuses on the content of displays and not their form; they identify what to display, not how to display it. Conversely, their role in system development spans the spectrum from specifying the size and location of information on the screen to training the operators after the system is installed. They do not currently employ human factors specialists or use any human factors guidelines.
This lack of understanding of the scope of human factors is commonplace in the engineering community. Clearly, human factors practitioners contribute to a systems perspective, information requirements, the content of screens, and operator training.
The Navigator was evaluated by an outside agency (Failure Analysis Associates, Inc.). This evaluation focused primarily on crashworthiness and liability issues, rather than usability testing or Human Factors issues such as glance frequency and duration.
A variety of standards and guidelines were used in developing the Navigator. Standards were used to determine the location of the device within the vehicles. Society of Automotive Engineers (SAE) standards were mentioned as being used specifically. Examples of areas in which standards were used to guide the design include ruggedization and moisture resistance. The design team also relied on standards concerning crashworthiness. Standards and conventions from cartography were examined in the development of the dynamic labeling algorithm. Notably, the decision to position labels parallel to roads to minimize the difficulty of associating a name with a road, rather than keeping all text horizontal to improve readability, was decided based on the cartographic literature.
More generally, the process used for system development does not seem to rely on any formal guidelines developed by any discipline. The single exception lies in the use of DOD engineering benchmarks for architecture and performance standards. In this instance, these standards were employed as a checklist to ensure product quality, rather than a tool that guides the design process. PRC employs methods and techniques that have been developed and tailored to the needs of emergency dispatcher centers. The methods and techniques focus on identifying user needs and then constructing a system to meet those needs. They elicit user needs through an intensive process of interviews with all potential users, including managers, drivers, dispatchers, and administrators. PRC uses people with domain expertise (e.g., experienced dispatchers and former police officers) and technical expertise (e.g., system engineering and computer science) to bridge the gap between defining user requirements, conceptual development, and operational implementation.
In addition to the methods that PRC has developed to gather and process information regarding user needs, they use several other tools to guide the software development process. Since each emergency dispatch installation is unique they do not install ready–made systems, rather they provide custom–designed solutions to the client's problems. However, since they install many similar systems, they are able to develop custom–designed software from a collection of relatively generic modules that can be tailored to specific needs. To aid in this process, PRC uses a variety of Computer–Aided Software Engineering (CASE) tools. These tools can aid in the understanding of complex workflow and data modeling problems.
Other Sources of Design Guidance
ETAK has, almost since its inception, required all staff working on vehicle navigation to have a device in their personal vehicle and to keep logs of the use of the system, particularly errors and anomalies. All staff members are required to personally install the system in their own vehicle. The result is that they have lots of documented on–the–road mileage using their systems in a wide variety of vehicles.
ETAK has performed evaluations of concepts and design options using non–staff members. In particular, they have brought in subjects who were not experienced with the use of navigation devices and tasked them to drive to various locations. Subjective data were normally obtained. In some instances, they placed video cameras into cars to monitor the amount of time the driver spent looking away from the road. The purpose was to measure the time drivers looked at the display instead of the road (e.g., at stop lights or while in stop–and–go traffic), and to see if that amount of time and pattern were subjectively acceptable to drivers. No results of this effort are available.
ETAK reportedly tested novice users from various categories of the driving population. Age and gender were two of the factors used to stratify subjects.
Failure Analysis Associates, Inc., analyzed the Owner's Manual and the User's Manual prepared for the Navigator. The emphasis was on the adequacy of the warning labels.
Effectiveness of Human Factors Guidelines Used By System Designers
Human factors guidelines were useful in the interface aspects of the design. Selection of font size is an example. Human factors guidelines were not available (or were not found) on which to base other design decisions. Examples reported include:
The human factors literature used by ETAK in the development of the Navigator was inadequate to guide design decisions regarding map display features (e.g., area fills) that facilitate "situational awareness" or enhance "spatial awareness." As an example, no information was reportedly found that indicated whether coding notable regions, such as a body of water, in addition to the road network, would result in easier navigation to a destination.
[TP 01] HFE GUIDELINES USED FOR FONT SIZE
[TP 02] HUMAN FACTORS IS NOT RECOGNIZED BY INDUSTRY MANAGERS
[TP 03] THE SYSTEM EVALUATION CRITERIA EXCLUDED HUMAN FACTORS
[TP 04] SAE STANDARDS WERE USED IN THE DESIGN PROCESS
[TP 05] AN ENGINEERING APPROACH TO SYSTEM DEVELOPMENT WAS USED
[TP 06] CASE DESIGN TOOLS WERE USEFUL
[TP 07] IN-HOUSE STAFF USABILITY TESTING CAN PRODUCE VALUABLE INFORMATION
[TP 08] INFORMAL DRIVER STUDIES CAN PROVIDE INSIGHTS INTO DESIGN ISSUES
[TP 09] EVALUATIONS OF MANUALS NOT CENTERED ON USABILITY
[TP 10] MANY DESIGN FEATURES AND CRITERIA ARE PRIMARILY BASED ON COST
[TP 11] LIMITED EFFECTIVENESS OF HFE GUIDELINES PERCEIVED
[TP 12] HUMAN FACTORS LITERATURE HAS MANY LIMITATIONS
[TP 13] MAP ORIENTATION PREFERRED HEADING UP
[TP 14] SIZE OF MAP SCALES CAN VARY GREATLY
[TP 15] ACCURACY OF VEHICLE LOCATION IS CRITICAL TO USER ACCEPTANCE
[TP 16] ETA DATA NEEDED IN CVO APPLICATIONS
[TP 17] DATA STORAGE DIFFICULTIES CAN AFFECT SYSTEM DESIGN
[TP 18] MAP DATABASE LIBRARIES NEED TO BE UP-TO-DATE
[TP 19] MAP DATABASE SIZE IMPLICATIONS
[TP 20] VEHICLE LOCATION ACCURACY IS CRITICAL
[TP 21] MAGNETIC DISTURBANCES CAN IMPACT VEHICLE LOCATION ACCURACY
[TP 22] MESSAGE-RECEIVED FEEDBACK IS DESIRED
[TP 23] VEHICLE IDENTIFICATION SEQUENCE CAN BE CONFUSING
[TP 24] CUSTOMER-DRIVEN APPROACH TO ATIS SYSTEM DESIGN IS COMMON
[TP 25] TRAINING REQUIREMENTS NEED TO BE DIRECTLY ADDRESSED
Back | Table of Contents | Next
Topics: research, safety
Keywords: research, safety, Advanced Traveler Information Systems (ATIS), Commercial Vehicle Operations (CVO), Intelligent Transportation Systems (ITS), Intelligent Vehicle-Highway Systems (IVHS)