Integrated Vehicle-Based Safety Systems (IVBSS)
Phase I Interim Report

USDOT/NHTSA logo

DOT HS 810 952 May 2008

This publication is distributed by the U.S. Department ofTransportation, National Highway Traffic Safety Administration, inthe interest of information exchange. The opinions, findings, and conclusions expressed in this publication are those of the authors andnot necessarily those of the Department of Transportation or theNational Highway Traffic Safety Administration. The United States Government assumes no liability for its content or use thereof. If trade or manufacturer’s names or products are mentioned, it is because theyare considered essential to the object of the publication and should notbe construed as an endorsement. The United States Government does not endorse products or manufacturers.

Technical Report Documentation Page

Technical Report Documentation Page

Table of Contents

1 EXECUTIVE SUMMARY
2 INTRODUCTION
3 LIGHT-VEHICLE PLATFORM
4 HEAVY-TRUCK PLATFORM
5 DEVELOPMENT OF VERIFICATION TEST PROCEDURES AND PHASE I TESTING
6 DVI AND HUMAN FACTORS TESTING
7 FIELD OPERATIONAL TEST PREPARATION
- 7.1 Data Acquisition System
8 CONCLUSIONS
9 REFERENCES
APPENDIX A: COMPLETE PROJECT SCHEDULE
APPENDIX B: DRIVER-VEHICLE INTERFACE WARNING SOUNDS

List of Figures

Figure 1. Approximate timing of IVBSS vehicle development and testing
Figure 2. Major IVBSS program tasks
Figure 3. Breakdown of crash types in the United States (2003)
Figure 4. Systems engineering process for the light-vehicle platform
Figure 5. High-level system functional model
Figure 6. Mid-level system functional model showing selected IVBSS components
Figure 7. Light-vehicle functional partitioning
Figure 8. IVBSS light-vehicle system architecture
Figure 9. Light-vehicle schedule for functional requirements and system architecture
Figure 10. Overall light-vehicle Phase I development plan flow
Figure 11. Light-vehicle crash alert zones and thresholds addressing lateral drift crashes
Figure 12. Light-vehicle forward zone for addressing rear-end crashes
Figure 13. Light-vehicle sensor coverage overview (not to scale)
Figure 14. New SafeTRAC-2 LDW system
Figure 15. Light-vehicle schedule for subsystem development
Figure 16. Driver-vehicle interface block diagram
Figure 17. Visual display (left) and blind spot detection icons installed in the Honda Accord
Figure 18. IVBSS mute button (right) and volume control switch (second from right)
Figure 19. IVBSS module, sensor, and camera placement in vehicle
Figure 20. Trunk rack system
Figure 21. LCM short-range radar sensors
Figure 22. LR radar sensor
Figure 23. Schedule for light-vehicle system integration and prototype building
Figure 24. System engineering process for the heavy-truck platform
Figure 25. Heavy-truck sensor suite overview (not to scale)
Figure 26. Schematic diagram of the system hardware architecture
Figure 27. Heavy-truck schedule for functional requirements and system architecture
Figure 28. Overall heavy-truck Phase I development plan flow
Figure 29. Lateral-drift crash alert timing concepts
Figure 30. Forward crash alert timing concepts
Figure 31. Heavy-truck schedule for performance guideline development
Figure 32. Bronze tractor sensor mounting
Figure 33. Heavy-truck schedule for subsystem development
Figure 34. Bronze tractor DVI placement
Figure 35. Heavy-truck DVI space in truck cockpit
Figure 36. Gold tractor (International Transtar)
Figure 37. Schedule for heavy-truck system integration and prototype building
Figure 38. Map of light-vehicle on-road verification test route
Figure 39. Map of heavy-truck on-road verification test route
Figure 40. Breakdown of nuisance alert rate both LV on-road tests
Figure 41. LDW availability by travel speed in LV on-road tests
Figure 42. Breakdown of nuisance alert rates in HT on-road tests
Figure 43. LDW Availability by travel speed bin in HT on-road tests
Figure 44. Rear-end crash scenario 1
Figure 45. Rear-end crash scenario 2
Figure 46. Rear-end crash scenario 3
Figure 47. Rear-end crash scenario 4
Figure 48. Rear-end crash scenario 5
Figure 49. Rear-end crash scenario 6
Figure 50. Rear-end crash scenario 7
Figure 51. Rear-end crash scenario 8
Figure 52. Rear-end crash scenario 9
Figure 53. Rear-end crash scenario 10
Figure 54. Rear-end crash scenario 11
Figure 55. Rear-end crash scenario 12
Figure 56. Lane-change crash scenario 1
Figure 57. Lane-change crash scenario 2
Figure 58. Lane-change crash scenario 3
Figure 59. Lane-change crash scenario 4
Figure 60. Lane-change crash scenario 5
Figure 61. Road departure crash scenario 1
Figure 62. Road departure crash scenario 2
Figure 63. Road departure crash scenario 3
Figure 64. Road departure crash scenario 4
Figure 65. Road departure crash scenario 5
Figure 66. Road departure crash scenario 6
Figure 67. Road departure crash scenario 7
Figure 68. Road departure crash scenario 8
Figure 69. Multiple-threat crash scenario 1
Figure 70. Multiple-threat crash scenario 2
Figure 71. No-warn threat scenario 1
Figure 72. No-warn threat scenario 2
Figure 73. No-warn threat scenario 3
Figure 74. No-warn threat scenario 4
Figure 75. No-warn threat scenario 5
Figure 76. No-warn threat scenario 6
Figure 77. No-warn threat scenario 7
Figure 78. No-warn threat scenario 8
Figure 79. Schedule for Phase II extended pilot testing
Figure 80. Schematic of data movement paths
Figure 81. Complete project schedule for light-vehicle platform
Figure 82. Complete project schedule for heavy-truck platform

List of Tables

Table 1. Light-vehicle IVBSS sensor suite versus warning function
Table 2. Crash alerts for the light-vehicle platform
Table 3. Advisories for the light-vehicle platform
Table 4. Heavy-truck IVBSS sensor suite versus warning function
Table 5. Support vehicles for mule activity and prototype use in Phase I
Table 6. IVBSS heavy-truck DVI warning strategy space
Table 7. Breakdown of alerts in Phase I on-road test
Table 8. Breakdown of alerts in Phase I extension on-road test
Table 9. Breakdown of alerts in Phase I test
Table 10. Breakdown of alerts in November 2007 on-road test
Table 11. Breakdown of alerts in the Phase I extension test
Table 12. FCW LV Phase I track test results
Table 13. LDW LV Phase I test-track results
Table 14. CSW LV Phase I test-track results
Table 15. LCW LV Phase I test-track results
Table 16. LCW LV Phase I extension test track results, February 2008
Table 17. MT LV Phase I track test results
Table 18. MT LV Phase I extension track test results, February 2008
Table 19. Phase I LV no-warn test results
Table 20. FCW HT Phase I track test results
Table 21. FCW HT Phase I extension track-test results, March 2008
Table 22. LDW HT Phase I track-test results
Table 23. LDW HT Phase I retest test track results, November 2007
Table 24. LDW HT Phase I extension test track results, March 2008
Table 25. LCW HT Phase I test track results
Table 26. LCW HT Phase I retest track results, November 2007
Table 27. LCW HT Phase I extension test track results, March 2008
Table 28. MT HT Phase I test track results
Table 29. MT HT Phase I extension track test results, March 2008
Table 30. Phase I HT no-warn test results
Table 31. Phase I extension HT no-warn test results
Table 32. Sequence of ex periments

List of Acronyms

AASHTO	American Assoc. of State Highway and Transportation Officials
ACAS	Automotive Collision Avoidance System
AMR	Available Maneuvering Room
BSD	Blind Spot Detection
CAMP	Crash Avoidance Metrics Partnership
CAN	Controller Area Network
CCD	Charge-Coupled Device
CDP	Concept Development Process
CFR	Code of Federal Regulations
CMOS	Complementary Metal-Oxide Semiconductor
CO	Contracting Officer
Co-PI	Co-Principal Investigator
COTR	Contracting Officer's Technical Representative
cRIO	Compact Reconfigurable I/O
CSW	Curve Speed Warning
CVO	Commercial Vehicle Operator
DAS	Data Acquisition System
DFR	Draft Final Report
DIU	Driver Interface Unit
DOORS	Dynamic Object-Oriented Requirements Management System
DRDA	Division of Research Development and Administration
DVI	Driver-Vehicle Interface
FAD	Light-vehicle module for FCW, Arbitration, and DVI
FCW	Forward Crash Warning
FOT	Field Operational Test
FOV	Field of View
HIL	Hardware-in-the-Loop
HT	Heavy Truck
ICD	Interface Control Document
IMU	Inertial Measurement Unit
IMS	Independent Measuring System
IRB	Institutional Review Board
ISO	International Organization for Standardization
IVBSS	Integrated Vehicle-Based Safety Systems
LAM	Look Ahead Module
LCM	Lane-Change/Merge Warning
LDW	Lateral Drift Warning
LV	Light Vehicle
LVO	Light-Vehicle Operator
MDOT	Michigan Department of Transportation
MFVB	Multi-Function Vision Board
MLP	Most Likely Path
MUTCD	Manual of Uniform Traffic Control Devices
NHTSA	National Highway Traffic Safety Administration
NI	National Instruments
NIST	National Institute of Standards and Technology
OEM	Original Equipment Manufacturer
OPM	Operational Procedure Model
PDT	Product Development Team
PI	Principal Investigator
PXI	PCI eXtensions for Instrumentation
RDCW	Road Departure Crash Warning
RFA	Request for Application
RPU	Radar Processing Unit
SAM	Situational Awareness Module
SAVE-IT	SAfety VEhicles Using Adaptive Interface Technology
SWF	Scalable Weighting Factor
TBD	To Be Determined
TTC	Time-to-Collision
TTLC	Time-to-Lane Crossing
TTE	Time-to-Event
TTW	Time-to-Warning
U.S. DOT	United States Department of Transportation
UM	University of Michigan
UMTRI	University of Michigan Transportation Research Institute
VOC	Voice of the Customer
VORAD	Vehicle Onboard RADar
VSA	Vehicle Stability Assist

1 Executive Summary

1.1 Introduction and Background

In November 2005, the U.S. Department of Transportation entered into a cooperative research agreement with an industry team led by the University of Michigan Transportation Research Institute to develop and test an integrated, vehicle-based crash warning system that addresses rear-end, lane-change, and roadway departure crashes for light vehicles and heavy commercial trucks. The program being carried out under this agreement is known as the Integrated Vehicle-Based Safety Systems program.

The goal of the IVBSS program is to assess the safety benefits and driver acceptance associated with prototype integrated crash warning systems. Preliminary analyses conducted by NHTSA indicate that a significant number of crashes can be reduced by the widespread deployment of integrated crash warning systems that address rear-end, lateral drift, and lane change/merge crashes.^{22 24 29} Such integrated warning systems have the potential to provide comprehensive, coordinated information, from which the individual crash warning subsystems can determine the existence of a threat and thus, provide the appropriate warning to drivers.

The IVBSS program is a four-year effort divided into two consecutive, non-overlapping phases. The UMTRI-led team is responsible for the design, build, and field-testing of the prototype integrated crash warning system. This report summarizes work performed during the second half of the IVBSS program’s Phase I, and discusses contributions by UMTRI and its team members, including design and development of the integrated system and a variety of products the program has generated. A detailed description of efforts accomplished in the first half of Phase I is provided in the IVBSS First Annual Report.³⁰

1.1.1 Crash Problem

Three crash warning subsystems are being integrated into each platform of the IVBSS program: forward crash warning, road departure warning, and lane-change/merge crash warning. The three target crash areas addressed by the IVBSS program represent approximately 6,318,000 police-reported crashes that took place in the United States in 2003.²¹ Of these crashes, 96 percent (6,060,000) involved at least one light vehicle, while heavy commercial trucks were involved in about 362,000 of these crashes. Collectively, rear-end, road departure, and lane-change crashes accounted for about 60 percent of all police-reported light-vehicle and heavy-commercial-truck crashes, and approximately 50 percent of all crash-related fatalities.

All crash-warning subsystems examined in the IVBSS program have undergone some level of previous development and evaluation. Major programs supported by the U.S. DOT have addressed forward crash warning, road-departure crash warning, and lane-change/merge systems.^{4 5 16 17 19 24 25 26} These systems are also the most mature from a commercial and research evaluation standpoint. What differentiates the IVBSS program from previous efforts is that these subsystem are being evaluated as part of an integrated crash warning system, rather than independently, and the level of integration is greater than any undertaken in prior programs of its kind.

The scope of systems integration on the IVBSS program includes integration of sensor data across subsystems (data sharing), arbitration of warnings based upon threat severity, and development of an integrated driver-vehicle interface. The overall goal of the integration effort is improved performance versus standalone systems by increasing system reliability, reducing false warnings, improving driver reaction time to warnings, and improving driver acceptance.

1.1.2 IVBSS Program Plan

The IVBSS team at the Department of Transportation includes representatives from the National Highway Traffic Safety Administration, the Research and Innovative Technology Administration—specifically, its Intelligent Transportation Systems Joint Program Office and the Volpe National Transportation Systems Center—the Federal Motor Carrier Safety Administration, and the National Institute of Standards and Technology.

The light-vehicle platform team, led by UMTRI, includes Visteon Corporation, Honda R&D Americas, and Cognex Corporation. The heavy-truck platform partners are Eaton Corporation, International Truck and Engine Corporation, Cognex Corporation, Con-way Freight (a commercial trucking company), and the Battelle Memorial Institute. The involvement of industrial partners on the IVBSS program is seen to be critical, given their technical knowledge and ability to deploy actual systems into the U. S. vehicle fleet.

The first year of the IVBSS program was comprised primarily of research, engineering, development, and verification efforts; performance improvements to non-integrated crash warning systems gained through sensor and data fusion, and improved warning effectiveness that were generated by an integrated driver-vehicle interface were also investigated.

The second year of the IVBSS program, the focus of this report, was comprised of continued system development, the publication of IVBSS functional requirements and system performance guidelines, the development and conduct of verification test procedures, and the conclusion of studies addressing the design of integrated driver-vehicle interfaces. The goal of the second year of the program has been to demonstrate the viability of the integrated system, as determined by verification tests and performance criteria; Phase II will include the building of a fleet of IVBSS-equipped vehicles and the conduct of field operational tests of the integrated system for both passenger cars and heavy trucks (class 8).

1.1.3 Phase I – IVBSS Development

Figure 1 illustrates the timing and number of vehicles included in the program. In the first year, eight vehicles were purchased or leased on which the developmental subsystems were installed. This includes six Honda Accord EXs (the make and model to be used in the FOT), one Chevrolet Suburban with an enclosed trailer that is serving as a surrogate for a class 8 tractor-trailer combination on the heavy-truck platform, and an International 8600 series tractor (the make and model to be used in the FOT). The heavy-truck platform used the surrogate vehicle to allow members of the team who do not hold commercial driver licenses to experience the systems under development. In the second half of Phase I, work continued on these eight vehicles and the heavy-truck platform added an International Navistar tractor, which is representative of the tractors that would be used in the field operational test.

Figure 1. Approximate timing of IVBSS vehicle development and testing

Figure 1. Approximate timing of IVBSS vehicle development and testing

Specific efforts completed in the second half of Phase I included finalizing the system performance guidelines and functional requirements documentation. These documents were circulated to stakeholders for both passenger-car and heavy-truck manufacturing industries for comment. The final documents were completed and made available to various stakeholders at the end of Phase I. The system performance guidelines offer quantitative and measurable metrics that are considered achievable and appropriate for the system, while the functional requirements describe how the IVBSS system should perform.

Additional subsystem development was performed to improve overall and subsystem performance. This included developing methods for the arbitration of warnings and finalizing the IVBSS integration into prototype vehicles. Testing and development of the driver-vehicle interface characteristics was completed, and the IVBSS Human Factors and Driver-Vehicle Interface (DVI) Summary Report was published.⁶

The UMTRI-led team and the U.S. DOT worked extensively to finalize system verification test procedures and conduct the verification tests. The results from these verification tests served as the basis for the decision to proceed with the field operational test (Phase II). To support the IVBSS development process and verification testing, the design of a data acquisition system that permits the collection of data from the developmental vehicles was furthered and represents the initiation of future data acquisition systems to support Phase II. Lastly, the beginnings of the experimental design and field operational test plans began.

The duration of Phase I of the program was extended by a period of five months, from an original Phase I completion date of November 22, 2007, to April 30, 2008. This extension was necessary to allow for additional verification testing to be performed, as well as to provide the team with further time to complete several Phase I deliverables.

1.1.4 Phase II – IVBSS Deployment and Analysis

The following activities will take place during Phase II:

Extended pilot testing;
Acquisition of the remaining vehicles;
Building of the fleet of passenger cars and heavy trucks;
Finalization of experimental design and protocol for the field test;
Conduct of the field operational test; and
Analysis of the results.

In the conduct of the field operational test, at least 108 passenger car drivers and 15 drivers of heavy trucks will be recruited. The actual field test will be conducted over a 12-month period for passenger cars and a 10-month period for heavy trucks, and will collect extensive data on driver performance with, and without, warnings provided by the integrated safety system. Instruments used in assessing driver acceptance of IVBSS will also be developed and used in the conduct of the field test.

1.2 Phase I Accomplishments

1.2.1 Systems Architecture Development

Systems architecture development was completed for both the light-vehicle and heavy-truck platforms. The systems architecture includes the partitioning of the IVBSS system into its major subsystems, specifying the sensors and software envisioned to reside in the subsystems, and identifying the hardware interfaces and communication protocols among the subsystems.

1.2.2 Sensor Suite Identification

Sensor suite identification involved the development of detailed descriptions of all sensors that make up IVBSS. Sensor type (vision, radar, inertial, and vehicle sensor) and specifications for these sensors were defined. The majority of sensors used in the IVBSS program are commercially available and intended for automotive and heavy-truck applications; however, all sensors were acquired and tested for the specific purposes of the IVBSS program.

1.2.3 DVI Option Space and Testing

The options available in the development of the driver-vehicle interfaces for post-production vehicles on the IVBSS program were identified, and a series of human factors tests, including initial pilot testing to examine design alternatives, were conducted. This included identifying visual and auditory display requirements and testing the characterization of the warnings. Furthermore, extensive engineering development went into providing prototype hardware of the DVI to support IVBSS evaluation. The final DVIs were the result of options available to the team, engineering judgment, simulator or laboratory studies, as well as jury and pilot testing. The IVBSS Human Factors and Driver-Vehicle Interface (DVI) Summary Report was produced in the second half of Phase I.⁶

1.2.4 Functional Requirements and Performance Guidelines

The functional requirements and system performance guidelines developed in the program describe the system’s functionality and the performance expected from it. Both the functional requirements and performance guidelines incorporate or reference existing requirements and standards where available. Drafts of these documents were circulated to industry stakeholders early in the second half of Phase I, and final documents were completed at the end of the phase.

1.2.5 Prototype Vehicle Development

Prototype vehicles were developed for both platforms in the second half of Phase I. Each prototype represented a fully functioning, street-worthy vehicle. On the light-vehicle platform, six 2007 Honda Accords were equipped with the four crash warning subsystems and arbitration packages. On the heavy-truck platform, one International tractor was initially equipped, followed by a second tractor at the end of Phase I. These vehicles were used not only for extensive development and refinement of IVBSS, but they were also used in the conduct of jury drives, initial pilot testing, and the verification test process.

1.2.6 Verification Test Plans Developed, Testing Completed, and Results Reported

Verification test plans were the basis of executing and evaluating verification test procedures. The verification tests served to demonstrate the effectiveness, repeatability, and general readiness of IVBSS for field operational testing. The test procedures were developed in close collaboration with U.S. DOT and its representatives to verify that the combined prototype system satisfies key performance specifications. The test plan provides: (1) detailed test scenarios and specifications, such as speeds, closing rates, road geometry, etc.; (2) performance metrics, the means by which the system performance can be evaluated; and (3) pass/fail criteria for determining system repeatability and robustness. Measurement variables served as the primary means of evaluating system performance when compared to an independent measurement system.

1.2.7 Field Operational Test Preparation and Plan Development

Preparation for the field operational test in Phase I entailed the design and development of prototype data acquisition systems for both platforms, and the selection of sensors not related to IVBSS system performance (in-cabin video cameras, microphone, etc.). Additional preparation went into securing actual vehicles with which to conduct the anticipated field operational test, including finalizing contractual agreements with a new heavy-truck manufacturer in the first year, and a trucking fleet in the second year of Phase I. A field operational test plan was also completed at the end of Phase I. This document provides details regarding how extended pilot testing and the field tests will be conducted. Issues addressed include sampling strategies for drivers, descriptions of how drivers will be recruited and trained, as well as the types of information that will be collected from drivers upon completing their participation in the tests.

1.3 Phase I Summary

Overall, the IVBSS program has completed numerous important engineering and documentation tasks during Phase I in order to prepare the program for the field operational test to be conducted in Phase II. In particular, the design and development of the IVBSS system architecture and the identification of sensors and equipment were completed; DVI development, specification, and testing have also been completed. System performance guidelines and functional requirements have been both circulated to industry stakeholders and finalized. Verification tests were developed, executed, and reported, and preparations for a field operational test begun. A new truck manufacturer was added to the program, and a trucking fleet, with which the field test will be conducted, has joined the UMTRI team. A high-level Gantt chart identifying major tasks on the IVBSS program is provided in Figure 2. (Specific program milestones and deliverables in support of these efforts are provided in Appendix A, with dates effective at the time of the completion of this report.)

Figure 2. Major IVBSS program tasks

Figure 2. Major IVBSS program tasks

2 Introduction

This report documents the IVBSS program’s activities and accomplishments in the design and development of an integrated vehicle-based safety system in Phase I of a cooperative agreement between U.S. DOT and a team led by UMTRI. The objective of the IVBSS program is to develop a state-of-the-art, integrated, vehicle-based crash warning system that addresses rear-end, lateral drift, and lane-change/merge crashes and to assess safety benefits and driver acceptance of the system through field operational testing. Future widespread deployment of such integrated systems may offer significant benefits in reducing the number of motor vehicle crashes on the Nation’s roadways. Crash reduction benefits specific to an integrated system can be achieved through a comprehensive and coordinated exchange of sensor data in order to more accurately determine the existence of a crash threat; in addition, the arbitration of warnings can be used to provide drivers with only the information that is most critical to avoiding crashes.

Three crash warning subsystems are being integrated into both light vehicles and heavy trucks in the IVBSS program as follows:

Forward crash warning warns drivers of the potential for a rear-end crash with another vehicle;
Lateral drift warning warns drivers that they may be drifting inadvertently from their lane or departing the roadway; and
Lane-change/merge warning warns drivers of possible unsafe lateral maneuvers based on adjacent or approaching vehicles in adjacent lanes, and includes full-time side object presence indicators.

The light-vehicle platform also includes a curve speed warning subsystem, which warns drivers that they may be driving too quickly into an upcoming curve and as a result, might depart the roadway.

2.1 Crash Problem

The scope of the crash problem addressed by the IVBSS program represents approximately 6,318,000 police-reported crashes that took place in the United States in 2003.²¹Of these crashes, 96 percent (6,060,000) involved at least one light vehicle and resulted in 1.5 million injuries and more than 19,000 fatalities. For the same time period, heavy commercial trucks were involved in about 362,000 crashes that resulted in 211,000 injuries and 1,100 fatalities. Collectively, rear-end, road departure, and lane-change crashes accounted for 60 percent of all police-reported light-vehicle and heavy truck crashes. Figure 3 illustrates the crash problem for the three major crash types addressed in the IVBSS program for light vehicles and heavy commercial trucks.

Figure 3. Breakdown of crash types in the United States (2003)

Figure 3. Breakdown of crash types in the United States (2003)

2.2 Program Purpose

The purpose of the IVBSS program is to assess the safety benefits and driver acceptance associated with a state-of-the-art integrated vehicle-based crash warning system. Preliminary analyses by the

U.S. DOT indicate that a substantial number of police-reported crashes (48% or 1.6 million) can be addressed through the widespread deployment of integrated crash warning systems that address rear-end, lateral drift, and lane-change/merge crashes.²⁹ The benefits of deploying integrated crash warning systems can be realized through coordinating and sharing sensor data, thus enabling crash warning subsystems to better determine the existence of a crash threat and issue useful warnings.

The IVBSS program has benefited from leveraging the work of several previous research programs on the development and deployment of crash warning systems. Information from these previous programs has aided in improving both the performance of specific crash warning subsystems and the integration effort by providing a more comprehensive understanding of benefits to be realized from sensor data sharing. The expectation is that the improvements in threat assessment and warning accuracy that can be realized through systems integration will, in contrast to a configuration of non-integrated warnings, result in increased consumer acceptance, the earlier introduction of integrated systems into the vehicle fleet, and a resulting reduction in crashes.

2.3 Previous Countermeasure Development

All of the crash warning subsystems being examined in the IVBSS program have undergone some level of previous development and evaluation, though not as part of an integrated warning system. Major U.S. DOT-sponsored programs have addressed the development and field testing of forward crash and road-departure crash warning systems for light vehicles and heavy trucks.^{4 5 8 16 17 19 24 25} The development of a lane-change/merge crash warning system has been supported by the U.S. DOT to a lesser degree with the development of performance guidelines.²⁶

2.4 Expected Benefits of an Integrated System

The scope of the systems integration task on the IVBSS program includes integration of sensor data across subsystems (data sharing), arbitration of warnings based on threat severity, and development of an integrated driver-vehicle interface (DVI). Integration should dramatically improve overall warning performance relative to the standalone subsystems by increasing system reliability, increasing the number of threats that can be accurately detected, and reducing false and nuisance warnings, thereby reducing crashes and increasing safety. If these improvements can be achieved, the result is expected to be increased consumer acceptance and earlier adoption relative to standalone warning systems. In addition, unlike standalone crash warning systems, the integrated system will be capable of detecting multiple threats that can be assessed and arbitrated to communicate only the most serious or immediate warning to the driver.

2.5 Program Approach

2.5.1 IVBSS Team Membership

UMTRI is serving as the prime contractor on the IVBSS program and is responsible for managing the program, coordinating the development of the IVBSS system on both platforms, developing data acquisition systems, and conducting the field operational tests. Visteon, with support from Cognex, is the lead system developer and systems integrator on the light-vehicle platform. Honda R&D is the light vehicle manufacturer and is providing engineering assistance throughout the development process. Eaton, with support from Cognex, serves as the lead system developer and system integrator on the heavy-truck platform, while International Truck is providing engineering assistance and will be responsible for some of the system installation. Battelle is supporting Eaton in the development of the heavy-truck DVI and warning arbitration. Con-way Freight will serve as the heavy-truck fleet for conducting the IVBSS field test, and the Michigan Department of Transportation is supporting UMTRI by assisting in the acquisition of crash and roadway geometry data to support analyses.

The U.S. Department of Transportation IVBSS program team includes representatives from the National Highway Traffic Safety Administration, Federal Motor Carrier Safety Administration, Research and Innovative Technology Administration (Intelligent Transportation Systems Joint Program Office), National Institute for Standards and Technology, and the Volpe National Transportation Systems Center. The U.S. DOT Research and Innovative Technology Administration’s Intelligent Transportation Systems Joint Program Office is the sponsor of the IVBSS program, providing funding, oversight, and coordination with other U.S. DOT programs, with the cooperative agreement is being administered by NHTSA.

2.5.2 Structure of the Program

The IVBSS program is governed by a cooperative agreement between the UMTRI-led team and the U.S. DOT. The program began on November 23, 2005, and is divided into two, non-overlapping phases. Efforts in Phase I, the basis of this report, were primarily focused on system design, development, specification, and verification testing. Phase II efforts include the buildup of a vehicle fleet, conduct of the field operational test, and subsequent analyses of system benefits and driver acceptance. Phase I, originally scheduled to last 24 months, required a 5month extension to address system performance issues, the re-conduct of certain system verification tests, and the delivery of several key program documents. Originally scheduled to end on November 22, 2007, the extension resulted in a new Phase I end date of April 30, 2008.

The first year of the IVBSS program was comprised primarily of systems engineering and systems development. This included performance improvements to non-integrated crash warning systems that can be achieved through sensor and data fusion and improved warning effectiveness associated with an integrated systems and an integrated DVI. Specific tasks on both the light-vehicle and heavy-truck platforms included developing system architectures, defining concepts of operation and functional requirements, describing the subsystems, identifying the sensors and hardware, and creating developmental vehicles.

The second year, along with the Phase I extension, consisted of continued system development, publication of IVBSS functional requirements and system performance guidelines, development and conduct of verification test procedures, and conclusion of studies addressing the design of integrated DVIs. The ultimate goal of the second year of the program was to demonstrate the viability of the integrated systems as determined by verification tests and performance criteria; this work was accomplished in order to seek approval to proceed with Phase II of the program, which was granted on April 8, 2008. Verification testing and the delivery of several key documents were completed during the Phase I extension period.

The second phase of the IVBSS program will involve study of system performance, user acceptance, and safety benefits, since it is only in the second phase that actual field operational testing is conducted. This phase includes three principal components: (1) building of the fleet vehicles, (2) field testing, and (3) system evaluation. The field test would be conducted over a 12-month period for light vehicles and a 10-month period for heavy trucks, and collect extensive data on driver performance with and without warnings provided by the integrated safety system. Subjective instruments used in assessing driver acceptance of IVBSS will also be developed and used in the conduct of the field test.

2.6 Phase I Accomplishments

During Phase I of the IVBSS program, the UMTRI-led team completed various important tasks to support a potential field operational test (Phase II). In the first half of Phase I efforts were concentrated on the design and development of the IVBSS system architectures, the identification of sensors and equipment, the beginning of DVI development, and the beginning of both the system performance guidelines and functional requirements. In the second half of Phase I, including the extension, a new truck manufacturer and a trucking fleet were added to the program, the team completed the DVI development and testing, both the system performance guidelines and functional requirements were completed, verification tests were developed, and these tests were performed and reported.

2.6.1 Systems Architecture Development

Systems architecture development was completed for both the light-vehicle and heavy-truck platforms in the first year. The systems architecture includes partitioning of the IVBSS system into its major subsystems, specifying the sensors and software envisioned to reside in the subsystems, and identifying the hardware interfaces and communication protocols among the subsystems. IVBSS system architecture was derived from the functional model developed during the first year of the program.

2.6.2 Sensor Suite Identification

Sensor suite identification involved the development of detailed descriptions of all sensors that make up IVBSS. Sensor type (vision, radar, inertial, and vehicle) and sensor specifications were defined. Most sensors used in the IVBSS program are commercially available and intended for automotive and heavy-truck applications; however, all sensors were acquired and tested for the specific purposes of the IVBSS program.

2.6.3 DVI Option Space and Human Factors Testing

The options available in the development of the DVIs for post-production vehicles on the IVBSS program were identified, and a series of human factors tests, including initial pilot testing to examine design alternatives, were conducted. This included identifying visual and auditory display requirements and testing the characterization of the warnings. Extensive engineering development went into providing prototype hardware of the DVI to support IVBSS evaluation. The final DVIs for the two platforms were the result of options available to the team in a postproduction vehicle, engineering judgment, simulator or laboratory studies, and jury and pilot testing in representative vehicles. The IVBSS Human Factors and Driver-Vehicle Interface (DVI) Summary Report was produced in the second half of Phase I. Key findings include:⁶

Warning sounds should be at least 80 dB(A) in the 1 to 5 KHz range;
The duration of auditory warning should be less than the expected mean response time to the warning;
No single prioritization scheme for warnings (simultaneous, priority interrupt, or delayed presentation) could be recommended based on the findings from a simulator study; and
Drivers in pilot tests with prototype vehicles found the IVBSS system and associated DVI to be intuitive and easy to use.

2.6.4 Functional Requirements and Performance Guidelines

The functional requirements and system performance guidelines describe the IVBSS system functionality and the performance expected from the integrated system. Both the functional requirements and performance guidelines incorporate or reference existing requirements and standards where available. Drafts of these documents were circulated to industry stakeholders early in the second half of Phase I, and final documents were completed at the end of the Phase I. Both of these documents will assist the automotive industry in the development of integrated systems by providing a framework through which future systems can be described.

The functional requirements for both platforms describe scenarios in which the crash warning system should warn drivers, as well as when warnings should not occur. Functional requirements are provided for each warning subsystem and for multiple threat scenarios. Scenarios are described in detail. System requirements are described in terms of general sensor requirements to achieve the functional requirements as well as appropriate approaches to convey warnings to drivers.

The system performance guidelines propose quantitative and measurable performance metrics for evaluating an integrated crash warning system like IVBSS. The guidelines build upon previous specification efforts for standalone crash warning systems, especially prior U.S. DOT projects and ISO standards. However, the focus in the IVBSS performance specification is on the integration of multiple warning functions, rather than on standalone systems.

2.6.5 Prototype Vehicle Development

Prototype vehicles were developed for both platforms in the second half of Phase I. Each prototype represented a fully functioning, street-worthy vehicle. On the light-vehicle platform, six 2007 Honda Accords were equipped with the four crash warning subsystems and arbitration packages. On the heavy-truck platform, one International tractor was initially equipped, followed by a second tractor at the very end of Phase I. These vehicles were used not only for extensive development and refinement of IVBSS, but they were also used in the conduct of jury drives, initial pilot testing, and the verification test process.

Several light-vehicle prototypes were used over an extended period in Phase I by the U.S. DOT to allow for real-world evaluation of system performance. These vehicles were also loaned to a number of stakeholders, namely vehicle manufacturers, to gain additional feedback regarding system performance and implementation. Due to the requirement of a commercial driver’s license, heavy-truck prototype vehicles did not receive as much stakeholder exposure.

2.6.6 Verification Test Plans Developed, Testing Completed, and Results Reported

Verification test plans were the basis for executing and evaluating verification test procedures. The verification tests served to demonstrate the effectiveness, repeatability, and general readiness of IVBSS for field operational testing. The test procedures were developed in close collaboration with U.S. DOT and its representatives in order to verify that the combined prototype system satisfies key performance specifications. The test plans provide:

Detailed test scenarios and specifications, such as, speed, closing rate and road geometry;
Performance metrics, the means by which the system performance can be evaluated; and
Pass/fail criteria for determining system repeatability and robustness.

Like the functional requirements and system performance specifications, the development and documentation of the verification test procedures will serve industry in the development of future systems by providing a uniform approach to system evaluation. The verification test procedures include extensive track-based testing and on-road test requirements.

While much of the verification testing was conducted in the second year, the final verification testing was completed during the Phase I extension. Both light-vehicle and heavy-truck platforms had undergone changes and, as such, some tests were re-conducted to ensure that the systems continued to function properly. Other verification tests during the extension were repeats of previous tests that had not passed for a variety of reasons. However, all track and on-road verification testing was completed successfully for both platforms during the Phase I extension.

2.6.7 Field Operational Test Preparation and Plan Development

A field operational test plan was completed at the end of Phase I. This document provides details on how extended pilot testing and the field tests will be conducted. Issues addressed include sampling strategies for drivers, descriptions of how drivers will be recruited and trained, and the types of information that will be collected from drivers upon completing their participation in the tests. The objective of the field test is to evaluate the potential benefits of integrating crash warning systems. In addition to determining if the IVBSS system can help reduce the instances of crash types addressed, part of the evaluation process is to determine how drivers respond to the system and whether the approaches used in the IVBSS program are acceptable to drivers.

The current field test plan includes at least 108 passenger-car drivers and 15 to 20 heavy-truck drivers. The light-vehicle field test would be conducted over 12 contiguous months, with each driver receiving an IVBSS vehicle for a period of 40 days. The first 12 days would serve as a baseline period in which data would be collected, but the system would not present warnings to the driver. The remaining 28 days would serve as the treatment condition in which IVBSS would be fully functional and will present warnings to the driver. In this manner it is possible to make a direct comparison between the before and after effects of IVBSS. The heavy-truck field test would last 10 contiguous months, with a baseline period of three months and a treatment condition of seven months. Passenger car drivers would use the IVBSS vehicle in place of their own passenger vehicle, while the heavy trucks would be introduced to a fleet and operated on regular routes by select drivers who service those routes.

2.7 Report Structure

The remainder of this report is organized as follows:

Chapter 3 describes the light-vehicle platform, including system design, subsystem and driver-vehicle interface development, and system integration.
Chapter 4 discusses the heavy-truck platform, including functional requirements, development of performance guidelines, subsystem and DVI development, and system integration.
Chapter 5 covers the development of verification test procedures and Phase I testing.
Chapter 6 details the DVI and simulator and laboratory testing.
Chapter 7 describes the preparations for the field operational tests.
Chapter 8 summarizes the major accomplishments of the first year research.
Chapter 9 contains a list of references.
Appendix A shows the milestones for each task in the project.
Appendix B provides sample audio warnings issued by the driver vehicle-interface.

3 Light-Vehicle Platform

The light-vehicle team is comprised of UMTRI, Honda, Visteon, and Cognex. The team incorporated curve speed warning, forward collision warning, lane-change/merge warning, and lateral drift warning systems into an integrated safety system with a unified driver-vehicle interface. The IVBSS system was installed on the 2006 Accord EX for development and will be installed in the 2007 Accord EX for field operational test deployment.

Visteon was the lead developer of the light-vehicle IVBSS countermeasure. Visteon was also responsible for leading systems engineering, vehicle integration, verification testing, and CSW, FCW, and LCM subsystem design. While UMTRI led the DVI requirements capture process, Visteon designed the in-vehicle DVI accordingly. Furthermore, Visteon was responsible for arbitrating the warnings between each of the warning functions (CSW, FCW, LCM, and LDW). Cognex was responsible for LDW subsystem design and supported vehicle integration, verification, and DVI implementation activities. Honda provided engineering support for vehicle integration and played a key role in the development and integration of specific elements of the DVI option space. UMTRI provided the data acquisition system, and leads the experimental design and conduct of pilot tests and the field operational test in Phase II.

3.1 Functional Requirements and System Architecture

3.1.1 Overview

The functional requirements and the system architecture (Task 1.b) were developed during the

first year of the program. Figure 4 shows this activity within the larger context of the Phase I systems engineering process. The crash problem, as described by the U.S. DOT, was considered along with previous and existing approaches to standalone crash warning systems. A system functional model was developed that described the functions and data flows necessary to address the target crash problem, as well as known operational scenarios (i.e., those that may lead to nuisance and false alerts). In parallel, the objectives, scope, and nature of IVBSS were defined, and, given the functional model, further functional requirements were derived. The system architecture was developed by aggregating the lower-level functions in a practical manner, recognizing the constraints of prototype hardware, and the interactions among functions. The steps on the right side of Figure 4 are described in later sections.

Figure 4. Systems engineering process for the light-weight platform

Figure 4. Systems engineering process for the light-weight platform

The functional requirements report for the light-vehicle platform was delivered and posted for public access on the ITS America website.¹² The functional requirements report was reviewed by industry and the feedback was consolidated into the final product. At the end of Phase I, the functional requirements report was updated to incorporate lessons learned from vehicle level development and verification testing. The final version was posted to the ITS America Web site in April 2008. The sections below describe the results of the functional requirements and system architecture efforts.

3.1.2 Functional Requirements

The first step in developing functional requirements was creating a detailed system functional model. Figure 5 shows the highest level of this model, which describes the relationship of the IVBSS system with the vehicle, driver, and environment. The IVBSS elements were further broken down into the six sub-functions (shown in Figure 6), which use data describing the roadway and targets (other vehicles), as well as data from the subject vehicle, in order to build an internal understanding of the driving situation. The threat of a potential crash is then assessed and decisions to issue IVBSS information to the driver are made. More levels of detail were developed than are shown here, and data flows among sub-functions were defined.

This process occurred in parallel with defining the objectives, scope, and primary strategy to be employed by IVBSS. The objectives of IVBSS are twofold: (1) to maximize potential safety benefits by providing the driver with critical information, and (2) to gain driver acceptance.

Figure 5. High-level system functional model

Figure 5. High-level system functional model

Figure 6. Mid-level system functional model showing selected IVBSS components

Figure 6. Mid-level system functional model showing selected IVBSS components

It was determined that two types of information would be provided: crash alerts and advisories. Crash alerts are audible, visual, or haptic displays that will be provided to help the driver be aware of an existing or quickly developing potential crash threat. Drivers are then responsible to decide whether and how to initiate an evasive maneuver. Advisories are less urgent warnings that are intended to assist the driver in decision-making to reduce the likelihood that a crash conflict will develop. IVBSS is, thus, a vehicle subsystem that supplements the driver’s situational awareness. IVBSS will not assume control of the vehicle, so there is no ongoing control function (e.g., active cruise control or lane-centering assist) and no automatic crash-avoidance control (e.g., automatic braking).

Crash alerts were determined to be applicable to five hazardous situations. These pre-crash conditions correlate to a majority of traffic crashes:

Subject vehicle is closing on a lead vehicle;
Subject vehicle is traveling too fast for an upcoming curve;
Subject vehicle is encroaching on a vehicle traveling in an adjacent lane;
Subject vehicle is drifting off of the roadway; and
A combination of two or more of the above.

IVBSS is an autonomous system that does not require other vehicles or the roadside to have additional equipment or capabilities. In this project, IVBSS must be implemented using technology that will be available and robust enough to conduct a field operational test in 2008. Lower-level functional requirements were developed for the five hazardous situations listed earlier. For each situation, requirements were levied for sensing, processing, and output to the driver. Descriptions and examples of these requirements are given in the following sections.

3.1.2.1. Sensing Requirements

IVBSS requires data in order to characterize the driving environment. This involves measurements from IVBSS sensors, communications with the vehicle, and use of static and dynamic onboard, or other, data sources. For each of the five hazardous situations listed earlier, requirements fall into five categories:

Sensing subject vehicle information and driver-control inputs: This stipulates the signals that IVBSS must obtain from the subject vehicle as well as IVBSS driver control inputs. For example, to address rear-end crashes, IVBSS must obtain subject vehicle speed, yaw rate, and driver brake switch. Other data may, of course, be desirable, including turn signal use, subject vehicle longitudinal acceleration, driver throttle control, wiper state, steering wheel angle, ambient temperature, and more.
Sensing roadway geometry and characteristics: This addresses the collection or acquisition of information about the roadway. For example, to address road-departure crashes, IVBSS must obtain data including: heading of the vehicle axes relative to the lane, position of the vehicle in the lane, determination of whether the lane edges are road edges, road curvature, upcoming road curvature, time rate of change of the lateral position of the vehicle relative to the road edge, and presence and geometry of upcoming roadway branches.
Sensing objects and characterizing object type and motion: This addresses identification and location of other vehicles that may pose a potential crash threat to the subject vehicle. For example, to avoid lane-change/merge crashes, IVBSS must detect and track same-direction vehicles in a field of regard that includes travel lanes adjacent to those in which the subject vehicle is traveling. In this case, the front edge of the field of regard shall be slightly forward of the subject vehicle and the rear edge shall be a distance behind the subject vehicle that allows for addressing crashes in which adjacent-lane traffic is overtaking the subject vehicle. IVBSS must determine those vehicles’ positions relative to the subject vehicle, laterally and longitudinally, and provide the relative speed in both lateral and longitudinal directions.
Estimating road condition parameters: Each warning function is required to obtain and use available data that may indicate low road friction.
Sensing driver attributes: In the second year, the light-vehicle platform will work toward incorporating individual driver behaviors into decisions about issuing crash alerts. The data necessary to support that activity is required to be available to the appropriate functions. For example, the FCW that addresses rear-end crashes will need headway- and speed-related measures that are thought to be potentially useful for this task.

3.1.2.2. Processing

Algorithms must be capable of processing the situational framework and determining that one or more of the hazardous situations are developing. The requirements for processing address situation characterization and threat assessment. Situation characterization is the determination of specific aspects of the driving situation needed by the system to ascertain that a potential crash threat exists. Given that a threat may exist, threat assessment for each warning sub-function generates an alert request that is sent to an arbitration function.

For each of the hazardous situations, a number of requirements were developed and documented.^{12 14} For situation characterization to address rear-end crashes, for instance, there are requirements to address object classification, path prediction, and target selection. An example of object classification is that IVBSS must be capable of rejecting the vast majority of roadside objects (e.g., road signs and mailboxes) from consideration as potential threats.

Threat assessment requirements for the same type of crash alert stipulate a primary need to accommodate driver reaction times and typical emergency braking levels. There are several allowances in the threat assessment sections that recognize the central difficulty of managing nuisance and false alerts. This means that the system is allowed to postpone or suppress crash alerts when there is a reasonable possibility that the driver is aware of the situation or is intentionally maneuvering, or that the threat sensing has a significant amount of uncertainty.

3.1.2.3. Output

IVBSS must be capable of conveying this information to the driver in a timely and understandable manner. The full set of functional requirements developed during the first year of the program is contained in the functional requirements for the IVBSS light-vehicle platform document (Task 1.b). These requirements address crash alert displays, advisory displays, driver inputs into IVBSS, and system status messages. The purpose of the crash alerts is to prompt an unaware driver to adjust attention in a manner that immediately allows assessing the appropriate aspect of the driving situation. Eleven qualities of displays were proposed and an early down-selecting of the display modalities associated with the crash types was proposed. These were modified later and are presented in Chapter 6.

3.1.3 System Architecture

As described earlier, the IVBSS system architecture was derived from the functional model developed during the first phase of the program. The first step was functional partitioning, the outcome of which is illustrated in part in Figure 7. The IVBSS system for light vehicles consists of six subsystems. At the top of the figure, four warning sub-functions each produce situational information and a request for driver alerts that address different crash types. To integrate these four systems into a seamless and intuitive driver interface, the arbitration subsystem is used to arbitrate and occasionally suppress alert requests that are received from the four sub-functions. The DVI subsystem presents information to the driver and also accepts driver inputs.

Figure 7. Light-vehicle functional partitioning

Figure 7. Light-vehicle functional partitioning

The implementation architecture was derived from the functional partitioning and data flow analysis. The resulting light-vehicle IVBSS architecture is depicted in Figure 8.

Figure 8. IVBSS light-vehicle system architecture

Figure 8. IVBSS light-vehicle system architecture

The three IVBSS CAN buses are shown as horizontal features running across the page. The five major elements above and below the buses are:

Gateway: Translates appropriate messages from two OEM data buses to one of the project CAN buses;
Lateral drift warning module: Uses forward vision-based lane tracking and other signals from the CAN bus to broadcast LDW alert requests onto the bus;
Curve speed warning module: Uses GPS, an onboard digital map, and other information to broadcast CSW alert requests onto a serial link to the FAD module;
FCW/arbitration/DVI module: A chassis that includes processors and other hardware on which FCW, arbitration, and DVI are hosted;
LCM module: A chassis using short-range radar data and other signals from the vehicle and IVBSS subsystem to assess threat when changing lanes or merging; and
Data acquisition system module: A two-CPU module with peripherals that records data

for analysis during development and the FOT. Three additional situational awareness modules (SAMs) process the data from the six short-range radar sensors. Also included is a power distribution module (PDM) that is required when installing IVBSS on a post-production vehicle. Several sensing and driver interaction elements are also associated with many of these elements. The individual subsystem functions are described in more detail in following sections.

3.1.4 Phase I Activities and Schedule

In Phase I, the functional requirements and vehicle architecture were updated during the vehicle-level development phase, as shown in Figure 9. A final Phase I release was completed in April 2008 to incorporate design changes and key results.

Figure 9. Light-vehicle schedule for functional requirements and systems architecture

Figure 9. Light-vehicle schedule for functional requirements and systems architecture

3.2 System Design, Development, and Integration

3.2.1 Overview

The output of the functional requirements and architecture tasks discussed previously is used by subsequent tasks. At the system level, the system design, development, and integration task creates and implements a vision for integrating the separate subsystems shown earlier in Figure. The goal of this task is a plan governing the actual design, development, and integration efforts that will lead to the prototype vehicles that are used in validation testing. The plan will describe the necessary tasks and success criteria for the stages of this process.

3.2.2 Design

Visteon used the concept development process to guide the team through the design, development, and integration of the IVBSS program (the system functional model was described earlier). Given that model and the functional requirements, the design process fills in the implementation of the detailed model, using the architecture and available tools. One output of this process is a detailed description of the signals exchanged between subsystems and shared with the data acquisition system.

3.2.3 Development

Development includes both subsystem- and system-level activities. Subsystem activities are discussed in section 3.4, while this section focuses on system issues. Figure 10 illustrates the overall design and development process employed on the light-vehicle platform.

Communications will be verified in a static environment on the bench. The initial functional and performance guidelines will be analyzed and refined. Additionally, alternative DVI implementations will be tested and evaluated. At the end of the development phase, jury drives will be conducted as well as accompanied pilot testing to further refine the IVBSS system.

During the first year, the LDW system was developed on the bench and through vehicle testing. The FCW algorithms were developed using Simulink models. The CSW algorithms and software were updated, based on findings from the RDCW platform and were migrated to the new hardware platforms selected for IVBSS. The updates include software and map-based enhancements to improve the accuracy of predicting whether the subject vehicle will move onto an upcoming road branch (e.g., freeway exit ramp), as well as different approaches to the use of lane boundaries, turn signals, and other secondary signals to issue or suppress alerts. Both CSW and FCW systems were installed on a Mercedes test vehicle for development. The LCM algorithms were developed on the bench.

During the second year, all subsystems were migrated from the bench or preliminary vehicles to the Honda development vehicles that were fully equipped with the IVBSS. Vehicle-level development was completed for the IVBSS system and verified through objective testing conducted at the test track and through on-road testing by U.S. DOT.

Figure 10. Overall light-vehicle Phase I development plan flow

Figure 10. Overall light-vehicle Phase I development plan flow

3.2.4 Integration

Integration addresses the installation of hardware on light vehicles and the resolution of any installation-related issues with system performance and reliability. One objective of the integration plan is to provide a vehicle that has the polish of an OEM vehicle, with driver controls and displays integrated in a manner that appears natural and is consistent with prevailing Honda design. The vehicle must be safe and reliable with prototype hardware secured and hidden from view. Recording devices such as cameras must not be intrusive or call attention to the experiment. Furthermore, integration for an FOT project must accommodate exchanges of prototype hardware, convenient access for software and hardware updates, and troubleshooting.

Six development vehicles were built to incorporate the IVBSS system architecture on the 2006 Accord EX platform. These vehicles were used for system development, jury drives, pilot testing, and system verification during Phase I. Upon approval to proceed to Phase II, an additional 12 vehicles (model year 2007) will be outfitted. Four of the development vehicles will be used as FOT vehicles, such that a 16-vehicle FOT fleet will be available.

Integration design was completed in the first year of the program. The actual development vehicle builds started near the end of year 1 and were completed in May 2007.

3.3 Development of Performance Guidelines

Figure 4 illustrates the system engineering process; given the functional requirements, a set of performance guidelines were developed and published in mid-2007. These are quantitative and measurable performance metrics that are considered achievable and appropriate for IVBSS. These guidelines drove details of the actual system implementation and served to guide establishing the pass-fail criteria for verification testing that was conducted October 9 to 15, 2007, and February 4 to 5, 2008. Final, revised guidelines were submitted and were posted on the ITS America website in April 2008.

3.3.1 Overview

The process of developing the preliminary guidelines was completed during the second year of the program. This built upon previous guideline efforts for standalone crash warning systems, especially prior U.S. DOT projects and ISO standards efforts.^{9 10 112 4 17 19 20 26}The focus, however, was on the integration of these functions. In some performance areas, integration allows improvements in potential safety benefits through enhanced system awareness. In other areas, integration presents a challenge, especially in ensuring driver acceptance because the broad scope of IVBSS could yield more potential sources of false and nuisance alerts.

3.3.2 Integrated System Performance Guidelines

The performance guidelines include specific bounds on system-level performance that may be discernible by an independent observer. The purpose of these guidelines is not to describe system performance as built, but to express the acceptable and achievable performance considered necessary to achieve the highest functional objectives (i.e., safety benefit and driver acceptance). For example, for potential lane-change/merge crashes, guidelines will stipulate the geometric zones (using specific ranges) and a range of times-to-collision at which crash alerts are required, prohibited, or allowed. A set of operating speeds, road types and geometries, and environmental conditions are described in which the guidelines must be satisfied. The presentation of crash alerts and advisories are described, in terms of display modality and commonality and distinctions of displays for different potential crash threats.

The System Performance Guidelines for a Prototype Integrated Vehicle-Based Safety System (IVBSS) – Light Vehicle Platform document defines commonly used terms and performance guidelines, and includes references upon which the performance guidelines were defined.¹⁸A sample integrated system performance guideline addresses the timing of crash alerts when a vehicle may be drifting from the roadway (Figure 11 illustrates such a scenario). A crash alert may be provided in a zone that encompasses the road edge, but also includes some portion of the lane itself, as well as areas beyond the lane edge. IVBSS must provide crash alerts at some point beyond the lane edge. This is called the must-inform zone, as shown in Figure 11. Similarly, Figure 12 illustrates the must-inform zone for a forward crash scenario. The guidelines make allowances for suppressing or delaying both types of crash alerts based on measured information that indicates a significant possibility that one or more of the following is true: (1) the driver is aware of the perceived conflict, or (2) the driver intends to initiate a maneuver, or is maneuvering, such that the potential conflict could be resolved through the maneuver. More details are available in System Performance Guidelines for a Prototype Integrated Vehicle-Based Safety Systems (IVBSS) - Light Vehicle Platform .¹⁸

Figure 11. Light-vehicle crash alert zones and thresholds addressing lateral drift crashes

Figure 11. Light-vehicle crash alert zones and thresholds addressing lateral drift crashes

Figure 12. Light-vehicle forward zone for addressing rear-end crashes

3.3.3 Phase I Activities

The preliminary light-vehicle integrated system performance guidelines document (Task 1.d) was delivered at the end of the first quarter of 2007.¹⁴The final IVBSS light-vehicle performance guidelines report was released at the end of Phase I.¹⁸It contains refinements based on system development feedback and verification testing.

3.4 Subsystem Development

Subsystem development involves the design and implementation of the functions defined for each of the six subsystems described in Figure 8, which in turn resulted from functional partitioning.

3.4.1 Overview

During the first year, the six subsystems have been developed somewhat independently on the bench, in the simulation environment, and on test vehicles (non-IVBSS-equipped vehicles). However, during the second year of the program, the six subsystems were developed in an integrated fashion on the Honda Accord EX, equipped with full IVBSS. All of the hardware and sensors were selected, designed, and developed to support the subsystem efforts. The following sections describe the sensor suite and detail the current status of subsystem development. Section 3.5 discusses the DVI subsystem, since there has been a separate and significant activity to incorporate human factors experiments into the design of the DVI. Furthermore, several significant decisions regarding the sensor set were made, as detailed in the following sections.

During the second year, stage 1 and stage 2 testing were completed. Stage 1 testing (jury drives) was conducted June 18 to 26, 2007. Twenty-seven people from Visteon, Cognex, U.S. DOT, Volpe, and NIST participated in the drives. The jury drives consisted of two hours of scripted driving, where maneuvers were performed by participants to elicit each of the warnings, and two hours of naturalistic driving where the participants drove one of three development vehicles around the Detroit suburbs at their discretion. At the conclusion of the naturalistic drive, each participant completed a questionnaire and the results were incorporated into the system design. Further details are found in section 5.

Stage 2 testing (accompanied pilot) was conducting in August 2007. Lay people were accompanied by UMTRI staff on a prescribed route in Ann Arbor. Before the drive, a static DVI demo was provided to the participants so that they would be familiar with the warnings. After the drive, each participant filled out a questionnaire. Results were incorporated into the IVBSS design. Further details are found in Section 5.

3.4.2 Subsystem Descriptions and Sensor Suite

The sensor suite for the light-vehicle application of IVBSS consists of vision, radar, inertial, and vehicle sensors and is depicted in Figure 13. The sensors and their applications are detailed in Table 1, with sensors associated with the warning sub-functions as primary or supporting sensors. The light-vehicle platform includes seven radars (one long-range forward-looking 77GHz radar, two rear-looking mid-range 24-GHz radars, and four side-looking short-range 24GHz radars); one camera; non-differential GPS with an onboard digital map; yaw rate gyroscope; and existing OEM vehicle data signals, such as speed, brake switch, turn signal status, etc. (Note: This does not include separate sensors that will be installed for the data collection effort to analyze the FOT data.)

Figure 13. Light-vehicle sensor coverage overview (not to scale)

Figure 13. Light-vehicle sensor coverage overview (not to scale)

Table 1. Light-vehicle IVBSS sensor suite versus warning function

Sensor	LDW	FCW	LCM	CSW
Forward radar (1)		X*
Side radars (2 each side)	X (AMR)		X*
Rear radars (1 each side)	X (AMR)		X*
Short-range forward vision (1)	X*		X
Vehicle yaw rate (1)	X	X	X	X
Vehicle data (speed, brake, turn, wipers, headlights, etc.)	X	X	X	X
GPS/dynamic database	X	X	X	X*

* = Primary sensor

The following addresses the separate subsystems including a subsystem overview, concept of operation, hardware, software, interactions with other systems, and status of subsystem development.

3.4.2.1. Forward Collision Warning (FCW) Progress and Accomplishments

3.4.2.1.1.Subsystem Overview

FCW uses radar, vision, and other onboard and map signals to detect and identify vehicles that the subject vehicle may potentially strike. The radar provides several tracks that are processed to identify legitimate vehicle threats, and then a computation determines when to request a FCW alert. The arbitration subsystem considers the request in conjunction with any other existing or impending requests from other warning subsystems, and decides whether to provide a crash alert to the driver.

3.4.2.1.2. Concept of Operations

The forward collision warning system warns the driver when the vehicle is in danger of striking the rear end of another same-direction or stopped vehicle. The objective of this system is to warn the driver early enough to avoid the collision, while avoiding excessive nuisance alerts. FCW system design attempts to address different forward collision scenarios such as:

Subject vehicle (vehicle equipped with the system) is moving on a straight or curved road, and there is a slower, stopped, or decelerating lead vehicle in the subject vehicle’s current lane (straight or curved);
Subject vehicle is moving on a straight or curved road following a lead vehicle. The lead vehicle changes lanes and a new slower, stopped, or decelerating lead vehicle appears in the subject vehicle’s current lane (straight or curved); and
Subject vehicle is moving on a straight or curved road following a lead vehicle. The subject vehicle changes lanes toward a new slower, stopped, or decelerating lead vehicle.

In all of these scenarios, the FCW is expected to warn the driver. The timing of the warning depends on the design tradeoff that is needed to minimize the number of nuisance and false alarms. The FCW system will not issue crash alerts in response to opposite-direction traffic, crossing-path traffic, or vehicles that are outside of the current subject vehicle travel lane.

3.4.2.1.3.Hardware

FCW processing occurs in the FAD module, as previously described. FCW uses long-range Bosch radar to detect and track objects in the forward scene. During the second year, extensive testing and development was completed that eliminated the forward camera for FCW. The main purpose of the FCW camera was to improve stationary object detection. Great strides were achieved in stationary object detection through improvements in the radar data processing algorithms, which eliminated the need for the long-range vision augmentation.

3.4.2.1.4. Software

There are four FCW software modules:

Radar-based scene tracking: Tracks objects with respect to the subject vehicle;
Path prediction and data fusion: Determines the upcoming geometry;
Primary target determination: Determines the in-lane primary target that is considered the most likely to pose a crash threat; and
Threat assessment: Given the primary target, decides whether to issue an FCW crash alert request.

3.4.2.1.5.Interaction with Other Subsystems

FCW uses map database attributes and most-likely-path attributes from CSW for path prediction and primary target selection. FCW calculates and sends the following data for use by other subsystems:

Refined curvature based on scene tracking and CSW curvature values; and
Primary target information, such as headway.

3.4.2.1.6. Development Activity

During the first year of development, FCW algorithms were implemented in Matlab/Simulink and used in a simulation environment. For the simulation, real-world data was used to develop and validate the algorithms. The algorithm models were then migrated to a rapid prototyping environment and installed on a test vehicle for further subsystem development on the road. During the second year of the program, the algorithms were ported to the FAD module and installed on all of the IVBSS development vehicles. The current algorithm development status is:

A radar-based FCW algorithm was implemented;
Vehicle detection and tracking was implemented;
Forward-radar sensor-track filtering was implemented based on a Visteon algorithm (filters 32 targets to eight targets);
Improvements to radar-processing algorithms have been completed that:
- Filter out over pass and under pass objects, and
- Improve target characterization to improve stopped object detection range.
Vehicle-based target validation and characterization is complete;
Long-range vision algorithm development is complete;
A fused FCW algorithm (vision, radar) was implemented and tested. Vision augmentation did not provide much value over the radar-only system once the radar processing improvements were realized. Therefore, vision was deleted from the program for the FOT;
Interface protocol is complete and implemented for proper communications between FCW and the yaw rate sensor, forward radar sensor, vision platform, CSW, and the vehicle test platform;
The trade-off study between long-range vision and radar-only threat assessment was
completed. Forward long-range vision was deleted from the program because:
- The added cost of vision did not significantly improve stopped object performance over radar-only algorithm with improved radar-processing; and
- The FCW subsystem passed all 12 verification tests without the vision system integrated.
The trade-off study for implementing a false alarm database (FADB) was completed. There was no data to support that an FADB is required for FCW so it was deleted from the program.

Planned activities for FCW for Phase II development include:

Extending the stop object detection range to a minimum of 60 meters;
Improving lead-vehicle stopped in a curve performance; and
Optimizing subsystem reaction to cut-ins.

3.4.2.2. Lateral Drift Warning (LDW) Progress and Accomplishments

3.4.2.2.1.Subsystem Overview

LDW is the only function addressed by the same technology solution across both light-vehicle and heavy-truck platforms (the SafeTRAC-2 lane-tracking system from Cognex). This cross-platform approach allows advances made for one vehicle platform to be quickly and synergistically employed by the other, and makes some activities common across the two platforms logistically more tractable (i.e., integration and validation testing).

3.4.2.2.2. Concept of Operation

The core sensor of the LDW subsystem is the forward-looking camera, which tracks lane boundaries of the road segment on which the subject vehicle is traveling. Information about the lane boundary positions and motion over time is used to estimate the subject vehicle’s lateral position and velocity relative to the lane. This trajectory information is used to assess the threat of unintentionally drifting off the road, and, if the threat is high enough, to warn the driver of the danger. For more details on the core operation of the LDW subsystem, see the IVBSS First Annual Report .³⁰

Challenges of the LDW function include ambiguity about the driver’s intentions and imprecision in the driver’s lateral control of the vehicle. The latter is particularly significant in heavy trucks where there is little more than a foot of distance between the tire and the lane boundary, even when the vehicle is centered in the lane. However, the greatest of all challenges for LDW is consistently tracking the lane in the wide range of weather, lighting, and road conditions encountered by drivers in the real world.

Efforts in the second year of the IVBSS program have focused on LDW subsystem improvements to address these challenges and on testing to validate them.

3.4.2.2.3. Hardware

A major effort during the second year of the program has been to transition to a newer, more capable LDW hardware module, SafeTRAC-2. This module combines the camera and processor into a single, windshield-mounted unit (Figure 14). Advantages of this hardware design relative to that employed in the Road Departure Crash Warning Field Operational Test Program include:^{19 20}

Small footprint: Approximately that of a typical electronic toll transponder;
CMOS imager: Higher resolution and greater dynamic range than CCD;
Native CAN bus support: Cross-platform (light vehicle and heavy truck) support; and
Powerful DSP processor: Better lane-tracking performance.

Figure 14. New Safe TRAC-2 LDW system

Figure 14. New Safe TRAC-2 LDW system

Incorporating the new LDW hardware into the IVBSS hardware and software architecture has been a significant challenge during the second year, but the results provide a stable and capable platform for lane tracking information and lateral drift warning.

3.4.2.2.4. Software

The LDW software builds on the successful LDW system fielded in the road departure crash warning field operational test program. One primary lesson that was learned from RDCW was that the LDW subsystem must maximize availability without an unacceptable rate of false alarms. During the second year of the IVBSS program, researchers completed a three-pronged strategy to meet the challenge of maximizing LDW while avoiding false alarms:

Improved camera control and image acquisition software to take advantage of the new CMOS imager’s capabilities to handle extreme, rapidly changing lighting conditions;
Improved image-processing algorithms that are accurate about when to warn; and
Improved false and nuisance alarm management to allow for accuracy in when not to warn.

The steps to implement this three-pronged strategy are described in section 3.4.2.2.6.

3.4.2.2.5. Interaction with Other Subsystems

LDW will have three types of interactions with the other IVBSS subsystems. These three main types of interactions and examples of each are listed below:
1. LDW will use information from the other subsystems to improve LDW performance.
2. If the LCM subsystem detects a nearby object in an adjacent lane, the LDW warning threshold will be adjusted to warn earlier.
3. LDW adjusts the warning threshold while traversing a curve based on the refined curvature calculation from FCW.
4. LDW also uses the refined curvature to better track the lane boundaries (better predictor of where to look in the field of view).
5. LDW uses the distance to target from FCW. If the headway is very small, LDW disables the system because too much of the field of view is occluded and becomes unreliable.
6. LDW uses road class from CSW map data to determine the appropriate default AMR value and to potentially adjust the AMR value being reported by LCM.
LDW calculates and sends information to the other subsystems so that they can improve their performance:
1. Time to warning.
2. Boundary type.
3. Vehicle position and lane-change information will be posted by LDW.

3.4.2.2.6. Development Activity

The new CMOS imager in SafeTRAC-2 can image both the bright and dark parts of the scene better than the CCD imager used in RDCW. This, coupled with improved algorithms for coping with extreme lighting, has helped ensure that the LDW subsystem availability is higher and the false alarm rate is lower relative to RDCW. Other important LDW-related software developments during the second year of the IVBSS program included:

Developing and testing the LDW subsystem CAN message set;
Incorporating yaw rate sensor input for improved curve tracking performance;
Implementing a low-headway disable function to avoid false LDW alerts during tailgating episodes (e.g., after a cut in);
Developing algorithms to detect and compensate for adverse weather conditions; and
Developing a false-alarm detection and suppression feature, based on analysis of driver response (or lack thereof) to recent warnings.

During the second year of the program, the new LDW hardware and software was tested, first in isolation and then as part of the integrated IVBSS system. Tests were conducted on the road and in carefully orchestrated and instrumented track tests to verify performance.

For Phase II, the warning onset timing will be refined if necessary based on feedback from subjects during the extended pilot testing. Furthermore, the false alarm suppression algorithm will be activated. The algorithm detects what are likely to have been false or nuisance alerts based on the driver’s steering behavior, and suppresses subsequent, similar alerts for a short period of time. The algorithm is fully developed, but it was disabled during LDW testing because the developer elicits multiple intentional alerts within a short time span, which might otherwise trigger the false alarm suppression algorithm and interfere with testing.

3.4.2.3. Lane-Change/Merge (LCM) Progress and Accomplishments

3.4.2.3.1. Subsystem Overview

The lane-change/merge (LCM) subsystem addresses side-collision scenarios involving lane-change maneuvering of the subject vehicle or merging by the subject vehicle into an occupied lane. Side-looking radar is used to identify potential hazards in an adjacent zone extending from just in front of, to substantially rearward of, the subject vehicle. A crash alert is generated when a collision hazard exists in the adjacent zone, due to the lateral motion of the subject vehicle. Advisory information is provided by illuminating icons on the side mirrors when a same-direction moving vehicle is detected in, or may be moving into, the blind-spot zone.

3.4.2.3.2. Concept of Operations

Three basic functions comprise the LCM subsystem: (1) warning the driver of side-collision hazards due to subject vehicle lane-changes or merging, (2) informing the driver of same-direction traffic in adjacent lanes (within a blind-spot zone), and (3) providing lateral available maneuvering room (AMR) for use by other subsystems. Three short-range radar sensors are positioned on each side of the subject vehicle, providing obstacle data. The data is used to create an awareness of obstacles in the adjacent proximity zones that extend from 0.5 to 3 meters laterally from the side of the subject vehicle and run from approximately 3 meters forward of the front bumper to 18 meters rearward of the back bumper.

The blind-spot zone is a subset of the adjacent proximity zone that represents the area of the adjacent lane that is difficult for the driver to see, both directly by turning the head and indirectly via the side mirror. The blind-spot zone extends from 0.5 to 3 meters laterally from the side of the subject vehicle and runs from approximately the B pillar to 3 meters rearward of the back bumper.

The AMR function delivers a pair of outputs that quantify the available lateral distance from the subject vehicle to detected objects in the adjacent path or adjacent lane. The goal of this function is to optimize IVBSS warnings and improve the performance that standalone IVBSS features can provide. AMR will enable IVBSS systems to respond to environment factors beyond the detection capabilities of any single system.

3.4.2.3.3. Hardware

LCM algorithms will be housed in a cRIO module as previously described. Radar sensor data will be processed using three radar processing units (RPUs), which will communicate with the cRIO module on a dedicated high-speed CAN bus (LCM CAN). Each RPU module will process the radar data and transmit the target information to the LCM as input to the LCM threat assessment module. The software model used is a modification of the already-developed Visteon blind-spotdetection algorithms and applications, which saved a significant amount of time to the overall LCM development time.

For the IVBSS program, vision was considered to provide improved azimuth information and target characterization information to enhance LCM threat assessment. During the second year of the program, it was determined that LCM would fully meet verification testing criteria without vision. Furthermore, the packaging for the side vision modules was incomplete. Significant effort was required to resolve water intrusion issues. Hence, side vision was deleted from the program.

3.4.2.3.4. Software

There are six basic software functions for LCM:

Available maneuvering room estimation;
Blind spot detection;
Closing vehicle detection;
Merge detection;
LCM false alarm management; and
Threat assessment.

3.4.2.3.5. Interaction with Other Subsystems

The LCM subsystem generates three outputs important to the IVBSS system. The primary function of the LCM subsystem is to warn drivers of lane-change and merge hazardous situations. The LCM subsystem supplies information on impending hazards to the arbitration subsystem. The arbitration subsystem is responsible for ensuring that IVBSS presents the most useful and timely warning to the driver, since multiple situations may occur simultaneously. Another function of LCM is to provide AMR to other subsystems. LCM also uses data provided by LDW to modulate warning onset. Specifically, LCM will consider position in lane and LDW warning information when assessing the threat.

3.4.2.3.6. Development Activity

During the second year of the IVBSS program, the LCM algorithms were developed and installed on the IVBSS development vehicles. The following were accomplished:

Radar sensor fusion: Now objects are tracked and passed to the next sensor as they move from one detection zone to the next;
First application of the 40ms sensor rate: Achieves 27-meter range;
AMR: Available maneuvering room is reported instantaneously and predicatively;
Simulation for radar signal processing: Radar sensor data can be collected during development drives and played back on the desktop for offline processing and analysis;
Enhanced LCM warning algorithm: TTC calculation coupled with driver intent;
System calibration: Refined alert timing to reduce nuisance alarms for overtaking vehicles, etc.; and
Side vision: Algorithm fully developed by Visteon, but deleted from program as
described above.

For Phase II, additional development is planned for LCM:

Refine system calibration for overtaking vehicles to further reduce false alarms
Migrate to production-level blind spot monitoring algorithms (minor revisions)

3.4.2.4. Curve Speed Warning (CSW) Progress and Accomplishments

3.4.2.4.1. Subsystem Overview

The CSW subsystem will extract data from the digital map and use lane tracking and detection information from the LDW module to assess the threat of losing control of the vehicle in an upcoming curve.

3.4.2.4.2. Concept of Operations

The CSW system warns the driver when the vehicle is traveling too fast for an upcoming curve. The objective of this system is to warn the driver early enough to avoid possible road departure at some point in the curve. CSW system design attempts to address curves in both single and branching road geometries. In all of these road scenarios, the CSW will issue a warning if the driver exceeds the desired system-designated speed for the curve. CSW will not warn drivers for turns and intersections; it will also not warn for speeds less than the IVBSS-enabling speed.

The basic CSW system is navigation-based, using the navigation system to place the vehicle position on the map. It then uses the CSW algorithm to look ahead on the map, extract all possible driving path candidates, determine the intended driving path, performs a curvature calculation on the geometric data of this path, and finally perform a threat assessment based on vehicle speed and the road curvature ahead.

The intended driving path determination is achieved by designing a look-ahead module (LAM) that looks forward from the vehicle position to the look-ahead distance. The LAM determines the most probable path of the vehicle using information from vehicle positioning, lane information (provided by vision), lateral velocity, and vehicle signals and state.

The IVBSS CSW design will have a special module to manage false alarms, which will attempt to detect some of the map database errors to suppress possible false alarms. It is also intended to build a false alarm database to mask some of the repeatable false alarms.

3.4.2.4.3. Hardware

During the second year of the IVBSS program, the CSW algorithms were ported from the Prolificx TrakPod to the IVXP navigation platform with SDAL 1.7. The IVXP runs the Windows CE 5.0 operating system and allows system integrators and software developers to implement custom software solutions. The CSW module communicates with the IVBSS system through an RS-232 serial connection to the FAD module, and has an external GPS antenna.

3.4.2.4.4. Software

There are six software modules:

Vehicle positioning system: Locates the vehicle on the map;
Look-ahead module: Extracts all possible road candidates;
Most-likely-path (MLP) calculation: Determines most likely path of the subject vehicle;
Curvature calculation: Calculates the curvature of the MLP;
Threat assessment: Assesses threat based on road geometry and subject vehicle data; and
CSW and FCW false alarm database management: Manages false alarms to reduce the nuisance alarm rate.

3.4.2.4.5. Interaction with Other Subsystems

The CSW subsystem provides the GPS latitude and longitude information to all other subsystems and will provide the road geometry and road attributes to the other subsystems. It uses lane boundary type from LDW as an input for the most-likely-path calculation.

3.4.2.4.6. Development Activity

The CSW algorithm is based on the road departure crash warning system developed for the field operational test deployment. Analysis of the RDCW data, both objective and subjective, revealed several areas of improvement for CSW that would significantly reduce the false alarm and nuisance alert rate. The improvements were incorporated into an enhanced algorithm and ported to new CSW hardware. The CSW subsystem is currently up and running on a test vehicle. During the second year of the IVBSS program, the CSW algorithm was tested in-vehicle with a fully equipped IVBSS system. Several improvements to the system were achieved:

Expanded map coverage to contiguous United States (RDCW was for a limited area of Michigan and parts of adjoining States);
Improved dead reckoning algorithms;
Improved map matching algorithms; and
Developed and integrated the false alarm database (FADB) to reduce the frequency of false alarms due to map errors.

For Phase II, the CSW system calibration will be tuned based on extended pilot results. Also, the FADB will be fully populated for the FOT deployment.

3.4.2.5. Arbitration Progress and Accomplishments

3.4.2.5.1. Subsystem Overview

The arbitration process is unique to IVBSS, a feature not found in standalone crash warning installations. Arbitration is necessary to manage the amount of information conveyed to a driver at any given time. Each subsystem is responsible for its own threat assessment and uses synergistic information from other subsystems to make its own treat assessment more robust and valuable. Arbitration continually monitors all subsystems to manage the DVI resources when multiple requests for DVI resources are likely to occur at, or very near, the same time.

3.4.2.6. Concept of Operations

Threats develop or build over time, and arbitration monitors the subsystem looking for conflicts to be developing between subsystems, primarily lateral (to the side) or longitudinal (forward) threats. Until such time that conflicts between subsystems arise, arbitration passes DVI requests directly to the DVI subsystem. Once a conflict is identified, the arbitration subsystem determines the best warning to send to the driver. Arbitration is the only subsystem that can request the DVI subsystem to present a warning to the driver. To avoid conflicting warnings, arbitration must select a single warning to present at any given time, or present no warning at all if the driver is fully engaged in driving.

3.4.2.6.1. Hardware

For Phase I development, the arbitration algorithm will be run in the FAD module. For Phase II FOT deployments, the algorithm will migrate with the DVI algorithm to a single cRIO.

3.4.2.6.2. Software

During the second year of IVBSS, the arbitration software went through a significant transformation. A rule-based arbitration strategy was developed for multiple threat scenarios:

Do not repeat warnings within 3 seconds (15 seconds for CSW);
Give competing warnings immediately after first warning is complete (710 ms);
Ignore lower priority warnings; and
Give a maximum of two warnings for any given multiple-threat scenario.

For a warning to be competing, it must not be of the same direction as the original warning. For example, if a warning request is received from FCW and, within three seconds, a warning request is received from CSW, the CSW warning request is disregarded. The IVBSS system has already warned the driver of a forward hazard and to alert a second time would be redundant and potentially distracting. This is also true for LCM and LDW imminent warnings. However, if the warning requests were in different directions, the second request would be given, for example if an FCW warning was requested (forward threat) and delivered and then an LCM left warning was requested (side threat). The second warning (LCM left) would be given either immediately or when the original warning expired. Furthermore, LDW cautionary warnings have the lowest priority and will always be disregarded in a multiple threat scenario.

The above holds true for warnings that are requested within three seconds of one another. In the rare instance that warnings are requested simultaneously, the following forced ranking (highest to lowest) is achieved through the CAN protocol by giving the highest priority messages a lower ID; first FCW, followed by CSW, then LCM, and finally LDW.

3.4.2.6.3. Interaction With Other Subsystems

Each of the four warning subsystems (FCW, CSW, LDW, and LCM) will transmit a warning request to arbitration. Arbitration will, in turn, select the highest priority warning to be presented to the driver. Arbitration is the only subsystem to request the DVI subsystem to generate a warning.

3.4.2.6.4. Development Activity

During the second year of IVBSS, a significant amount of effort was expended developing the priority of warning requests. The warning requests were mapped to crash severity and occurrence data. The warnings were then separated into competing and non-competing warnings. If a warning is issued and a non-competing warning is requested within 3 seconds of the original warning, it is suppressed. If a warning is issued and a competing warning is requested within 3 seconds of the original warning, it is delayed until the first warning is finished (approximately 700 ms).

The initial version of the arbitration algorithm was installed in IVBSS for the jury drives. The algorithm was further enhanced based on in-vehicle development and results of the jury drives. The final version was installed on the development vehicles for the accompanied pilot testing and was verified at the track during Phase I verification testing. There are no planned changes or enhancements to the arbitration algorithm in Phase II.

3.4.3 Phase I Activities and Schedule

Phase I concludes in April 2008. All functional subsystem development activities will have been completed according to the overall schedule shown in Figure 15.

Figure 15. Light-vehicle schedule for subsystem development

Figure 15. Light-vehicle schedule for subsystem development

3.5 Development of Driver-Vehicle Interface

During the second year of the IVBSS program, the DVI warnings were formulated and tested. Results from the simulator studies, jury drives, and accompanied pilot testing were incorporated into the design. The finalized specification of the modality of crash alerts and advisories was developed as shown in Tables 2 and 3.

Table 2. Crash vehicle alerts for the light-vehicle platform

Table 2. Crash vehicle alerts for the light-vehicle platform

Table 3. Advisories for the light-vehicle platform

Type of Information	Advisories (Visual Only)
Forward object – Potential threat	Forward target detected (optional)
Forward roadway curve	Information regarding upcoming curve (optional)
Side object – Potential threat	Indicator or icon when vehicle in side-object zone (optional)

To host these capabilities, the light-vehicle FAD module houses the FCW, arbitration, and DVI modules. FAD consists of a National Instruments PXI controller with two compact reconfigurable input-output modules (cRIOs) and will be used for development. The DVI will migrate to the cRIO-embedded target (shared with arbitration) for the IVBSS FOT vehicle.

The DVI module interfaces are shown in Figure 16, and include interfaces for accepting driver inputs, providing IVBSS driver information (visual, audible, and haptic), and exchanging data with other subsystems and the vehicle through a project CAN bus. Two visual cues will be provided (as shown in Figure 17): (1) an OEM text and icon display on the center stack above the audio system and HVAC controls, and (2) icons on both side-view mirrors. Audible cues will be delivered through the driver headrest speakers, with right-left directionality. Haptic cues can be provided in the driver seat pan (with right-left directional capabilities) and through brake pulses.

Figure 16. Driver-vehicle interface block diagram

Figure 16. Driver-vehicle interface block diagram

Figure 17. Visual display (left) and blind spot detection icons installed in the Honda Accord

Figure 17. Visual display (left) and blind spot detection icons installed in the Honda Accord

Driver inputs that have been implemented in the final DVI design as shown in Figure 18:

Driver audio volume control (for headrest speakers); and
Driver temporary IVBSS mute button (to suppress unwanted alerts for a brief period).

The driver inputs are located on the driver’s side left knee bolster, next to the steering wheel and are shown below in Figure 18.

Figure 18. IVBSS mute button (right) and volume control switch (second from right)

Figure 18. IVBSS mute button (right) and volume control switch (second from right)

The light-vehicle development vehicles were built with all of the hardware described in the IVBSS First Annual Report .³⁰

3.5.1 Development Activity

During the second year of the IVBSS program, the DVI option space was finalized. Specifically, during this period, researchers:

Conducted jury drives (stage 1 testing);
Conducted accompanied pilot (stage 2 testing);
Completed simulation testing;
Changed the haptic brake pulse to a two-stage approach to reduce variability. The first stage pre-charges the brakes and the second stage delivers the full brake pulse;
Developed audible, haptic, and visual warning cues as shown in Table;
Optimized system latency to reduce delay between warning requests and when the
warning is presented to the driver;
Implemented a mute function; and
Designed, tested, and implemented the volume adjustment settings.

For Phase II, the DVI will be optimized for the extended pilot.

3.6 System Integration, Build of Prototype Vehicles, and Verification Testing

This task addresses installing IVBSS on a fleet of development and FOT vehicles.

3.6.1 Overview

The 2006 Accord EX is the vehicle platform for the IVBSS development program. The 2007 model will be the vehicle platform for the IVBSS FOT fleet. Phase I includes the integration of IVBSS on six development vehicles; four of these will be converted into FOT vehicles during Phase II. Phase II will involve installing the IVBSS system on an additional 12 FOT vehicles.

3.6.2 Light-Vehicle Prototype Build Plan

The buildup of the first three development vehicles was started in the first year of the IVBSS program. These vehicles and the remaining three vehicles were completed by May 2007. The IVBSS system is complex, requiring over 35 components to be designed and installed, not including the hardware required to mount the components to the vehicle or the power distribution hardware. Figure 19 shows the overall integration plan for the IVBSS system. The items to be installed were introduced in earlier sections of this report.

The majority of the IVBSS components are trunk-mounted. A special trunk rack has been designed that houses the various IVBSS components. The rack is on a track (Figure 20) and can move toward the rear of the trunk to provide easy access to the components during development. Components will be inaccessible to the FOT participants, with a false back made to bar any access from the trunk. The access panel in the back seat will be permanently locked. For development, however, the access panel will provide CAN drops for all of the CAN busses.

Figure 19. IVBSS Module, sensor, and camera palcement in vehicle

Figure 19. IVBSS Module, sensor, and camera palcement in vehicle

Figure 20. Trunk rack system

Figure 20. Trunk rack system

3.6.2.1. FCW Subsystem

The FCW algorithm runs on the FAD module, which is trunk-mounted. The yaw rate sensor will also be mounted in the trunk. The forward radar will be mounted behind the front fascia. The long-range FCW camera was mounted on the windshield, behind the rearview mirror. The FCW vision module also was trunk-mounted. The FCW vision hardware will be removed for the FOT fleet builds, since it was deleted from the program as described previously.

3.6.2.2. LDW Subsystem

The original LDW module was mounted in the trunk, while the short-range LDW camera was mounted on the windshield, behind the rearview mirror. The new LDW module (SafeTRAC-2) has an integrated CMOS camera and LDW module combined into a single package and mounted behind the rearview mirror.

3.6.2.3. LCM Subsystem

Figure 21 shows the short-range radar sensors for the LCM subsystem in the vehicle-installed position. LCM algorithms are running on a separate cRIO module, which is installed in the trunk. The three RDU modules that interface with the radar sensors are also installed in the trunk. The side vision system was installed on one vehicle for development, but was later deleted from the program as described previously.

Figure 21. LCM short-range radar sensors

Figure 21. LCM short-range radar sensors

3.6.2.4. CSW Subsystem

The CSW module and associated components are trunk-mounted.

3.6.2.5. Phase II Planned Activities

For Phase II, several integration tasks remain:

Select material for and design new grille cover for LR radar sensor (see Figure 22);
Package DAS peripherals (cabin cameras, side cameras, etc.);
Increase trunk space by reducing the size of the trunk-rack; and
Improve trunk cooling.

Figure 22. FCW radar sensor

Figure 22. FCW radar sensor

3.6.3 Second Year Activities and Schedule

All six IVBSS development vehicles were completed in the second year.

Figure 23. Schedule for light-vehicle system integration and protoytpe building

Figure 23. Schedule for light-vehicle system integration and protoytpe building

4 Heavy-Truck Platform

The heavy-truck platform team is comprised of partners from UMTRI, Eaton Corporation, Cognex Corporation, and Battelle Memorial Institute. The team is integrating forward collision warning, lane-change/merge warning, and lateral drift warning systems into an integrated safety system on a class 8 tractor for field operational test deployment. Key results from the first phase include not only technical accomplishments for the integrated suite of sensors and the integrated system of warning functions and interface, but also team dynamics alignment to better serve the mission and the U.S. DOT.

This section documents the Phase I progress on the IVBSS heavy-truck platform. Details are provided for the major elements of the effort, including functional requirements and system architecture, system design and integration, performance guidelines, subsystem and sensor suite details, driver-vehicle interface development, and prototype vehicle builds and development.

4.1 Functional Requirements and System Architecture

The functional requirements and system architecture (Task 1.b) were developed during Phase I. Figure 24 shows the heavy-truck Phase I systems engineering process. The process shown is slightly different from that followed by the light-vehicle team. The heavy-truck team first considered the crash problem and developed an extensive list of crash scenarios and operational scenarios, along with parameters to populate examples of those scenarios. The scenarios were used to directly develop functional requirements, without the use of the system functional model employed by the light-vehicle team. The remainder of the process is similar to that described in section 3.1.2. A preliminary functional requirements report for the heavy-truck platform was delivered and posted for public access.¹³

Figure 24. Systems engineering process for heavy-truck platform

Figure 24. Systems engineering process for heavy-truck platform

This process has considered collision warning technologies that have been incorporated and investigated under earlier major U.S. DOT programs, such as lane-change/merge systems, road departure systems, and forward collision warning systems.^{4 5 16 1719 20 24 25 26}The process has also considered Eaton’s current and planned commercial truck collision warning products that are based on many years of experience and feedback from customers including both fleet managers and drivers. The following sections describe some of the key results of the functional requirements and system architecture efforts.

4.1.1 Overview

IVBSS provides information to assist the driver in avoiding or reducing the severity of the following four crash types:

Rear-end crashes where the subject vehicle strikes the rear of a primary other vehicle;
Road-departure crashes where the driver of the subject vehicle allows the unintentional lateral drift of that vehicle, ultimately taking the vehicle off the road;
Lane-change/merge crashes where: (1) the subject vehicle intentionally changes lanes and collides with a vehicle that had been moving in the same direction, or (2) the subject vehicle intentionally merges into traffic and collides with a same-direction vehicle; and
Crashes that involve two or more of the above pre-crash conditions.

Information about the driver’s situation is provided in two forms, crash alerts, and crash advisories. The timing of crash alerts is intended to allow drivers who are unaware of the potential approaching threat to have enough time to react, assess the situation, and decide whether to initiate and complete an evasive maneuver that avoids (or greatly reduces the severity of) a crash. In an integrated system, it is important to address multiple crash scenarios and manage the timing and presentation of that information in a manner that reduces both driver confusion and perception of nuisance.

Overall, it is recognized that an aware driver remains the best decision maker about whether, and how, to conduct such maneuvers. The IVBSS system will not provide automatic control of the vehicle and will not prohibit other systems that do employ active control of the vehicle. Other constraints stated in section 3.1.2 also hold for the heavy-truck platform.

4.1.2 Functional Requirements

The preliminary functional requirements document, developed by the heavy-truck team, has been updated and improved during Phase I.¹³To focus the requirements development process, initial activity involved a critical identification and rationalization of the scenarios involved. This involved identifying possible pre-crash and nuisance-alert scenarios and attaching to each scenario a set of attributes to assist with requirements development and validation. Most scenarios were drawn from earlier programs referenced above. Early assessment matrices for this task segmented the scenario space by crash type, crash statistics, kinematic properties, warning options, likely driver behavior, and potential commercial viability. By analyzing a set of scenarios, it was possible to consider the various functionalities and operating conditions and generate functional requirements and the system architecture.

The final functional requirements document was released at the end of Phase I and includes advances made in driver-vehicle interface requirements, arbitration, and the measurement of multiple-threat scenarios. The heavy-truck version is very similar to the light-vehicle platform version and includes the same type of requirements as discussed in section 3.1.2.

The heavy-truck and light-vehicle teams worked separately on the requirements, but discussed differences between the respective results; examples of these differing requirements include:

The heavy-truck platform includes a requirement for alerts based on smaller headway times, while the light-vehicle platform does not include such headway-based crash alerts. This is because the braking capabilities of heavy trucks cannot always compensate for sudden decelerations by passenger vehicles if the headway is small; appropriate headways thus provide a safety margin. Conversely, a passenger vehicle is assumed to have braking capability comparable to almost any deceleration capability a preceding vehicle may have.
More consideration of nuisance alerts is necessary for light-vehicle systems, since typical operating environments and driving styles may lead to more nuisance scenarios with customers who are less tolerant of them. Heavy-truck operations typically include more freeway exposure than that seen in the light-vehicle fleet, and while decisions to acquire safety technology are almost entirely economically based for heavy trucks, the light-vehicle market includes a major element of driver preference. Furthermore, light vehicles engage in more lane changes, passing maneuvers, and turns per mile of exposure than do heavy vehicles, which increases the chances of inducing unwanted nuisance alerts.

4.1.3 System Architecture

The heavy-truck IVBSS was partitioned into major subsystems and their supporting sensors and software, with a definition of the interfaces and communications between the subsystems. The sensor suite for the heavy-truck IVBSS function consists of multiple vision, radar, inertial, and vehicle sensors that are mostly commercially available, off-the-shelf sensors. These are depicted in Figure 25. The system will also use sensory information from the vehicle CAN bus, such as vehicle speed and brake and vehicle status indicators. In addition to the IVBSS sensors, the data acquisition system will use supplemental sensors for FOT data collection and analysis purposes.

Figure 25. Heavy-truck sensor suite overview (not to scale)

Figure 25. Heavy-truck sensor suite overview (not to scale)

Table 4 summarizes the major sensor elements and identifies those that play primary and supporting roles for the warning functionalities. As highlighted in Table 4, the original sensor suite (as described in the IVBSS First Annual Report ) included long-range rear-looking cameras that are not part of the final design.³⁰While providing complementary side sensing for LDW and LCM functionality, these cameras were not critical and were omitted from the final design primarily for structural robustness issues. The primary sensing for the three subsystems remains unchanged. Forward collision warning uses two forward-looking radar units, lane departure warning uses a single forward-looking camera, and lane-change/merge warning employs a fusion of rear-looking radar, and side radar:

Short-range forward-looking camera: Mounted near the top center of the windshield. The camera and dedicated video processing hardware are based on the next-generation Cognex SafeTRAC lane-tracking hardware. The azimuth field-of-view of the CMOS camera is 44 degrees and the imaging field is up to about 25 meters ahead of the subject vehicle;
Short-range side-radar: Eaton (BackSpotter) 5.8-GHz radar units, two mounted on the left side of the tractor and two on the right. The radar units detect the presence of objects adjacent to the subject vehicle at a maximum detection range of at least 4 meters and an azimuth field-of-view of 100 degrees;
Forward radar: Two TRW AC20 forward-looking 77-GHz radar units mounted near the tractor headlights estimate range, range rate, and azimuth of multiple objects ahead of the subject vehicle at a maximum detection range of at least 150 meters and an azimuth field-of-view of 11 degrees. It provides dedicated onboard target tracking and FCW warning software;
Rear-facing radar: Two M/A COM C3 SLR rear-looking 24-GHz radar units mounted near the tractor side mirrors estimate range, range rate, and azimuth of multiple objects adjacent to the subject vehicle at a maximum detection range of at least 30 meters and an azimuth field-of-view of 40 degrees. The units provide dedicated, onboard target tracking;
GPS sensor: A GPS sensor determines the position of the subject vehicle. Positional information is used in conjunction with a digital map to provide information related to false alarms, roadside objects, and roadway geometry; and
Inertial sensors: A yaw rate sensor estimates the yaw angle and rate relative to the
longitudinal travel of the subject vehicle. A tri-axial accelerometer estimates the
acceleration of the vehicle along three axes.

Table 4. Heavy-truck IVBSS sensor suite versus warning function

Sensor	Original Design	Final Design	LDW Sensors	FCW Sensors	LCM Sensors
Forward radar	X	X		X*
Side radar	X	X	X (AMR)		X*
Rear radar	X	X	X (AMR)		X*
Short-range forward vision	X	X	X*		X
Long-range rear vision	X		X (AMR)		X
Vehicle yaw rate	X	X	X	X	X
Vehicle XYZ acceleration	X	X	X	X	X
Vehicle data (speed, brake, turn, wipers, headlights)	X	X	X	X	X
GPS/digital database	X	X		X	X

* = Primary sensor

This sensor suite has been installed on the engineering development truck, a class 8 International tractor (also known as the “bronze truck”), and represents a tractor-only solution for sensing. The tractor-only sensor configuration is important for the project and for realistic commercial viability. For a typical fleet operation, there may be three or more trailers out in the field for any given tractor. Furthermore, those trailers will tend to not be “married” to a given tractor. This simplification of architecture has greatly simplified the execution and management of the FOT in Phase II. Additionally, this system architecture has been finalized and implemented on the bronze truck, allowing it to capture datasets for playback and algorithm development and refinement.

The schematic diagram of the heavy-truck IVBSS system hardware architecture is shown in Figure 26. The architecture is based on a four-CAN bus communication infrastructure that facilitates sharing of all sensor data and subsystem module information. The four CAN buses are: (1) the camera/side radar/DVI bus (CAN 1); (2) the J1939 vehicle CAN bus; (3) the forward radar data bus (CAN 2); and (4) the rear radar data bus (CAN 3).

As depicted in Figure 26, the two rear-facing radar units (M/A-COM C3 SLR) and the two forward-facing radar units (AC20) each have their own dedicated bus due to the relatively large amount of data provided by the radar sensors.

The LDW module used in the early development of Phase I essentially consisted of the commercial Cognex SafeTRAC product. The forward camera was a CCD camera and external to the LDW module. The final LDW design uses the next-generation hardware (SafeTRAC-2) employing a CMOS camera that is internal to the LDW module. The final LDW module also has a native CAN I/O interface that was not part of the original design. The camera data is provided on a private CAN bus and contains LDW warning information, lane information, and information relative to the presence of vehicles or obstacles next to the subject vehicle; it will not include raw video data.

Figure 26. Schematic diagram of the system hardware architecture

Figure 26. Schematic diagram of the system hardware architecture

The CAN concentrator module is a custom-designed hardware unit used to collect and translate the side-facing proximity radar sensor data, the DVI enable signal from the DAS, and vehicle data (not provided on the vehicle bus) onto the private CAN bus 1. The concentrator module also translates DVI output messages from the CAN bus 1 to the side displays. As indicated in Figure , the primary forward display (driver interface unit), will communicate directly on CAN bus 1.

The GPS module is a custom-designed hardware unit using low-cost, commercially available GPS, yaw rate, and tri-axial accelerometer sensors. It will interface to CAN bus 1 and be located toward the roof of the tractor cab for optimal GPS signal reception.

The fusion engine interfaces with all four system buses. It is the primary hardware component and executes the majority of the IVBSS fusion, warning, and arbitration algorithms. The fusion engine is based on a PC-104 stack and uses the rapid prototyping tools from Mathworks to rapidly transition from software and simulation development to real-time testing on board the experimental and prototype vehicles.

With the exception of the LDW-related algorithms, the heavy-truck software takes the form of a centralized software architecture, where the majority of the software is executed on the main PC104-based processor, the fusion engine. Most of the sensor hardware modules, however, have their own resident signal processing and conditioning software that preprocesses or extracts information from the sensor data before transmission to the fusion engine. For example, all vision processing algorithms will be executed on the LDW camera module. The radar sensors will also perform preliminary radar signal processing, data association, target tracking, and first-stage warning algorithms using onboard processing capabilities.

Currently, the software architecture is composed of the following components: (1) a lateral-drift warning SW module that provides lane detection and tracking, false alarm management, and threat assessment; (2) a forward-radar SW module that provides scene tracking, primary target determination, and threat assessment; (3) a rear-radar SW module that provides scene tracking adjacent to the subject vehicle; and (4) the fusion engine SW module that provides radar filtering and fusion, host state estimation, LCM threat assessment, available maneuvering room estimation, warning based arbitration, system threat assessment, digital database management (for false alarms, roadside obstacles, and other roadway information), system management, diagnostics, and I/O signal conditioning.

4.1.4 Phase I Activities and Schedule

The functional requirements and system architecture documents were released at the end of Phase I.

Figure 27. Heavy-truck schedule for functional requirements and system architecture

Figure 27. Heavy-truck schedule for functional requirements and system architecture

4.2 System Design, Development, and Integration

Plans for the design and vehicle builds, along with verification testing within the integration effort, were completed in the first year. System design, development (including subsystem development and check-out), and integration (with subsystem and data fusion) activities were completed in the second year, resulting in the two engineering prototype vehicles (the Chevrolet Suburban SUV or “mule vehicle” and the bronze class 8 tractor) that are being used in system verification and concept testing.

4.2.1 Overview

The work plan governing the design, development, and integration approach and methodology for the creation of the IVBSS system proposed in the first year was followed in the second year. The work completed includes the hardware and software combination that provides warning functions, arbitration, and the DVI, as well as the vehicle builds for Phase I; the simulation, bench-test, and extensive road testing and development activities used for algorithm development were also completed (see Table 5). Using simulation and bench-test environments in concert with the actual vehicle test mules and prototype platforms, the team quickly investigated and refined ideas through the review of a portfolio of data playback libraries, analysis of performance, and the monitoring of improvement on key system parameters. Figure 28 displays a high-level overview of the heavy-truck design, development, and integration process followed during Phase I.

Table 5. Support vehicles for mule activity and prototype use in Phase I

Vehicle	Function
Suburban “mule” truck	Permits non-CDL engineers to acquire data and validate system design
Class 8 “bronze” truck	Primary engineering truck test platform and vehicle used for all verification testing
Class 8 “gold” truck	Clean prototype truck as specified in the RFQ with production quality “fit and finish” to be the prototype design for all FOT truck builds

4.2.2 Design

A systems engineering approach was used to subdivide the heavy-truck system into relevant subsystems. This uses a top-down process, and, subsequent to the design and development of the subsystems, a bottom-up approach to combine the subsystems into a fully functioning and integrated system ready for verification and testing. The design process was guided by the functional requirements and system performance guidelines, which form the basis of the design. Much of the earlier work in the separate subsystem technologies and capabilities is being used as the starting point, with integration of those subsystems as a primary focus. The subsystems were also designed to easily combine into one integrated system. The IVBSS First Annual Report contains more information regarding the design effort followed in Phase I.³⁰

4.2.3 Development

The general development process was mentioned previously and documented in the IVBSS First Annual Report .³⁰ On the desktop, simulation and hardware-in-the-loop benchtop tools and methods were used to develop the system software in a structured, controllable, and repeatable environment. This approach will be especially useful to avoid unsafe conditions in on-road tests. On the vehicle, to be used on test tracks and roadways, are the experimental mule and prototype development tools and methods. Throughout Phase I, the rapid prototyping tools and benchtop testing environment proved to be extremely beneficial and expedited all stages of development, from early system development on the Suburban mule vehicle to fine warning refinements based on pilot testing feedback with the bronze truck.

4.2.4 Integration

As the development effort migrated to useable hardware and software that can be implemented first on-bench, then in the Suburban mule, and finally in the bronze and gold tractors, the integration effort also migrated the subsystems from the bench and mule vehicle to the prototype vehicles. Risks in this migration were planned as gaps that were addressed in the course of verification testing and refinement, and through design and development review during the course of the migration.

Figure 28. Overall heavy-truck Phase I development plan flow

Figure 28. Overall heavy-truck Phase I development plan flow

4.3 Development of Performance Guidelines

Figure showed that system performance guidelines were developed from the preliminary requirements. The performance guidelines consist of quantitative and verifiable performance measures for IVBSS system functions in key driving scenarios. The process of deriving guidelines was similar to that described in section 3.3, and included references from previous pubic research programs as well as ISO standards and corporate knowledge from the commercially available Eaton Vorad and Cognex systems. Preliminary system performance guidelines were shared with the public and the final version is now available on the ITS America Web site .

4.3.1 Overview

The heavy-truck team employs a systems engineering process that uses the “voice of the customer” (VOC) process to drive system requirements identification, evaluation, and capture. In this systems engineering process, the VOC for the IVBSS program is represented by the potential known or envisioned pre-crash scenarios, accompanied by associated historical crash statistics to help understand essential priority. Further, U.S. DOT, working with independent technical consultation, has provided a refined set of potential pre-crash scenarios including crash statistics.

The functional requirements document characterizes the system behavior in response to pre-crash scenarios. The goal of the functional requirements is to guide and aid in the development of the integrated system performance guidelines, verification test procedures, and test plans that will implemented during the verification of the prototype vehicle IVBSS systems and used in the development and execution of the FOT. Thus, there is traceability that extends throughout the requirements-capture process, from scenarios through to functional requirements, integrated system performance guidelines, verification test procedures, and verification testing.

4.3.2 Integrated System Performance Guidelines

The performance guidelines report was written in accordance with the functional requirements developed by the IVBSS heavy-truck team based on crash scenarios developed by the Volpe Center, ISO standards (ISO 15623, 2002; ISO 17361, 2005; and ISO 17387, 2006), results from projects such as RDCW and ACAS, and other related publications.^{4 7 8 19 20 28 31} Specifically, this document defines what data must be collected, the accuracy of the data, functions of the algorithms, and necessary system outputs in terms of signals, reliability, consistency, and robustness.

Figure 29. Lateral-drift crash alert timing concepts

Figure 29. Lateral-drift crash alert timing concepts

Figure 30. Forward crash alert timing concepts

Figure 30. Forward crash alert timing concepts

The integrated system performance guideline document defines commonly used terms and performance guidelines, and includes references upon which the performance guidelines were defined. A sample integrated system performance guideline addresses the timing of crash alerts when a vehicle may be drifting from the roadway (Figure 29 illustrates such a scenario). A crash alert may be provided in a zone that encompasses the road edge, but also includes some portion of the lane itself, as well as areas beyond the lane edge. IVBSS must provide crash alerts at some point beyond the lane edge. This is called the “must-inform” zone, as shown in Figure 29. Similarly, Figure 30 illustrates the “must-inform” zone for a forward crash scenario. The guidelines make allowances for suppressing or delaying both types of crash alerts based on measured information that indicates a significant possibility that one or more of the following is true: (1) the driver is aware of the perceived conflict; or (2) the driver intends to initiate a maneuver, or is maneuvering, such that the potential conflict could be resolved through the maneuver. More details are available in the heavy-truck preliminary performance guidelines .¹⁵

4.3.3 Phase I Activities and Schedule

The IVBSS Heavy-Truck Performance Guidelines Report was released at the end of Phase I. It contains refinements based on system development feedback and verification testing.

Figure 31. Heavy-truck schedule for perfromance guideline development

Figure 31. Heavy-truck schedule for perfromance guideline development

4.4 Subsystem Development

This section details the four major subsystems (forward crash warning, lane-change/merge warning, lateral drift warning, and arbitration) and the DVI as they relate to arbitration and development progress; the DVI is discussed in more detail in section 4.5.

4.4.1 Overview

The subsystems on the heavy-truck platform were developed leveraging existing commercial programs and products. However, substantial development efforts were required for both subsystem performance and for integration of the systems into a cohesive system. Development occurred using simulation, on the bench, in the mule vehicle, and with the engineering bronze tractor.

4.4.2 Subsystem Descriptions and Sensor Suite

4.4.2.1. Forward Collision Warning (FCW) Progress and Accomplishments

The forward collision warning capability will provide imminent and cautionary alerts to help drivers avoid striking other vehicles from behind or to reduce the severity of such collisions. The primary sensors of the FCW subsystem are a pair of long-range, forward-looking TRW AC20 77-GHz radar units. Several other sources of information are fused together with the forward-looking radar data to improve the accuracy of in-lane object detection and the proper assessment of the threat posed by the vehicle or obstacle.

The FCW system will use a pair of AC20 radar units mounted near the tractor headlights to provide sufficient detection coverage in front of the vehicle, in particular for close vehicle cut-in scenarios. The mounting location is also ideally suited for detection of small vehicles, such as motorcycles, which typically ride in the tire track lateral lane position to avoid grease and debris that tend to accumulate near the lane center. The sensors have a field-of-view of 11 degrees and an approximate range of 150 meters. The AC20 radar units will communicate radar track data to the fusion engine on their own dedicated CAN bus.

The AC20 radar units are the primary sensors of the FCW subsystem. The unit has onboard processing hardware that will estimate target track data assigned to specific vehicles and objects. A set of evolving parameters is associated with each track: track identification number, relative distance, relative rate (radial velocity), estimated relative acceleration, angular position, and track confidence level. The set of tracks will be managed according to the girth and depth of vehicle tracks (i.e., entry and exit from the radar FOV). Each AC20 can track up to eight vehicles simultaneously at a data rate of 40 ms.

To reduce the amount of data communicated to the fusion engine, each AC20 radar unit will execute its own forward-collision-warning algorithm. Using the vehicle speed and yaw rate information provided to the AC20, the warning algorithm will assess all track information, distinguish between in-path and out-of-path obstacles, and calculate the associated threat level. The FCW-related software executing on the fusion engine will fuse several sources of information, including warning information from each AC20, roadway geometry information, lane boundary information, AMR, and host kinematic state information. The FCW subsystem will use this information to provide an enhanced FCW warning and an associated severity and confidence measure. The FCW-specific software processing executed in the fusion engine consists of two main components: FCW data fusion and FCW threat assessment. The FCW subsystem also uses information provided by two additional processing components: roadway geometry and host state estimation.

The FCW data fusion component merges the forward collision data provided by the two AC20 radar units. The forward collision data includes: FCW threat level, FCW priority and critical target information (track identification number, relative (radial) distance, relative rate (radial velocity), estimated acceleration, and angular position). The critical target is the closest in-path obstacle or vehicle. The FCW warning algorithm executed on each AC20 is based on the relative kinematic parameters of the subject vehicle and critical target developed and refined by Eaton VORAD for the heavy-duty truck market over the last decade.

The FCW threat assessment component provides a final fused FCW warning and an associated severity and confidence measure using information related to the lane boundary type, AMR, position-specific false alarm information, refined road curvature, and the host state. The FCW information is subsequently used by the system-warning arbitrator.

Upcoming roadway geometry or curvature is useful for processing both image data and radar data. The roadway geometry estimation component uses several sources of information for estimating the upcoming road curvature: visually-estimated curvature from the LDW subsystem, vehicle yaw rate, and speed. IVBSS combines information from these sources and generates a refined curvature estimate that is more accurate than any individual curvature. The refined estimate is calculated in the fusion engine and sent to the LDW module to improve LDW, as well as LCM, performance.

Technical progress on forward collision warning includes:

Performance was analyzed and fine-tuned on the AC20 tracking and collision warning algorithms using the bronze engineering class 8 tractor.
AC20 tracking algorithms were refined to provide more accurate vehicle tracking for slow or stopped vehicles and vehicles only partially in the path of the subject vehicle. Extensive track, road, and pilot test results confirm acceptable performance of the tracking and warning algorithms in terms of data accuracy, temporal response, and latency.
Performance of the twin AC20 radar sensors was analyzed using the bronze tractor. Results indicate that the combined forward radar field-of-view is more than sufficient for meeting the program requirements, and that the fusion of the two AC20 radar warnings provides more robust operation.
Audible warning suppression logic based on speed and brake usage was developed, tested, and implemented.

4.4.2.2. Lateral Drift Warning (LDW) Progress and Accomplishments

The concept of operations for the LDW is the same for heavy trucks as light vehicles, and due to the cross-platform synergy afforded by the SafeTRAC lane tracker, the progress for the first year outlined in the light-vehicle LDW subsystem description (p. 28), also applies to heavy trucks. The LDW subsystem is based on the next-generation SafeTRAC lane departure warning system (SafeTRAC-2) from Cognex. SafeTRAC-2 consists of a processing module with a driver interface and a small camera mounted on the windshield of the vehicle. A similar LDW subsystem was integrated into the vehicles used in the RDCW program. Similarly in IVBSS, LDW will be integrated into the vehicle and use the same driver-vehicle interface as the other subsystems. LDW was further integrated with the other subsystems to improve the functionality of both LDW and the other subsystems. The interaction of the LDW subsystem with other subsystems on the heavy truck platform is described below.

4.4.2.2.1. Interaction with Other Subsystems

LDW will have three types of interactions with the other IVBSS subsystems. These three main types of interactions and examples of each are listed below:

LDW will use information from the other subsystems to improve LDW performance.
1. If the LCM subsystem detects a nearby object in an adjacent lane, the LDW warning threshold will be adjusted to warn earlier.
LDW will send information to the other subsystems so that they can improve their
performance.
1. LDW information confidence and lateral position will be broadcast by the LDW subsystem. This information will be used by the LCM subsystem to delay warnings until there is lateral motion toward an occupied adjacent lane.
2. Boundary type information will be broadcast by the LDW subsystem. Boundary information (detection of solid boundaries) assists the suppression of LCM alerts potentially caused by opposing traffic.
3. Lane width information will be posted by the LDW subsystem. The LCM subsystem can use this data to improve its determination of vehicle presence in the adjacent lane.
LDW and other subsystems will work together to improve situational awareness, e.g., refined curvature estimate.

4.4.2.3. Lane-Change/Merge (LCM) Progress and Accomplishments

The LCM warning function advises or warns the driver of an impending crash with another vehicle occupying a proximity zone in the adjacent lane, on either side of the subject vehicle, when changing lanes, turning, or passing a vehicle. The primary sensor information for LCM is provided by four short-range, side-looking radar sensors and a pair of rear-looking radar sensors.

For rear-looking radar development, the following progress has been made:

Final LCM subsystem sensors and hardware installed, calibrated, and tested on the bronze engineering tractor. Figure 32 shows the bronze tractor sensor mounting locations.
Advanced Kalman filtering, temporal track signal processing, and target classification algorithms were created and applied to the M/A-Com radar data. The algorithms were extensively tested on the bronze tractor and results demonstrate the ability to accurately distinguish between radar reflections due to the subject vehicle (tractor and trailer) and other vehicles and roadside objects. Results also confirm the ability to distinguish between vehicles and obstacles that are in the adjacent lane from objects two lanes or farther away. Collectively, these results confirm the tractor-only sensor solution will meet or exceed system functional requirements, i.e., no trailer sensors are required.
Kalman filtering and smoothing applied to the LDW lane position information to predict the time until the host vehicle crosses a lane boundary. The time to lane crossing, processed M/A-Com target data, BackSpotter side radar data, and yaw rate information were fused by the LCM collision warning logic to produce the final LCM alert.
LCM audible suppression logic based on speed, brake usage, LDW availability, presence of opposing traffic or roadside obstacles, and clear lane change events was developed, tested, and implemented.
Based on the M/A-Com and BackSpotter vehicle presence information, the lateral available maneuvering room (AMR), used by the LDW subsystem, was estimated.

Figure 32. Bronze tractor sensor mounting

Figure 32. Bronze tractor sensor mounting

4.4.2.4. Arbitration Progress and Accomplishments

Content in this section is taken from the IVBSS Heavy Truck Driver-Vehicle Interface (DVI) Specifications final report, written by the Battelle Center for Human Performance and Safety.¹To avoid overloading the driver with information, an arbitration system plays a critical role in IVBSS. First, it arbitrates among forward collision, lateral drift, and lane-change/merge collision warning signals based on the severity of each threat. It also supports the DVI, which may include status information during times of low collision conflict as well as urgent warnings of an imminent collision. The arbitration unit is unique to an integrated warning system.

The primary input to the arbitration subsystem is the warning severity and confidence of the three warning subsystems (FCW, LDW and LCM). The arbitration algorithms will also rely heavily on input from human factors and DVI studies and information for adjusting threat priorities, managing temporal aspects of the warnings, and, most importantly, determining the appropriate warning mechanisms and modalities for integrated scenarios. The arbitration algorithms will also make use of contextual and temporal databases.

The approach for arbitrating warnings in multiple-warning scenarios adopts a strategy of displaying as much as possible as long as it does not interfere with the driver’s ability to make the best safety response. Arbitration is primarily governed by a set of rules that was developed to provide general high-level guidance for determining which warnings to present in the event of multiple warning conflicts. Nineteen rules were generated containing the following information:

Rule description: The conditions under which visual and/or auditory warnings are
preempted or suppressed either by other warnings;
Justifications: Rationale and logic behind the rule;
Confidence: Strength of confidence in the data that supports the justification for the rule.
Confidence levels may be reduced if the quality or quantity of available data cannot adequately support the rationale behind the rule; and
Exceptions: Likelihood that exceptions to the rule may be applicable.

The rules were applied to an exhaustive list of each possible combination of outputs generated by the three IVBSS warning subsystems (FCW, LDW, and LCM) to determine the appropriate visual and auditory display. The subsystem outputs considered consisted of both the subsystem warning alerts and the main subsystem fault indicator. The arbitration logic was specified by the following information contained within a multiple threat permutation matrix:

Input: All possible combinations of FCW, LCM, and LDW warnings;
Output: The resulting visual and auditory outputs associated with each input combination.
Outputs are given for the DIU, right lateral, and left lateral visual displays and for the auditory displays;
Conflict source: The types of displays (auditory, DIU) associated with each input
combination for which warning display conflicts exist;
Sensor inputs: The subsystem alerts, in combination with the turn signal, that result in presentation conflicts;
Rule: The arbitration rule(s) (defined above) that apply to the input combination; and
Display outputs: The visual and auditory displays to present for each input combination.

This first stage of arbitration was followed by a smaller second stage that arbitrates between two concurrent auditory warnings. It determines when to present an auditory alert that is generated by one warning subsystem while a previous auditory alert associated with another subsystem is still actively being played. Four strategies were identified for arbitration of concurrent auditory warning messages. When an auditory message must be presented on the driver-vehicle interface (message 2), but an earlier message is currently being played (message 1), the first message may be preempted or the second message may be suppressed, delayed, or canceled. The appropriate strategy for each two-alert combination depends on warning priority, duration of message 1, and the time available before the driver must react to message 2. Detailed information on the arbitration rules, permutation matrix, auditory preemption logic, and driver-vehicle interface is contained in the IVBSS Human Factors and Driver-Vehicle Interface (DVI) Summary Report .⁶

4.4.3 Second Year Activities and Schedule

Many first year activities will be carried over and completed during the second. The schedule for subsystem development (Task 1.e) is shown in Figure 33.

Figure 33. Heavy-truck schedule for subsystem development

Figure 33. Heavy-truck schedule for subsystem development

4.5 Development of Driver-Vehicle Interface

This section addresses the subsystem aspects of the DVI, in terms of physical embodiment for hardware and software capability. Chapter 6 addresses the DVI from the human factors perspective, in terms of the science and investigations involved.

4.5.1 Overview

The general approach to designing the DVI for both the light-vehicle and heavy-truck platforms has been to design in hardware flexibility early in the systems design and development stages, thereby allowing human factors testing and evaluation to take place in parallel with the development of the IVBSS system. Early decisions regarding the types of hardware that will be available to the DVI team on the heavy-truck platform have been made, and the DVI team is working directly with the IVBSS systems design and development team to ensure that the hardware selection meets the anticipated needs based on the outcome of the human factors testing. This involves making some early assumptions regarding the scope of the DVI, based on some fundamental human factors principals, to allow the programs DVI and systems development teams to proceed in parallel.

The ultimate decision regarding selection of the final DVI configuration is a joint effort of UMTRI, the heavy-truck team, the vehicle manufacturer, and U.S. DOT and its partners. The decisions will take into consideration the following factors: (1) whether the approach is safe and effective based on simulator and in-vehicle testing; (2) the feasibility of the implementation from technical, financial, and schedule perspectives; and (3) what the market for crash warning systems seems to desire.

4.5.2 Heavy-Truck DVI Option Space

This section describes the dimensions considered in the development of the DVI warning space. Table 6 shows the warning strategy matrix.

Table 6. IVBSS heavy-truck DVI warning strategy space

Warning Type	IVBSS Warning	Desired Driver Response	Desired Driver Attention	Auditory Modality	Visual Modality
FCW	Hazard ahead	Decelerate vehicle and possibly steer to avoid threat based on driver’s observations	Forward	Forward sound source from DVI	Red collision warning LEDs on DVI and information only displays (yellow headway indicator LEDs and collision warning LCD display on DVI)
LDW	Drifting across a lane boundary	Steer back into lane	Forward	Directional, from side of threat, using speakers (crossing solid or dashed) controlled by DVI	Informational only; “move left/right” graphic on LCD of DVI, status and availability icon on LCD of DVI
LCM	Entering occupied lane	Steer back into lane	Forward with appropriate side verification	Directional, from side of threat, using speakers controlled by DVI	Side display LEDs near each side mirror that indicate that the adjacent lane is occupied

The DVI warning space includes both a headway warning system and an imminent collision detection system. The headway warning system provides drivers with graded cautionary warnings when headway time to a forward object drops below four established thresholds (3, 2, 1, and 0.5 seconds). These headways were selected based on field experience of safe headway distances, as well as consideration of possible preceding vehicle decelerations and the heavy truck’s braking capability. The forward collision system provides collision warnings whenever a significant risk of collision is detected. Detailed information on the DVI audible and visual displays is contained within the IVBSS Human Factors and Driver-Vehicle Interface (DVI) Summary Report. ⁶

The physical embodiment of the DVI has been designed and verified in the bronze engineering vehicle. Figure 34 shows the DVI placement in the cockpit of the bronze tractor. Figure 35 illustrates the full DVI space in the tractor cab interior.

Figure 34. Bronze tractor DVI placement

Figure 34. Bronze tractor DVI placement

Figure 35. Heavy-truck DVI space in truck cockpit

Figure 35. Heavy-truck DVI space in truck cockpit

4.5.3 Second-Year Activities and Schedule

The DVI hardware was integrated into the bronze engineering vehicle and extensively tested during development, jury drives, and pilot testing. It was also used for verification testing.

4.6 System Integration, Build of Prototype Vehicles, and Verification Testing

In the second year, the IVBSS hardware and software migrated from the Suburban mule vehicle to the bronze tractor and gold tractor (“bronze” and “gold” are the team’s terms for the engineering development tractor and the prototype installation tractor, respectively). This section details progress on the integration effort.

4.6.1 Overview

The three vehicles to be built during Phase I include: (1) the engineering mule vehicle (a Suburban SUV), (2) the bronze tractor (shown in Figure 32), and (3) the gold tractor. The mule vehicle was built and became operational in the first year of the project. The bronze tractor was built and became operational in the first quarter of 2007. The gold tractor will be built and will become operational in May 2008.

For the FOT fleet, an additional 10 vehicles will be built in Phase II. These will be new tractors purchased by the fleet operator that participates in the field operational test.

4.6.2 Heavy-Truck Prototype Build Plan

Since the heavy-truck IVBSS is being developed as a system, the integration section covers primarily progress on the vehicle build-up activity. Vehicle integration progress during the second year includes:

Bronze class 8 tractor
- An International model 8600i (similar to the FOT vehicles) was fully instrumented, tested, and used for Phase I verification testing.
Gold class 8 tractor
- The gold tractor is an International Transtar vehicle based on the 8600 platform with a day cab design commonly used for fleet operation. This vehicle is identical to the tractors used for the FOT testing;
- The gold tractor will serve as a prototype design of the FOT fleet vehicles with production “fit and finish.” All integration issues will be resolved and well documented to expedite the FOT vehicle integration in Phase II; and
- The gold tractor will also serve as a backup tractor to address the necessity that the tractors must remain in service during the entire FOT.
Procurement strategy
- If Phase II is awarded, parts for the FOT fleet vehicles, especially those with long lead times, will be purchased immediately.

Figure 32 illustrated the bronze tractor with the IVBSS sensor suite installed. Figure 36 shows the gold tractor.

Figure 36. Gold tractor (International Transtar)

Figure 36. Gold tractor (International Transtar)

4.6.3 Second-Year Activities and Schedule

The schedule for heavy-truck system integration and prototype builds (Task 1.g) is shown in Figure 37.

Figure 37. Schedule for heavy-truck system integration and prototype building

Figure 37. Schedule for heavy-truck system integration and prototype building

Second year activities included:

Installing IVBSS hardware on the bronze tractor;
Obtaining the gold tractor and installing IVBSS hardware;
Performing system verification and road worthiness testing;
Performing checkout of the development and prototype data acquisition systems;
Documenting the integration including development drawings (mechanical and electrical);
Maintaining the spare tractor; and
Delivering the official heavy truck fitted with the final prototype IVBSS.

5 Development of Verification Test Procedures and Phase I Testing

UMTRI team members and the U.S. DOT jointly developed on-road and test-track testing procedures to verify that the prototype integrated system satisfies performance guidelines and will serve as a suitable system for conducting a series of extended pilot and field operational tests in Phase II of the program.

The on-road test procedures, developed by U.S. DOT, Volpe, and NIST, and the results of the on-road tests from Phase I are discussed in Sections 5.1 and 5.2. A detailed overview of the on- road test procedures can be found in the IVBSS First Annual Report .²⁸

A description of the test-track procedures and the results of these tests can be found in Sections

5.3 and 5.4. Full descriptions of these tests can be found in Integrated Vehicle-Based Safety Systems (IVBSS) Verification Test Plans for Light Vehicles and the Integrated Vehicle-Based Safety Systems (IVBSS) Verification Test Plans for Heavy Trucks .

5.1 Summary of On-Road Verification Tests

The objectives of the on-road verification tests are to drive the vehicles in a naturalistic, uncontrolled driving environment on public roads to:

Measure the system’s susceptibility to nuisance alerts;
Assess alerts in perceived crash situations when they arise; and
Exercise each of the four crash warning functions in order to develop a mental model and better understanding of warning system logic.

The U.S. DOT conducted the on-road tests using its own drivers and observers. These tests were devised to complement track-based verification tests by assessing the limits of the system under naturalistic driving conditions. The on-road verification test procedures consist of a structured road map with fixed roadway characteristics, light conditions, driving maneuvers, and exposure to dynamic movements of other vehicles. The selection of the public road drive is based on known road characteristics and simple controllable maneuvers that can be repeated over time.

The routes for the on-road test were designed to provide a representative distribution of different road types, traffic conditions, lighting conditions, and driving maneuvers. The test routes for both the light vehicle and the heavy trucks were located in the greater Detroit area in Southeast Michigan, providing easy access to a variety of freeway, arterial, and local roadways.

The test route for the light vehicle is shown in Figure 38. This route is approximately 208 miles and consists of 29 percent freeway, 50 percent arterial roads, and 21 percent local roads. Each on-road test included a nighttime and daytime driving session. The nighttime driving sessions began about an hour and a half before sunset and covered the first half of the test route. Starting at this time exposed the systems to the entire range of lighting conditions as the sun set, as well as a period of darkness. The daytime driving sessions began in the morning after sunrise. The entire length of the test route was driven during the daylight drive.

Figure 38. Map of light vehicle on-road verification test route

Figure 38. Map of light vehicle on-road verification test route

The on-road testing route for heavy trucks is shown in Figure 39. This route was designed to incorporate routes from Con-Way’s short-haul delivery routes while also satisfying the requirements for diverse road types and vehicle maneuvers. This route is approximately 208 miles and consists of 55 percent freeway, 35 percent arterial roads, and 10 percent local roads. As with the light-vehicle test, the nighttime drive began before sunset and covered half of the 208-mile route. The daylight drive began after sunrise and covered all 208 miles.

The on-road tests included a U.S. DOT driver and at least one independent evaluator. The driver was instructed to drive normally and the independent evaluator observed the system performance and collected information about the alerts.

Figure 39. Map of heavy-truck on-road verification test route

Figure 39. Map of heavy-truck on-road verification test route

5.2 Results of On-Road Verification Tests

The Phase I light-vehicle and heavy-truck on-road verification testing was conducted in October 2007. Due to the results of the on-road tests and failures of some of the test-track tests, Phase I was extended to allow both the light-vehicle and heavy-truck teams to update the system software to test failures and system anomalies. After the systems were updated, the on-road verification tests were rerun to reassess their on-road performance. The on-road tests to assess the updates during the Phase I extension took place in November 2007 and March 2008. The results of both the initial tests and the retests for both the light-vehicle and heavy-truck platforms are discussed in the following sections.

5.2.1 Light-Vehicle On-Road Verification Test Results

The light-vehicle platform underwent two rounds of on-road tests; one test during Phase I of the project (October 2007), and one after system updates were made during the Phase I extension (February 2008). Alert rates, nuisance alerts, and system availability will be discussed for both tests.

5.2.1.1. Light-Vehicle Alert Rates and Validity

A total of 52 alerts were issued during the first on-road test. About 52 percent (27 alerts) were judged to be “valid” and 48 percent were judged to be “nuisance.” In the Phase I extension on-road test, a total of 49 alerts were issued; 29 percent (14 alerts) were judged to be “valid” and 71 percent (35 alerts) were considered to be “nuisance.” The validity of the alerts was assessed subjectively by the driver and observers during the test, and objectively in the analysis of the driving data. Tables 7 and 8 break down the valid and nuisance alerts issued by each function for the Phase I on-road test and the Phase I extension on-road test respectively.

Table 7. Breakdown of alerts in Phase I on-road test

Alert	Valid	Nuisance	Total
FCW	4	4	8
LCW-Left	0	2	2
LCW-Right	0	3	3
LDW Imminent-Left	2	0	2
LDW Imminent-Right	1	4	5
LDW Cautionary-Left	15	10	25
LDW Cautionary-Right	3	0	3
CSW	2	2	4
Total	27	25	52
%	52%	48%	100%

Table 8. Breakdown of alerts in Phase I extension on-road test

Alert	Valid	Nuisance	Total
FCW	0	1	1
LCW-Left	0	5	5
LCW-Right	1	3	4
LDW Imminent-Left	1	3	4
LDW Imminent-Right	0	1	1
LDW Cautionary-Left	12	8	20
LDW Cautionary-Right	0	10	10
CSW	0	4	4
Total	14	35	49
%	29%	71%	100%

5.2.1.2. Light-Vehicle Nuisance Alert Rates

The nuisance alert rate per 100 miles for each LV function and the total nuisance alert rate for both on-road tests are shown in Figure 40. Overall, the nuisance alert rate during Phase I testing was at 8.0 nuisance alerts per 100 miles driven, which is within the light-vehicle platform performance guidelines of a maximum of 15 alerts per 100 miles (shown by red line in Figure 40). The total nuisance alert rate in the Phase I extension also met these performance guidelines with 11.4 per 100 miles.

Figure 40. Breakdown of nuisance alert rate both LV on-road tests

Figure 40. Breakdown of nuisance alert rate both LV on-road tests

5.2.1.3. Light-Vehicle LDW Availability

Figure 41 shows the availability of the LDW subsystem on local roads, arterials, and freeways. The LDW system is considered available when it is able to track both the left and right lane markers. This enables the system to issue crash alerts that are associated with lateral drifting events. The red lines in Figure 41 indicate the availability targets for light-vehicle for each road type. The LDW subsystem exceeded the availability targets for both freeway and arterial roads in both tests, however the system was only available 22 percent of the total distance traveled on local roads in the Phase I test, and only 16 percent in the Phase I extension test. This degraded system performance was most likely due to the rainy driving conditions (Phase I) and the presence of road salt residue on the roads (Phase I extension), which most likely limited the LDW subsystem’s ability to identify the contrast between the road surface and lane markings.

Figure 41. LDW availability by travel speed in LV on-road tests

Figure 41. LDW availability by travel speed in LV on-road tests

5.2.2 Heavy-Truck On-Road Verification Test Results

Three rounds of testing were completed for the heavy-truck platform. The initial round of tests and retesting during Phase I took place in September 2007 and November 2007. On-road tests conducted during the Phase I extension took place in March 2008. Alert rates, nuisance alerts, and system availability are discussed for all three tests in the following sections.

5.2.2.1. Heavy-Truck Alert Rates and Validity

During the first on-road verification test a total of 208 alerts were issued. Twelve alerts were issued due to scripted maneuvers that were performed to invoke valid alerts. These 12 alerts were omitted from the analysis leaving a total of 196 alerts were received under naturalistic driving conditions. Nuisance alerts accounted for 89 percent (175) of the 196 total alerts valid alerts comprised 11 percent (21) of total alerts. As with the light-vehicle platform, the validity of the alerts in each of the three tests was assessed subjectively by the driver and observers during the test, and objectively in the analysis of the driving data. Table 9 breaks down the valid and nuisance alerts in the Phase I heavy-truck on-road test.

Table 9. Breakdown of alerts in Phase I test

Alert	Valid	Nuisance	Total
FCW	2	19	21
LCW-Left	11	56	67
LCW-Right	2	72	74
LDW-Left	0	8	8
LDW-Right	6	20	26
Total	21	175	196
%	11%	89%	100%

Sixty-six alerts were issued during the first Phase I extension verification test; about 24 percent or 16 alerts were judged to be valid, while about 76 percent or 50 alerts were deemed as nuisance. Table 10 breaks down these alerts by system function. It is noteworthy that nuisance alerts in the second heavy-truck on-road test dropped by 71 percent from the Phase I test nuisance alerts. This improvement was due to implementation of recommended improvements based on Phase I results. By system function, the biggest drop in nuisance alerts was observed in the LDW function (89%). There was major improvement in LCW nuisance alerts, lowering these alerts by 73 percent from tests conducted in September. Nuisance alerts from FCW have decreased by 37 percent.

Table 10. Breakdown of alerts in November 2007 on-road test

Alert	Valid	Nuisance	Total
FCW	0	12	12
LCW-Left	8	23	31
LCW-Right	3	12	15
LDW-Left	5	0	5
LDW-Right	0	3	3
Total	16	50	66
%	24%	76%	100%

A total of 30 alerts were issued during the second Phase I extension verification test; six of these alerts (20%) were judged to be valid while the remaining 24 alerts (80%) were deemed as nuisance (Table 11). The system showed significant improvement since she November 2007 testing, reducing the nuisance alert rate by 52 percent. LCW nuisance alerts were decreased by 89 percent.

Table 11. Breakdown of alerts in the Phase I extension test

Alert	Valid	Nuisance	Total
FCW	1	9	10
LCW-Left	0	2	2
LCW-Right	0	2	2
LDW-Left	1	6	7
LDW-Right	4	5	9
Total	6	24	30
%	20%	80%	100%

5.2.2.2. Heavy-Truck Nuisance Alert Rates

Figure 42 illustrates the nuisance alert rates per 100 miles for each function and total system for the heavy-truck on-road tests. In Phase I, the total nuisance alert rate was close to 56 nuisance alerts per 100 miles driven. Based on IVBSS performance guidelines for the heavy-truck platform, the total nuisance alert rate should be at or below 15 alerts per 100 miles (shown by a red line in Figure 42). The LCW function largely contributed to this very high nuisance alert rate in Phase I. The nuisance alert rate in the Phase I re-test was at about 16 alerts per 100 miles driven. This is a remarkable improvement in comparison to 56 nuisance alerts per 100 miles received in Phase I. This rate still exceeds the guideline of 15 or less nuisance alerts per 100 miles, however. After the Phase I re-test, the LCW function was updated and in the final test the updated system showed a nuisance alert rate of 7.4 alerts per 100 miles driven, meeting its performance guideline of 15 or less nuisance alerts per 100 miles.

Figure 42. Breakdown of nuisance alert rates in HT on-road tests

Figure 42. Breakdown of nuisance alert rates in HT on-road tests

5.2.2.3. Heavy-Truck LDW Availability

In Phase I, the heavy-truck LDW function exceeded the availability targets for all three road types. In both the Phase I re-rest and the Phase I extension however, LDW function exceeded the availability targets for freeway and arterial roads but did not meet the target for local roads. The system was only available 29 percent and 19 percent of the total distance traveled on local roads for the Phase I re-test and the Phase I Extension tests respectively. This degraded system performance was most likely due to rainy driving conditions and the presence of salt on road surfaces. Standing water and salt residue most likely limited the LDW function’s ability to distinguish lane markings. These results are illustrated in Figure 43. The availability targets for each road type are indicated in red.

Figure 43. LDW Availabilty by travel speed bin in HT on-road tests

5.3 Summary of Test-Track Verification Tests

This section describes the track tests that were used to verify that the prototype integrated system meets design requirements and is ready for use in the field operational test planned for Phase II. The test procedures for both light vehicle and heavy truck include the following:

Extensive test-track testing;
Test scenarios and specifications, such as speeds, closing rates, road geometry, etc.;
Pass/fail criteria for evaluating system performance; and
A set of measurement variables that will be used to evaluate system performance when

compared to an independent measurement system installed on the test vehicle. The tests for light vehicle and heavy truck are the same for each test unless notated in the text. Detailed test plans for both platforms are available on the ITS America Web site .

5.3.1 Rear-End Crash Threat Tests

The 12 rear-end crash threat scenarios are as follows:

Scenario 1: This test is intended to verify the appropriateness of an FCW when the SV approaches, from behind, a slower moving POV (P) in the center of the same lane. In this test the SV and P1 are traveling at a constant speed with a speed differential between the SV and P1 of at least 8.9 m/s (20 mph).

Figure 44. Rear-end crash scenario 1

Figure 44. Rear-end crash scenario 1

Scenario 2: This test is intended to verify the appropriateness of an FCW when the SV approaches from behind (with a short headway time gap), a modestly slowing POV (P) in the center of the same lane.

Figure 45. Rear-end crash scenario 2

Figure 45. Rear-end crash scenario 2

Scenario 3: This test is intended to verify the appropriateness of an FCW when the SV approaches from behind (with a large headway time gap), an aggressively slowing POV (P) in the center of the same lane.

Figure 46. Rear-end crash scenario 3

Figure 46. Rear-end crash scenario 3

Scenario 4: The test determines whether the countermeasure’s required collision alert occurs at a range that is consistent with the collision alert onset timing requirements. This test especially explores the ability of the countermeasure to issue timely warnings in response to a stopped vehicle approached at moderate speed.

Figure 47. Rear-end crash scenario 4

Figure 47. Rear-end crash scenario 4

Scenario 5: The test determines whether the countermeasure’s required collision alert occurs at a range that is consistent with the collision alert onset timing requirements. This test especially explores the ability of the countermeasure to issue timely warnings in response to a stopped vehicle approached at low speed.

Figure 48. Rear-end crash scenario 5

Figure 48. Rear-end crash scenario 5

Scenario 6: This test is intended to verify the timeliness detecting a new in-path vehicle and the appropriateness of an FCW when the SV changes lanes to approach from behind a moderately slower moving P. The SV should complete its lane change just before entering the system’s forward warning zone.

Figure 49. Rear-end crash scenario 6

Figure 49. Rear-end crash scenario 6

Scenario 7: The test determines whether the countermeasure’s required collision alert occurs at a range that is consistent with the collision alert onset timing requirements. This test especially explores the ability of the countermeasure to issue timely warnings in response to a stopped vehicle in a curve to see if the system is able to determine the stopped vehicle to be in the same lane and therefore a threat.

Figure 50. Rear-end crash scenario 7

Figure 50. Rear-end crash scenario 7

Scenario 8: The test determines whether the countermeasure’s required collision alert occurs at a range that is consistent with the collision alert onset timing requirements. This test especially explores the ability of the countermeasure to issue timely warnings in response to a lower vehicle in a curve to see if the system is able to determine the slower vehicle to be in the same lane and therefore a threat.

Figure 51. Rear-end crash scenario 8

Figure 51. Rear-end crash scenario 8

Scenario 9: This test is intended to verify the appropriateness of an FCW when the SV approaches a slower moving motorcycle that is traveling behind a same-speed truck. The test determines whether the countermeasure’s required collision alert occurs at a range that is consistent with the collision alert onset timing requirements. This test especially explores the ability of the countermeasure to detect smaller in-path vehicle near larger vehicles and issue timely warnings.

Figure 52. Rear-end crash scenario 9

Figure 52. Rear-end crash scenario 9

Scenario 10: This test is intended to verify the timeliness detecting a new in-path vehicle and the appropriateness of an FCW when a slower moving POV changes lanes in front of the SV. The lane-change/cut-in by the POV should occur within the forward-conflict region of the FCW system on the SV.

Figure 53. Rear-end crash scenario 10

Figure 53. Rear-end crash scenario 10

Scenario 11: This test is intended to verify the timeliness detecting a new in-path vehicle and the appropriateness of an FCW when a slower POV is suddenly revealed after the cutout of an intermediate vehicle.

Figure 54. Rear-end crash scenario 11

Figure 54. Rear-end crash scenario 11

Scenario 12: This test is intended to verify the appropriateness of an FCW when the SV approaches, from behind and from long range, a slower moving motorcycle in the center of the same lane. This test especially explores the ability of the countermeasure to detect and issue timely warnings for smaller in-path vehicles.

Figure 55. Rear-end crash scenario 12

Figure 55. Rear-end crash scenario 12

5.3.2 Lane-Change Crash Threat Tests The five lane-change threat scenarios are as follows:

Scenario 1: This test is intended to verify the appropriateness of a warning when the right- side blind zone is occupied by a vehicle. The SV driver gives a turn signal and begins to change lanes to the occupied right adjacent lane. Physically the POV is positioned with its front bumper behind the SV driver. Both vehicles are traveling at the same forward speed.

Figure 56. Lane-change crash scenario 1

Figure 56. Lane-change crash scenario 1

Scenario 2: This test is intended to verify the appropriateness of a warning (when and if it is issued) when the SV signals and begins to change lanes to the left while the adjacent lane is occupied by another vehicle such that the front bumper of the POV is behind SV driver. In this test both vehicles, traveling at the same forward speed are negotiating a large radius curve (~300 m).

Figure 57. Lane-change crash scenario 2

Figure 57. Lane-change crash scenario 2

Scenario 3: This test is intended to verify the appropriateness of a warning when the SV signals and begins to merge into a lane that is occupied by another vehicle located in the blind spot of the SV driver. In this test both vehicles are traveling at the same forward speed. The test determines whether the countermeasure’s required lane change merge warning is consistent with the warning requirements when the lane marker is not available.

Figure 58. Lane-change crash scenario 3

Figure 58. Lane-change crash scenario 3

Scenario 4: This test is intended to verify the appropriateness of a warning (when and if it is issued) when the SV signals and begins to change lanes too soon after passing the vehicle in the left lane. In this test SV vehicle is traveling a little faster than the POV.

Figure 59. Lane-change crash scenario 4

Figure 59. Lane-change crash scenario 4

Scenario 5: This test is intended to verify the appropriateness of a warning when the SV changes lane and encounters an approaching POV.

Figure 60. Lane-change crash scenario 5

Figure 60. Lane-change crash scenario 5

5.3.3 Road Departure Crash Threat Tests

The eight road departure crash threat scenarios are as follows:

Scenario 1: This test is intended to verify the appropriateness of an LDW when the SV drifts at a slow rate toward an opposing-traffic lane as designated by a double solid lane boundary. The lateral velocity of the SV relative to the boundary markers should be between 0.2 and 0.4 m/s.

Figure 61. Road departure crash scenario 1

Figure 61. Road departure crash scenario 1

Scenario 2: This test is intended to verify the appropriateness of an LDW when the SV drifts
at a high rate toward a clear shoulder as designated by a solid lane boundary. The lateral
velocity of the SV relative to the boundary markers should be between 0.6 and 0.8 m/s.

Figure 62. Road departure crash scenario 2

Figure 62. Road departure crash scenario 2

Scenario 3: This test is intended to verify the appropriateness of an LDW when the SV driving at low speed drifts at a low lateral speed toward a clear shoulder (designated by a solid lane boundary) on a curve with a small radius (~200 m). The lateral velocity of the SV relative to the solid white boundary marker should be between 0.2 to 0.4 m/s.

Figure 63. Road departure crash scenario 3

Figure 63. Road departure crash scenario 3

Scenario 4: This test is intended to verify the appropriateness of an LDW when the SV driving at high speed drifts at a low lateral speed toward a clear shoulder (designated by a solid lane boundary) on a curve with a large radius (~ 300 m). The lateral velocity of the SV relative to the solid white boundary marker should be between 0.2 to 0.4 m/s.

Figure 64. Road departure crash scenario 4

Figure 64. Road departure crash scenario 4

Scenario 5: This test is intended to verify the appropriateness of an LDW when the SV drifts at a low lateral speed toward an adjacent jersey barrier to be placed one meter from lane marker. The lateral velocity of the SV relative to the barrier should be between 0.2 to 0.4 m/s.

Figure 65. Road departure crash scenario 5

Figure 65. Road departure crash scenario 5

Scenario 6: This test is intended to verify the appropriateness of a curve speed warning (CSW), when the SV driving at excessive speed encounters a small radius curve in warm/dry condition.

Figure 66. Road departure crash scenario 6

Figure 66. Road departure crash scenario 6

Scenario 7: This test is intended to verify the appropriateness of a curve speed warning, when the SV driving at excessive speed encounters a small radius curve in cold or wet condition.

Figure 67. Road departure crash scenario 7

Figure 67. Road departure crash scenario 7

Scenario 8: This test is intended to verify the appropriateness of a warning when the SV begins to change lanes to the left without signaling, while the adjacent lane is occupied by another vehicle that is located such that the POV rear bumper is in front of the SV driver. In this test both vehicles are traveling at the same forward speed.

Figure 68. Road departure crash scenario 8

Figure 68. Road departure crash scenario 8

5.3.4 Multiple-Threat Tests

The two multiple-threat scenarios are as follows:

Scenario 1: This test is intended to verify the appropriateness of an FCW and LCW when the SV approaches a slower P1 while there is an adjacent P2 that prevents the SV from changing lanes to maneuver around P1. In this test the SV and P2 are traveling at the same forward speed. The test determines whether the IVBSS system provides appropriate warnings or series of warnings to the SV in the multiple threat scenario. The IVBSS warning system will not suppress critical warnings due to multiple threats occurring.

Figure 69. Multiple-threat crash scenario 1

Figure 69. Multiple-threat crash scenario 1

Scenario 2: This test is intended to verify the appropriateness of an LCW followed by an FCW when an adjacent P2 prevents the SV from changing lanes to go around a slowing P1. This test determines whether the countermeasure’s required alert occurs, giving the SV sufficient threat awareness of the multiple threats. It will also show that the IVBSS Warning System will not suppress critical warnings due to multiple threats occurring.

Figure 70. Multiple-threat crash scenario 2

Figure 70. Multiple-threat crash scenario 2

5.3.5 No-Warn Threat Tests

The eight no-warn threat scenarios are as follows:

Scenario 1: The purpose of this test is to verify that the IVBSS system does not issue a warning in a close-following situation, where SV is driving behind a POV with a constant 1second headway gap.

Figure 71. No-warn threat scenario 1

Figure 71. No-warn threat scenario 1

Scenario 2: The purpose of this test is to verify that the IVBSS system does not issue a warning when SV passes a stopped POV in the adjacent lane, when both the vehicles are in a curve.

Figure 72. No-warn threat scenario 2

Scenario 3: This test determines whether or not IVBSS system allows for close cut-in lane changes by a faster-moving POV without warning, as commonly experienced during naturalistic driving.

Figure 73. No-warn threat scenario 3

Figure 73. No-warn threat scenario 3

Scenario 4: The purpose of this test is to verify that the IVBSS system does not issue a warning when SV approaches from behind and passes between two slower moving large vehicles in adjacent lanes.

Figure 74. No-warn threat scenario 4

Figure 74. No-warn threat scenario 4

Scenario 5: This test is intended to verify that no warning is issued for poor lane keeping, when SV is weaving within the lane, with a continuous barrier on the left with clear lane markings.

Figure 75. No-warn threat scenario 5

Figure 75. No-warn threat scenario 5

Scenario 6: The purpose of this test is to verify that the IVBSS system does not issue a warning when the SV driver changes lanes in front of a slowly approaching POV in an adjacent lane. Since the POV driver has adequate time to react to the SV lane-change due to both the range between the POV and rear of the SV and the slow closing rate between the vehicles, a warning should not be issued to the SV driver.

Figure 76. No-warn threat scenario 6

Figure 76. No-warn threat scenario 6

Scenario 7: The purpose of this test is to verify that the IVBSS system does not issue a warning during a lane change for vehicles that are two lanes over and not a threat.

Figure 77. No-warn threat scenario 7

Figure 77. No-warn threat scenario 7

Scenario 8: This test is intended to verify the appropriateness of a curve speed warning system that no CSW warning is given when the SV driving at safe speed encounters a small radii curve in warm/dry condition.

Figure 78. No-warn threat scenario 8

Figure 78. No-warn threat scenario 8

5.4 Test-Track Verification Test Results

The Phase I light-vehicle and heavy-vehicle verification testing was conducted in September 2007. As mentioned in the on-road test description, Phase I was extended to allow both the light-vehicle and heavy-truck teams to update IVBSS and re-run the track testing for the affected tests. The affected tests were rerun in November 2007 and February 2008. The results of both the initial tests and the retests for both light-vehicle, and heavy-truck platforms are discussed in the following sections.

Table 12. FCW LV Phase I track test results

No	FCW Tests	Initial Conditions				Pass/ Fail	Test Type
No	FCW Tests	SV (mph)	POV (mph)	^RH (m)	^apov (g)	Pass/ Fail	Test Type
1	Constant speed POV	50	25			Pass	Req
2	Slowing POV at close range	45	45	30	0.2	Pass	Req
3	Stopped POV at far range	45	45	60	0.35	Pass	Req
4	Stopped POV at moderate speed	45	0			Pass	Req
5	Stopped POV at low speed	30	0			Pass	Req
6	Slower POV after land change by SV	45	35	50		Pass	Req
7	Stopped POV in a curve	30	0			FAIL	Eng
8	Slower POV in a curve	45	35			Pass	Eng
9	Constant speed motorcycle behind truck	45	25			Pass	Eng
10	Cut-in by POV	35	25	45		Pass	Eng
11	Slowing POV1after POV2 cut-out	50	25	60		Pass	Eng
12	Constant speed motorcycle	45	25			Pass	Req

5.4.1 Light-Vehicle Test-Track Results

This section discusses the results of each of the IVBSS subsystems for the Phase I and the Phase I Extension. The pass/fail results for each of the IVBSS functions and the multiple threat scenarios are discussed below.

5.4.1.1. Summary of FCW Pass/Fail Results

In the original September 2007 track-test, the FCW function passed all seven required tests, and four of the five engineering tests. Required tests are those tests that must be passed in order for the IVBSS program to be approved to enter the program’s second phase (field operational testing). The objective of the engineering tests, however, is to characterize system performance and determine system limitations. Table 12 lists the individual tests and their pass/fail results. Also included in Table 12 are brief descriptions of each test and the initial conditions. The red cells in the table indicate a failed test.

Table 13. LDW LV Phase I test-track results

No	LDW Test		Initial Conditions			Pass/ Fail	Test Type
No	LDW Test	Speed (mph)	POV (mph)	Lateral Speed (m/s)	Curve Radius (m)	Pass/ Fail	Test Type
1	Toward opposing traffic lane	45		0.3		Pass	Req
2	Toward clear shoulder	45		0.7		Pass	Req
3	Toward clear shoulder on small radius curve	35		0.3	200	Pass	Req
4	Toward clear shoulder on large radius curve	45		0.3	300	Pass	Req
5	Toward shoulder barrier with solid lane marker	35		0.3		Pass	Eng
8	Toward adjacent lane with POV forward on left	45	45	0.4		Pass	Req

5.4.1.3. Summary of CSW Pass/Fail Results

The CSW function passed both of the required tests in Phase I testing. There were no engineering tests for the CSW function. Table 14 shows a brief description, the initial conditions, and the pass/fail results of each test.

Table 14. CSW LV Phase I test-track results

No	CSW Test	Initial Conditions		Pass/ Fail	Test Type
No	CSW Test	Speed (mph)	Curve Radius (m)	Pass/ Fail	Test Type
6	Toward curve with excessive speed in dry/warm condition	50	100	Pass	Req
7	Toward curve with excessive speed in wet/cold condition	50	100	Pass	Req

5.4.1.4. Summary of LCW Pass/Fail Results

All three of the required tests and both of the engineering tests for the LCW function failed the Phase I, September 2007 testing. At the time of the testing the system had been recently updated and was not properly calculating the position of the vehicle within the lane and was therefore unable to properly detect when the vehicle had crossed the lane lines. Table 15 shows the pass/fail results of these tests.

Table 15. LCW LV Phase I test-track results

No	LCW Test	Initial Conditions				Pass/ Fail	Test Type
No	LCW Test	SV Speed (mph)	Lateral Speed (m/s)	POV Speed (mph)	Curve Radius (m)	Pass/ Fail	Test Type
1	LC conflict with POV in blind spot on right	45	0.25	40		FAIL	Req
3	LC into adjacent POV on curve	35	0.25	40	300	FAIL	Eng
4	LC into adjacent POV on merge – Lane line not available	35		40		FAIL	Req
5	LC into adjacent POV after passing	37	0.25	35		FAIL	Eng
6	LC into approaching POV	30	0.25	45		FAIL	Req

The light-vehicle IVBSS team updated the LCM software to incorporate position in the lane to determine the warning onset timing. The lane widths at the track were much wider than lane widths on public roads, causing significant variation in warning onset timing. After making the necessary updates to the LCW function, the system was retested during the Phase I extension. In February 2008 the LCW function passed all three required tests and both engineering tests. The results of the Phase I extension of the LCW function are shown in Table 16.

Table 16. LCW LV Phase I extension test track results, February 2008

Test No	LCW Tests	Initial Condition					Pass/ Fail	Test Type
Test No	LCW Tests	SV Speed (mph)	Lateral Speed (m/s)	Lateral Distance (m)	POV Speed (mph)	Curve Radius (m)	Pass/ Fail	Test Type
1	LC conflict with POV in blind spot on right	45	0.65	0.91	45		Pass	Req
3	LC into adjacent POV on curve	35	0.65	0.91	35	150-300	Pass	Eng
4	LC into adjacent POV on merge - Lane marker not available	35	0.65	0.91	35		Pass	Req
5	LC into adjacent POV after passing	37	0.65	0.91	35		Pass	Eng
6	LC into approaching POV	50	0.65	0.91	60		Pass	Req

5.4.1.5. Summary of MT Pass/Fail Results

In the initial testing of the multiple threat scenarios, the IVBSS system passed one of the required tests and failed the other due to the failures of the LCW system. Test 1 was rerun during the Phase I extension. The results of the MT test scenarios for Phase I and the Phase I Extension are shown in Tables 17 and 18, respectively.

Table 17. MT LV Phase I track test results

No	Test	Initial Conditions					Pass/ Fail	Test Type
No	Test	SV Speed (mph)	Lateral Speed (m/s)	POV Speed (mph)	apov (g)	RH (m)	Pass/ Fail	Test Type
1	Avoid RE with slower POV1 and encounter LC with adjacent POV2	50	0.5	25		100	FAIL	Req
2	Avoid LC with POV2, RE with slowing POV1, and encounter ED toward clear shoulder	35	0.5	35	0.2	40	Pass	Eng

Table 18. MT LV Phase I extension track test results, February 2008

No	Test	Initial Conditions					Pass/ Fail	Test Type
No	Test	SV Speed (mph)	Lateral Speed (m/s)	POV Speed (mph)	apov (g)	RH (m)	Pass/ Fail	Test Type
1	Avoid RE with slower POV1 and encounter LC with adjacent POV2	50	0.5	25		100	Pass	Req

5.4.1.6. Summary of No-Warn Tests

The IVBSS LV platform passed all of the no-warn tests during Phase I testing. Table 19 illustrates a list of the no-warn tests with descriptions, initial conditions, and pass/fail results.

Table 19. Phase I LV no-warn test results

No	Test Description	Initial Conditions					Pass/ Fail	Test Type
No	Test Description	SV Speed, VSV (mph)	POV Speed, (mph)	Range, RSP1 (m)	SV Lat Speed, (m/s)	Radius of Curvature (m)	Pass/ Fail	Test Type
NW-1	No FCW when SV closely follows POV	40	40	18			Pass	Req
NW-2	No FCW when passing stopped POV in adjacent lane on curve	35	0			300	Pass	Req
NW-3	No FCW when faster POV cuts in front of SV	40	45	10	0.5		Pass	Req
NW-4	No FCW when passing between two slower POVs in adjacent lanes	45	40				Pass	Req
NW-5	No LDW with poor lane keeping and barrier on the left	35			0.3		Pass	Req
NW-6	No LCW when SV changes lanes in front of close POV	30	35	15	0.4		Pass	Req
NW-7	No LCW when SV changes lanes while POV is two lanes over	45	45		0.4		Pass	Req
NW-8	No CSW when SV is approaching a curve with safe speed	35				100	Pass	Req

The above test results show that the light-vehicle IVBSS satisfies performance guidelines and will serve as a suitable system for conducting a series of pilot and field operational tests in Phase II of the program.

5.4.2 Heavy-Truck Test Track Results

This section discusses the results of each of the IVBSS systems for Phase I and for the Phase I extension. The pass/fail results for each of the three IVBSS functions and the multiple threat scenarios are discussed below.

5.4.2.1. Summary of FCW Pass/Fail Results

In the original September 2007 track test, the FCW function passed seven out of eight required tests, and two out of three engineering tests. Table 20 lists these individual tests and their pass/fail results. FCW test 5 was omitted from the test track due to safety concerns with approaching a stopped lead vehicle at high speeds.

Table 20. FCW HT Phase I track test results

No	FCW Tests	Initial Conditions				Pass/ Fail	Test Type
No	FCW Tests	SV (mph)	POV (mph)	RH (m)	apov (g)	Pass/ Fail	Test Type
1	Constant speed POV	55	30			Pass	Req
2	Slowing POV at close range	40	40	40	0.15	Pass	Req
3	Stopped POV at far range	40	40	60	0.31	Pass	Req
4	Stopped POV at moderate speed	35	0			Pass	Req
6	Slower POV after land change by SV	45	35	40		Pass	Req
7	Stopped POV in a curve	30	0			FAIL	Eng
8	Slower POV in a curve	55	40			Pass	Eng
9	Constant speed motorcycle behind truck	50	35			Pass	Req
10	Cut-in by POV	45	35	30		FAIL	Req
11	Slowing POV1after POV2 cut-out	40	40	60	0.15	Pass	Eng
12	Constant speed motorcycle	50	30			Pass	Req

Based on above results, Eaton modified the FCW system to improve detection of stopped lead vehicles and cut-ins at short range from the heavy truck. FCW test 10 was conducted again in March 2008. The results of this retest are shown in Table 21.

Table 21. FCW HT Phase I extension track-test results, March 2008

No	FCW Tests	Initial Conditions				Pass/ Fail	Test Type
No	FCW Tests	SV (mph)	POV (mph)	RH (m)	apov(g)	Pass/ Fail	Test Type
10	Cut-in by POV	45	35	30		Pass	Req

5.4.2.2. Summary of LDW Pass/Fail Results

The LDW function passed all four required tests and the engineering test during Phase I testing, as shown in Table 22.

Table 22. LDW HT Phase I track-test results

No	LDW Test	Initial Conditions			Pass/ Fail	Test Type
No	LDW Test	Speed (mph)	Lateral Speed (m/s)	Curve Radius (m)	Pass/ Fail	Test Type
1	Toward opposing traffic lane	45	0.3		Pass	Req
2	Toward clear shoulder	45	0.7		Pass	Req
3	Toward clear shoulder on small radius curve	40	0.3	185	Pass	Req
4	Toward clear shoulder on large radius curve	45	0.3	280	Pass	Req
5	Toward shoulder barrier with solid lane marker	40	0.3		Pass	Eng

Based on results from the HT on-road verification test, some modifications were made to the LDW alert logic during the Phase I extension. The affected track tests were rerun in November 2007 and the results are shown in Table 23. In the first round of testing of the Phase I extension LDW function failed required test 3 because the system suppressed four crash-imminent alerts due to the lack of proper tuning. Further LDW modifications were implemented and required test 3 was re-performed in March 2008. The system passed this test as shown in Table 24.

Table 23. LDW HT Phase I retest test track results, November 2007

No	LDW Test	Initial Conditions			Pass/ Fail	Test Type
No	LDW Test	Speed (mph)	Lat. speed (m/s)	Curve Radius (m)	Pass/ Fail	Test Type
1	Toward opposing traffic lane	45	0.3		Pass	Req
2	Toward clear shoulder	45	0.7		Pass	Req
3	Toward clear shoulder on small radius curve	40	0.3	185	FAIL	Req
5	Toward shoulder barrier with solid land marker	40	0.3		Pass	Eng

Table 24. LDW HT Phase I extension test track results, March 2008

No	LDW Test	Initial Conditions			Pass/ Fail	Test Type
No	LDW Test	Speed (mph)	Lateral Speed (m/s)	Curve Radius (m)	Pass/ Fail	Test Type
3	Toward clear shoulder on small radius curve	40	0.3	185	Pass	Req

5.4.2.3. Summary of LCW Pass/Fail Results

During Phase I the LCW function of the HT IVBSS passed both required tests and three out of four engineering tests as shown in Table 25. Test 4 failed 9 out of 10 trial runs because the test was set up improperly.

Table 25. LCW HT Phase I test track results

No	LCW Test	Initial Conditions				Pass/ Fail	Test Type
No	LCW Test	SV (mph)	Lat. speed (m/s)	POV (mph)	Curve Radius (m)	Pass/ Fail	Test Type
1	Adjacent POV in blind spot on right	40	0.25	40		Pass	Req
2	Adjacent POV in blind spot on left	40	0.25	40		Pass	Req
3	Adjacent POV on curve	40	0.25	40	280	Pass	Eng
4	Adjacent POV on merge	40		40		FAIL	Eng
5	Adjacent POV after passing	45	0.25	45		Pass	Eng
6	Approaching POV	35	0.25	35		Pass	Eng

Due to system changes as a result of the on-road verification tests during the Phase I extension, some LCW crash-imminent tests were re-conducted in November 2007 and March 2008 as shown in Tables 26 and 27, respectively. The LCW function passed all of these tests.

Table 26. LCW HT Phase I retest track results, November 2007

No	Test	Initial Conditions				Pass/ Fail	Test Type
No	Test	SV Speed (mph)	Lateral Speed (m/s)	POV Speed (mph)	Curve Radius (m)	Pass/ Fail	Test Type
1	Adjacent POV in blind spot on right	40	0.25	40		Pass	Req
2	Adjavent POV in blind spot on left	40	0.25	40		Pass	Req

Table 27. LCW HT Phase I extension test track results, March 2008

No	Test	Initial Conditions				Pass/ Fail	Test Type
No	Test	SV Speed (mph)	Lateral Speed (m/s)	POV Speed (mph)	Curve Radius (m)	Pass/ Fail	Test Type
1	Adjacent POV in blind spot on right	40	0.25	40		Pass	Req
2	Adjavent POV in blind spot on left	40	0.25	40		Pass	Req
4	Adjavent POV on merge	40		40		Pass	Eng

5.4.2.4. Summary of MT Pass/Fail Results

In the initial testing of the multiple threat scenarios during Phase I, the IVBSS system failed the first required MT test and passed the second MT test. Table 28 shows the pass/fail results, a brief description, and the initial conditions for both tests. In test 1, the LCW function passed but the FCW function failed in 3 out of 10 runs by about 1 m off the required maximum alert range. Also in this test, the system met its requirement of time between alerts. After system modifications to the LDW system discussed above, the first MT test was re-tested and passed in March 2008 as indicated in Table 29.

Table 28. MT HT Phase I test track results

No	Test	Initial Conditions					Pass/Fail	Test Type
No	Test	SV Speed (mph)	Lateral Speed (m/s)	POV Speed (mph)	apov (g)	RH (m)	Pass/Fail	Test Type
1	Avoid RE with slower POV1 and encounter LC with adjacent POV2	45	0.3	45	0.31	60	FAIL (LCM)	Req
2	Avoid LC with POV2, RE with slowing POV1, and encounter ED toward clear shoulder	45	0.25	45	0.15	45	Pass	Req

Table 29. MT HT Phase I extension track test results, March 2008

No	Test	Initial Conditions					Pass/Fail	Test Type
No	Test	SV Speed (mph)	Lateral Speed (m/s)	POV Speed (mph)	apov (g)	RH (m)	Pass/Fail	Test Type
1	Avoid RE with slower POV1 and encounter LC with adjacent POV2	45	0.3	45	0.31	60	Pass	Req

5.4.2.5. Summary of HT No-Warn Tests

The IVBSS HT platform passed all the no-warn tests during Phase I testing. Table 30 shows a list of the no-warn tests with descriptions, initial conditions, and pass/fail results. After the testing was complete it was determined that NW-7 was not run to the test specifications. NW-7 was rerun during the Phase I Extension. The results of this test are shown in Table 31.

Table 30. Phase I HT no-warn test results

No	Test Description	Initial Conditions					Pass/ Fail	Test Type
No	Test Description	SV (mph)	POV (mph)	Range, RSP1 (m)	SV Lat Speed, (m/s)	Radiu s of Curva ture (m)	Pass/ Fail	Test Type
NW-1	No FCW when SV closely follows POV	40	40	44.8			Pass	Req
NW-2	No FCW when passing stopped POV in adjacent lane on curve	40				285	Pass	Req
NW-3	No FCW when faster POV cuts in front of SV	40	45	15 ± 5			Pass	Req
NW-4	No FCW when passing between two POVs in adjacent lanes	55	30				Pass	Req
NW-5	No LDW with poor lane keeping and barrier on the left	45			0.3		Pass	Req
NW-6	No LCW when SV changes lanes in front of close POV	45	45	10	0.25		Pass	Req
NW-7	No LCW when SV changes lanes while POV is two lanes over	45	45		0.25		Pass	Req

Table 31. Phase I extension HT no-warn test results

No	Test Description	Initial Conditions					Pass/ Fail	Test Type
No	Test Description	SV (mph)	POV (mph)	Range, RSP1 (m)	SV Lat Speed, (m/s)	Radius of Curvat ure (m)	Pass/ Fail	Test Type
NW-7	No LCW when SV changes lanes while POV is two lanes over	45	45		0.25		Pass	Req

The above test results show that the heavy-truck IVBSS satisfies performance guidelines required to proceed to Phase II of the program.

6 DVI and Human Factors Testing

6.1 Overview

The design of an integrated crash warning system such as IVBSS differs significantly from that of a single, standalone system in that the warnings must be distinguishable from one another and not interfere with each other. When multiple warnings are to be presented at the same or almost the same time, the presentation needs to make it easy for the driver to prioritize the warnings, address the most important warnings first, and act in a timely manner. The following objectives drove the design of the DVI and the associated testing: easy detection of and rapid response to the warnings, minimized confusion, and support for prioritization. The DVI simulator and laboratory tests, jury drives, and on-road pilot tests established warning system characteristics that resulted in safe and effective DVIs.

The designs of the DVIs were necessarily constrained by the use of post-production vehicles. For example, there were constraints on where displays would fit into the instrument panel of a Honda Accord EX. On the heavy-truck platform, existing hardware was used, which included a tone generator with limited capabilities, speakers with limitations, and LEDs on the A-pillar. Nevertheless, the DVIs for both the light-vehicle and heavy-truck platforms were designed to provide hardware and software flexibility in the initial prototypes, and a means to record driver and system performance. Thus, early prototypes could be used for human factors evaluation in parallel with other aspects of the IVBSS development.

DVI development and evaluation occurred as a multi-step process beginning with a literature review that informed experiment planning. Small-scale experiments on auditory warning characteristics were followed by major simulator experiments. Finally, the DVIs were evaluated on the road during jury drives with IVBSS team members, personnel from U.S. DOT, and Volpe, while accompanied pilot testing occurred with lay drivers. Each of these steps is detailed below.

Preparation for the DVI simulator testing began with a review of the existing literature. The literature review aided in identifying test methods and conditions to examine, and in providing insights into warning characteristics such as warning modality, multiple alarms, alert reliability, responsiveness, and localization. The literature was not very helpful in predicting which particular warnings would be understood. Furthermore, the literature has concentrated on standalone systems (i.e., what constitutes a good auditory warning regardless of the application) and single warning systems. This makes research on IVBSS, a multiple warning system, unique.

After consideration of the existing literature on warning design (in general and specific to crash warnings for drivers), expert human factors judgment, and discussions with those overseeing the engineering efforts of subsystem development and integration, seven research questions that warranted study were identified by the human factors team. Five experiments (of which the first had five parts) that addressed these seven research questions were designed with particular interest towards recommending how DVIs ought to be implemented in the IVBSS program (Table 32). Those seven questions were:

Q1─Shared Warnings. When and how should warnings be shared or differentiated, e.g., FCW and CSW, LDW and LCM?
Q2─Sequencing/Prioritizing Co-Occurring Warnings. Should warnings occurring at the same time be presented together or with a delay between them?
Q3─ Warning Confusion. Are the warnings in the IVBSS sets confused with one
another?
Q4─Time Course of Driver Actions. What is the process by which drivers respond to warnings?
Q5─Warning Processing Time/Accuracy Tradeoff. How does the tradeoff between warning system processing time (to start to inform the driver) and warning accuracy affect driver responses to warnings?
Q6─Auditory Characteristics of Warnings. How does auditory warning effectiveness vary with warning sound characteristics (loudness, pitch, speed) in the sound environments of each vehicle platform?
Q7─Influence of Pauses and Repetitions. For sounds that involve periods of silence (or pauses), are responses deferred to coincide with silence? What is the optimal number of repetitions?

Table 32. Sequence of experiments

Experiment	Central Theme	Procedure	System
1. Auditory warning characteristics	Q3, Q6, Q7: Characterized sound environment of light vehicle and heavy truck; selected sounds best suited to environment, five subtasks	Jury evaluations1: (subtask 1) of masking of warnings, (2) of sound appropriateness, (4) localization of candidates sounds RT evaluations2 (subtask 3) confusability of ensemble, (5) repeating sounds	All
2. Time course of driver response	Q3, Q4: How people responded (where and when they look) suggested warning presentation modality and content.	Collected eye fixations, steering and brake data, etc. to initial warnings (includes uninformed warnings)	FCW, LDW, CSW, maybe LCM
3. Shared warnings	Q1, Q3: If two warnings (FCW, CSW) lead to the same response, should the warning be the same?	Collected steering and brake data, etc. for shared warnings and unique warnings	All
4. System response time/accuracy tradeoff	Q3, Q5: Warnings that are delayed may be more accurate. What tradeoff is “best?”	Used full set of candidate warnings, vary accuracy and delay of each warning, collect steering and brake data, etc.	All
5. Cooccurring warnings	Q2, Q3: When two warnings occur at the same time, should one be delayed and by how much?	Created situations to trigger two warnings. Sometimes presented both, sometimes presented in priority order, with delays. Collected steering and brake data, etc.	All

¹ In this context, a jury evaluation refers to the use of a panel of experts to perform a task, not lay drivers.
²In the RT (response time) evaluations, sounds were presented and drivers identified which one by pressing one of several buttons, for which the response time was recorded.

Except for most of experiment 1, all experiments were conducted using lay drivers in the UMTRI driving simulator using a passenger car cab.

In the first experiment, which was actually a series of small experiments, subjects rated warnings on various dimensions. Additionally, reaction time tasks were performed to collect data on response times and errors to each of the warning types. These experiments identified warning sounds and characteristics that would be used in subsequent experiments and in the DVI that was developed. All parts of experiment 1 were conducted early in the development process except for subtask 5, which was conducted at the end for practical reasons. Also, as part of this experiment, researchers collected physical measurements of the light-vehicle and heavy-truck cab environments. The human performance experiments were conducted in the laboratory, in the UMTRI driving simulator, and in vehicle cabs.

In experiments 2 through 5, subjects drove in the UMTRI driving simulator while various events occurred (vehicles cut in, lead vehicle braked, lead vehicle changed lanes to reveal parked vehicles, etc.). When these events occurred, one or more of the four warnings (FCW, CSW, LDW, and LCM) triggered, and subjects responded by slowing down, braking, or returning to the lane. In addition to collecting driving performance data (speed, lane position, throttle position, brake on/off, etc.), these experiments gathered subjective data from subjects’ ratings of warnings on various characteristics (loudness, frequency of occurrence, ease of understanding, usefulness, etc.) at various points in time. Within and across experiments, the warning modalities and, in particular, sound characteristics, varied in a systematic manner to examine issues pertaining to simultaneous warnings (not much of a problem), and warning processing delays (150 to 300 ms is acceptable for LDW). One of the more important design recommendations to emerge was to favor one warning for hazards ahead (FCW, CSW) where drivers should respond by braking and steering and a second for lateral hazards (LDW, LCM) where the primary response was steering. (Other alternatives included just presenting a master warning or a unique warning for each hazard.)

In the light-vehicle jury drives, program participants from UMTRI, the U.S. DOT, NIST, and Volpe drove research vehicles equipped with IVBSS over a fixed route on public roads and offered comments about warning system performance. These drives led to changes in the haptic pulse, LDW/LCM warning timing, and the in-vehicle display. The heavy-truck jury drives involved team members who possessed a CDL driving an IVBSS-equipped truck on a test track and on public roads. No changes to the heavy-truck DVI were deemed to be necessary.

The light-vehicle pilot test featured lay drivers who drove a fixed route with an experimenter present in the research vehicle. Despite known problems with the LCM subsystem (which were subsequently corrected) that led to a rather high false warning rate for LDW, drivers reported IVBSS to be intuitive and easy to use. The heavy-vehicle pilot test involved truck drivers and a fixed route. The truck drivers found IVBSS easy to use, but only thought it was somewhat helpful regarding potential conflicts.

Throughout all of these steps, feedback from experimenters to DVI designers was rapid but informal as those who were managing the experiments were also members of the DVI teams. These early insights were key given the short development schedule.

On both vehicle platforms, the primary modality used to warn drivers is auditory, with the addition of some haptic warnings on the light-vehicle platform. The auditory warnings are directional, as they are presented from the location where the threat resides (forward, left, or right of the vehicle). Visual displays are not a source of presenting warnings per se, but they indicate the presence of vehicles in blind spots so that drivers might see those indicators, located in or near the left and right rearview mirrors, prior to initiating a maneuver that would otherwise result in an auditory warning. Visual displays are largely used to convey system status information on both platforms. Haptic warnings that are implemented on the light-vehicle platform consist of a directional vibrating-seat pan to convey cautionary LDW alerts, and a brake pulse that is used in conjunction with an auditory warning to convey imminent FCW and CSW alerts.

With the emphasis on the use of auditory warnings for both platforms, the human factors experiments conducted to support DVI design focused largely on how auditory warning characteristics, and methods of implementing auditory warnings, affect both objective and subjective driver response. Simulator experiments 2 through 5, jury drives, and accompanied pilot tests were conducted during the second year of the IVBSS program. A detailed description and results of each of the studies are described in the IVBSS Human Factors and Driver-Vehicle Interface (DVI) Summary Report .⁶

6.2 Human Factors Experiments

6.2.1 Experiment 1: Auditory Warning Selection

Experiment 1 investigated how auditory warning effectiveness varies with warning sound characteristics. This experiment consisted of five subtasks involving the selection and evaluation of candidate warning sounds for use in IVBSS. The ultimate objective was to produce warning sounds that are reliably heard, differentiated, and responded to in each potential warning condition.

6.2.1.1. Summary Findings

The sound environments in the Honda Accord EX and International 8600 tractor (both environmental noise levels and the types of auditory tones present) were measured. To avoid confusion, masking, and unnecessary startle, IVBSS warning sounds were designed to be a minimum of 80 dB(A) with frequency content in the 1 to 5 KHz range;
The empirical results from subtask 3 suggest that both urgency and annoyance increase as frequency increases, with annoyance increasing more rapidly. Use of high frequencies risks increasing annoyance levels. A 1,000 Hz tone may be considered high with respect to fundamental pitch. This recommendation, however, is not just based on considerations of perceived urgency and annoyance, but also to avoid masking of warnings by background noise;
In comparison to abstract sounds, one set of auditory icons required substantially fewer trials to learn and resulted in substantially shorter reaction times. However, another set of sounds that were modest variants of the auditory icons (and assigned to the same scenarios) were more difficult to learn and produced longer reaction times. Thus, even minor alterations to the sound characteristics of auditory icons can result in markedly different performance;
Neither the addition of noise nor spatial enhancement improved the accuracy or speed of responding to a warning sound. This and other reasons led to not using QSound features in the light-vehicle platform; and
Reaction times increased slightly when warnings had increasing numbers of bursts, numbers of beeps in a burst, or delays between bursts. Based on the response time, pulsed warnings should consist of two bursts of three beeps each, and gaps of approximately 161 ms between bursts.

6.2.2 Experiment 2: Driver Response to Warnings

The focus of experiment 2 was to determine how drivers responded to warnings, including where they looked. Additionally, drivers’ responses to warnings were examined while they were distracted. Finally, this experiment investigated how well drivers understood a candidate set of IVBSS warnings, and whether any were confused or misunderstood. (Note: Experiments 2 through 4 all addressed this question, though it is only listed here as it was this experiment that led to the most profound changes to reduce confusion.)

6.2.2.1. Summary Findings

For all threat types, in most cases drivers were likely to fixate on the area forward of the vehicle (about 65 percent of the time during the baseline periods and 75 percent of the time immediately after a warning), even for lane change-merge (LCM) warnings where the hazard was on the side of the vehicle. There was not, however, a distinctive sequence of glances or a place where drivers consistently looked for each warning, and therefore no strong recommendations were made about where a display should be located;
There were no statistically significant effects associated with distraction; however, the complexity of the basic task meant that many participants were not diligent in completing the distraction task, so that they were not in fact truly distracted. This led to dropping distraction as an experimental manipulation is subsequent experiments;
All of the warnings were rated as somewhat easy to understand with only small differences among them; however, none of the warnings was initially well understood when drivers were uninformed. This led to changes in all the warnings; and
Often scenarios did not occur as planned, sometimes with the warning not triggering as planned and other times triggering when not planned. This was not because the warning systems did not operate as desired, but because driving performance was not completely controllable. However, there were more than enough warnings to analyze.

6.2.3 Experiment 3: Shared Warnings

Experiment 3 addressed how combining warnings, using a singular cue to represent more than one threat scenario, affects (a) driver performance when responding to them and (b) driver ratings of them. Of interest were (a) single (master) warning, (b) dual warnings (simple and hybrid), and (c) multiple warnings (one for each hazard).

6.2.3.1. Summary Findings

No combination of threat scenarios into one or more combined cues − single warning, dual-simple (lateral warning and longitudinal warning), dual-hybrid, or multiple − led to substantially better driver responses (deceleration for FCW and CSW, lateral control for LDW and LCM) than any other combination. In terms for preferences, drivers liked the multiple warnings for four subsystems the least. Given these findings, and the desire to support other warnings not tested, IVBSS used one of the dual-warning approaches.

6.2.4 Experiment 4: System Time or Accuracy Tradeoff

Experiment 4 examined how the tradeoff between warning system processing time (to start to inform the driver) and warning accuracy affect driver responses to warnings.

6.2.4.1. Summary Findings

Subjects did not perceive the difference in warning delays. Therefore, delays (the time between the onset of a threat and the presentation of a warning to a driver) between 150 and 300 ms were deemed acceptable for the LDW algorithm implemented in this experiment.

6.2.5 Experiment 5: Co-Occurring Warnings

Experiment 5 investigated how responses to a single warning differ from responses to two warnings that are co-occurring (simultaneous or nearly simultaneous). Further, presentation schemes for co-occurring warnings were studied. Three prioritization rules were examined. Cooccurring warnings were presented:

Whenever they occurred, even if they occurred simultaneously;
One at a time with higher priority warnings interrupting those of lower priority; and
In sequence of occurrence, with the first warning playing to completion before the second (delayed warning) started.

6.2.5.1. Summary Findings

No single prioritization rule for IVBSS was recommended based on the data collected and, if anything, responding to multiple warnings was not different from responding to single warnings (in terms of speed decrease to forward warnings or lateral position changes for lateral warnings). In part, this was because many of the multiple warnings were driver induced. For example, in responding to a lead vehicle braking, drivers would change lanes, but because they did so without signaling, LDW would trip;
In contrast to other warnings, there was a strong desire for BSD, which was included in the IVBSS set; and
Even at this late stage, drivers were not giving high ratings to the understandability of warnings, so improvements were desired, though no specific suggestions were offered.

6.2.6 Environmental Characterization

The cabin environments of the vehicles used for the two platforms, the Accord EX and an International 8600 series tractor, were characterized, particularly for environmental noise levels and the types of auditory tones that might already exist in the vehicles. The complete characterization is reported in Appendix E of the IVBSS Human Factors and Driver-Vehicle Interface (DVI) Summary Report .⁶

This characterization was required to ensure that auditory warnings developed as a result of the simulator and laboratory testing were sufficiently unique so as not to be confused with existing tones. However, the effects of the environment in which they are implemented can dramatically alter the in situ characteristics. Factors such as the dynamic range of the vehicle’s speakers and sound attenuation due to in-cabin trim can affect the perceived characteristics of auditory signals. Additional work was performed to characterize the visual displays and labeling of controls and displays in the cabins. Every attempt was made to match the existing use of colors, fonts, font sizes, and luminance levels for displays, as all of these characteristics contribute significantly to making IVBSS an integral part of the vehicle from the perspective of the driver.

The characterization of the vehicles that remains to be performed is the anthropometric characterization of the cabins and location of the displays relative to driver models.

6.3 DVI Field Testing

6.3.1 Jury Selection

6.3.1.1. Light-Vehicle Jury Drives

For the light-vehicle platform, a fully-integrated IVBSS system was evaluated by human factors, safety, and warning system experts who were all program participants, including experts from UMTRI, U.S. DOT, NIST, and Volpe who drove the light vehicle on a prescribed route with prescribed maneuvers. Feedback was entirely subjective.

6.3.1.1.1. Summary Findings

One significant issue identified in the light-vehicle jury drives was an inter-vehicle variation in the haptic brake pulse used for FCW and CSW warnings. There were several cases in which the brake pulse was not noticed. In order enhance the effectiveness of the brake pulse, a two-stage pulse was implemented. First the brakes are pre-charged for a short duration and then the actual brake pulse is applied. This removes much of the variation observed during the jury drives. Furthermore, the magnitude of the brake pulse was increased to enhance driver awareness of the pulse.
Also as a result of comments received during the jury drives, the possibility of adding icons to the central console display to signify the occurrence of alerts, simultaneous warnings, and subsystem availability was excluded. Almost all participants failed to notice the icons at all. Therefore, a textual display was deemed sufficient and more straightforward.
Two tones that could serve to indicate a lateral threat were examined in the jury drives and one was selected as the preferred choice. The length of tones was deemed adequate, so it was decided to continue with the 700 ms warnings to drivers. The timing of the LDW/LCM warnings that were experienced during the jury drives was generally perceived as being late. As a result, the onset timing was adjusted inward for both subsystems, i.e., the lateral drift warnings were given 10 cm earlier in the departure sequence to increase the reaction time given to the driver to respond to the threat.

6.3.1.2. Heavy-Truck Jury Drives

The heavy-truck jury drives involved five team members who hold CDLs and took place both on a test track and public roads. The intent of the on-road tests was to elicit lower priority warnings (e.g., FCW headway warnings of 2 and 3 seconds) while scripted maneuvers were carried out on the test track to elicit higher priority warnings (e.g., FCW imminent).

6.3.1.2.1. Summary Findings

The threshold for changes to the heavy-truck DVI was set very high given that the VORAD system, which serves as the primary element in the heavy-truck DVI, had previously been subjected to several evaluations and the associated hardware was not as flexible as that of the light-vehicle platform. No changes were deemed necessary.

6.3.2 Pilot Testing

6.3.2.1. Light-Vehicle Pilot Testing

The light-vehicle pilot testing sought to gain feedback and first impressions from 18 laypeople while driving a vehicle equipped with a developmental version of IVBSS. This evaluation was performed along a 90-mile prescribed route with a researcher present. Objective measures of warning type and frequency were collected, as was subjective data on preliminary acceptance.

6.3.2.1.1. Summary Findings for Light-Vehicle Pilot Testing

Across all drivers, 379 warnings were issued for 1,528 cumulative miles of pilot testing. Each driver received an average of 21 warnings. The most common type of warning, imminent LDW, was dominated by false warnings (e.g., drifting toward a lane boundary while IVBSS mistakenly identified an adjacent threat). The false warning rate for LDW was 12.8 warnings per 100 miles, which highly influenced an overall false warning rate of 13 warnings per 100 miles. Scheduled changes to the LCM subsystem (that provide AMR data to LDW) will significantly reduce false warnings. The second most common warning was cautionary LDW (e.g., lane changes with no turn signal). The frequency of FCW and CSW warnings was relatively low.

Drivers subjectively reported IVBSS to be intuitive and easy to use. Most drivers stated they received warnings with about the right frequency, and on average were not distracted by IVBSS warnings. The warnings were also deemed to be helpful in identifying potential conflicts. However, the high false warning rate associated with the known LDW problems did lead to driver uncertainty about what each warning was intended to represent. Overall, when compared to the subjective results from previous field evaluations of crash warning systems (RDCW and ACAS), the results are on par despite the recognized need to correct the LDW subsystem.

6.3.2.2. Heavy-Truck Pilot Testing

Similar to the light-vehicle pilot testing, heavy-truck pilot testing sought to gain feedback and first impressions of a developmental version of IVBSS from five commercial truck drivers. This evaluation was performed along a 52-mile prescribed route with a researcher present. Objective measures of warning type and frequency were collected, as was subjective data on preliminary acceptance.

6.3.2.2.1. Summary Findings for Heavy-Truck Pilot Testing

The five drivers received a total of 49 warnings. The average number was 10 warnings per driver, with one driver receiving only 3 warnings and another receiving 15 warnings. As far as the experimenter could tell, there was only 1 intentional warning.

LCMs were by far the most common type of warning, comprising 61 percent of the total number of warnings. The frequency of FCW and LDW alerts was fairly low, though almost all of the FCW alerts were false warnings.

In general, three of the five drivers had very positive overall feedback, while two had specific concerns that made them generally dislike the system. The negative comments were generally limited to the issue of false or unnecessary alerts, with one driver having a very low tolerance for false alerts. The drivers found IVBSS easy to use, but only thought it was somewhat helpful regarding potential conflicts. On average, drivers felt that they received warnings with about the right frequency. There was also general agreement with the statement “I always understood why IVBSS was providing a warning.” Finally, on average, drivers were not distracted by IVBSS warnings.

In terms of the look and feel of the system, the drivers generally were not distracted by the displays, although one driver commented that the side-display LEDs were too bright at night, and one driver said he did not like the simulated horn sound warning, as it sounded too similar to a real horn.

6.4 Phase II Next Steps

During Phase II of the IVBSS program, extended pilot testing will be undertaken; the outcome of this testing is likely to provide driver feedback that will help to make further subtle refinements to the DVIs on both the light-vehicle and heavy-truck platforms. This is most likely to occur with the auditory warnings or visual system state messages. Prolonged exposure to the auditory warnings might alter the team’s understanding of potentially annoying warning characteristics when experienced for extended periods, particularly on the heavy-truck platform where drivers will spend several hours every day driving. However, the flexibility built into the prototype systems to allow the human factors testing to proceed in parallel with subsystem development will also readily allow for minor DVI modifications.

Figure 79 displays the schedule for extended pilot testing.

Figure 79. Schedule for Phase II extended pilot testing

Figure 79. Schedule for Phase II extended pilot testing

7 Field Operational Test Preparation

7.1 Data Acquisition System

7.1.1 Task overview

The data system development activity (Task 1.j) is to create hardware and software and to deploy networking operations to capture data from onboard IVBSS vehicles during both Phase I development and verification efforts and Phase II FOT experiments. This activity includes:

Data capture to support Phase I engineering development of the IVBSS systems on the light-vehicle and heavy-truck platforms;
Data capture during Phase I verification testing;
Data capture during pilot testing in Phases I and II;
Data capture during both the extended pilot FOT and the final FOT during Phase II;
Data capture and transfer to support remote monitoring of the test fleets in order to ensure proper performance of the IVBSS system and appropriate usage of the test vehicles by the test participants (both project phases);
Creation and management of data archives from both the Phase I development and testing efforts and the major testing efforts in Phase II;
Support of analysis task needs for the UMTRI project team during all phases of the project;
Sharing of key elements of the data archive with the independent evaluator and other
representatives identified by the U.S. DOT;
Enabling remote access by the entire UMTRI team to data collected during development; and
Enabling the U.S. DOT to remotely monitor in near real time the progress of the FOT fleet, including vehicle usage and system performance.

The data system can be described as two integrated systems. The first system is the onboard data acquisition system (DAS) module that collects data generated by IVBSS, the subject vehicle, and “FOT sensors” (sensors and devices that serve the data collection purposes but do not contribute to the IVBSS functionality). The second system is the data management and analysis system (DMAS), which is a set of software, networking, and hardware elements that are used to manage the DAS units remotely, to manage data already onboard the DAS units, to load and manage archived data into enterprise-grade servers, and to enable post-processing and visualization of data. The DMAS represents major innovation in networking to support such projects.

There will be three generations of DAS modules and two generations of the DMAS during the project. The three generations of DAS modules include an initial deployment of modified units from previous field operational tests that have supported the engineering development efforts at Eaton, Cognex, and Visteon during the first phase of the project. The second generation of DAS modules that is being completed now is the prototype DAS units, which includes the same hardware and software components as the DAS units that will eventually be fielded in Phase II for both the light-vehicle and heavy-truck platforms. The third generation of DAS modules will be the FOT DAS units, which will be built and used in Phase II with finalized hardware packaging and wireless communications.

There are two generations of DMAS. The first was developed during the second year of the project and uses a virtual private network (VPN) to connect servers at UMTRI, Eaton, Visteon, and Cognex. UMTRI is able to remotely administer and manage data on those servers, as well as on remote DAS modules installed on vehicles at the other facilities. The second generation of the DMAS for Phase II operation will use essentially the same concept except that the remote server location will be the heavy-truck fleet terminal.

7.1.2 Overview of Onboard DAS Capabilities

The DAS systems onboard the light-vehicle and heavy-truck platforms are almost identical. The differences in hardware include different wireless communication hardware and interface hardware (since the heavy trucks include a J1939 bus). The primary sources of data include:

The IVBSS data buses (three CAN buses on the light-vehicle platform, and two CAN
buses and a J1939 bus on the heavy-truck platform);
Camera signals from the LDW camera on both platforms;
Camera signals from four cameras that are installed only for FOT analysis purposes;
FOT sensors, including accelerometers and GPS on both units, and steering wheel angle on the heavy vehicle system;
Battery power and ignition switch state;
Remote wireless data transfer (cellular data network connection for the light-vehicle
platform and wireless LAN for the heavy-truck platform); and
Ethernet connection for downloading data and communicating remotely (via the VPN
network) to the DAS module.

The onboard DAS module will collect data on the following types of information:

Driver’s vehicle-control activity (e.g., brake switch, throttle, wipers, turn signals, lights, etc.);
Subject vehicle state (e.g., speed);
IVBSS intermediate information;
IVBSS crash alerts, advisories, and system status information;
Driver inputs to IVBSS (e.g., driver preference for alert timing);
GPS information;
All radar information (seven radars on the light-vehicle platform and six radars on the
heavy-truck platform);
Video information from five cameras per platform (forward scene, driver’s face, cabin activity, external scene to the left-side and the rear, external scene to the right-side and rear of the vehicle); and
Environmental information (e.g., road type, ambient temperature, precipitation, lighting, etc.).

Numerical data will be collected at rates of 10 to 100 Hz. Video data will be collected at rates up to 10 Hz, and will use separate compression of each of the video streams using MPEG-4 compression. In the first phase of this project, the collection of the numerical, radar, and video data in the manner intended for the FOT has been demonstrated. The remaining challenge is to completely validate the numerical data being collected and tuning the sampling and collection of video data to capture the most information about the driving context and system performance, while managing the data volumes that video collection can create.

Figure 80. Schematic of data movement paths

Figure 80. Schematic of data movement paths

Figure 80 shows a simplified view of the paths for data movement associated with the data management and analysis system. Data from vehicles can be transferred into the data archive by wireless communications or direct downloads at either UMTRI or remote locations, such as the development team’s facility or the heavy-truck fleet. Conversely, UMTRI can remotely reconfigure the DAS at those locations, enabling iteration on the definition of the data archive and maximizing efficiency of operations.

7.1.3 DAS Status

The first-generation development DASs to support Phase I development efforts were used in Phase I, including with test-track and on-road verification testing. The prototype DAS hardware (which is all new hardware from previous generation systems) has been checked out in a vehicle environment and in fact a simpler single-CPU system with the same hardware is being used in an ongoing experiment. The first final-packaging prototypes for the IVBSS platforms are being built and will be completed before the end of the Phase I extension. Since these prototypes are much closer to the FOT design than previously planned, there are only a few significant issues to be determined before FOT DAS buildup can begin.

7.1.4 DMAS Status

The first-generation DMAS has been operational since the fall of 2007. The next generation, to be incorporated with a remote server at the heavy-truck terminal, will be essentially the same system at a different location. The servers have been purchased and set up and are being tested with vehicle data and database applications. The final step in the DMAS process will be determining the nature and implementation of the wireless tracking of the heavy trucks, as well as the manner in which data is downloaded from the heavy trucks and in which the onboard system memory is erased.

8 Conclusions

Phase I of the IVBSS program achieved all of its stated goals, albeit with a time extension. The successful completion of Phase I is pivotal to the success of the IVBSS program as it is the foundation upon which the remainder of the program will be based. As such, sound engineering practices and program planning were necessary to ensure satisfactory IVBSS vehicle performance into in Phase II. Overall, as a result of considerable effort by all team members, IVBSS is well positioned to proceed toward, and successfully conduct, a field operational test in Phase II.

In the first year of Phase I, the following program accomplishments were achieved:

System architecture development was completed, including partitioning the IVBSS system into its major subsystems, specifying sensors and software, and identifying hardware interfaces and communication protocols;
Sensor suites were identified, with detailed descriptions and specifications of all sensors;
The development of the driver-vehicle interfaces (DVI) and a series of human factors tests began. Extensive engineering development also went into providing prototype DVI hardware to support IVBSS evaluation; and
Development began on the functional requirements and system performance
guidelines to describe both the IVBSS system functionality and the performance
expected from the integrated system.

In the second year of Phase I, including the extension period, the following accomplishments were achieved:

A new truck manufacturer and trucking fleet were added to the program to replace a previous partner that withdrew from the program. The trucking fleet will serve to operate the IVBSS equipped heavy trucks during the extended pilot and field operational testing
DVI development and testing were completed and the results published in a public report. DVIs for both platforms were specified and implemented into prototype vehicles.
System performance guidelines and functional requirements were distributed to industry stakeholders for comment and later published .
Multiple prototype vehicles were built and evaluated.
Extensive program outreach to stakeholders included two public meetings, numerous presentations and booths at key industry meetings, several one-on-one meetings, and the loan of prototype light vehicles for gaining firsthand experience with the IVBSS system.
Jury and pilot testing was performed.
Verification test plans were developed in close collaboration with the U.S. DOT and its partners. The verification tests, which served to demonstrate the effectiveness, repeatability and general readiness of IVBSS for field operational testing, were conducted on test tracks and on-road. All tests were passed and the results reported.
Field operational test preparation continued, including the design and development of prototype data acquisition systems and the selection of data acquisition sensors (in-cabin video cameras, microphone, etc.). Vehicles with which to conduct the anticipated field operational test were secured, and a field operational test plan was submitted.

The UMTRI-led team was fortunate to have worked closely with the U.S. DOT and its partners throughout Phase I of the program, particularly in the development of verification test procedures, and wishes to acknowledge the extensive efforts and contributions made by representatives of NHTSA, ITS JPO, Volpe, NIST, and FMCSA.

9 References

Brown, J., McCallum, M., Campbell, J., & Richard, C. 2007. Integrated Vehicle-Based Safety System Heavy Truck Driver-Vehicle Interface (DVI) Specifications, Final Report. UMTRI-2008-27. Seattle, WA: Battelle Center for Human Performance and Safety.
Campbell, J. L., Richard, C. M., Brown, J. L., & McCallum, M. 2006. Crash Warning System Interfaces: Human Factors Insights and Lessons Learned, Final Report. Seattle, WA: Battelle Center for Human Performance and Safety.
Catchpole, K., McKeown, J. D., & Withington, D. J. 2004. Localizable Auditory
Warning Pulses. Ergonomics, 47(7), 748-771.
Ervin, R.; Sayer, J.; LeBlanc, D.; Bogard, S.; Mefford, M. L.; Hagan, M.; Bareket, Z.; & Winkler, C. 2005. Automotive Collision Avoidance System (ACAS) Field Operational Test – Methodology and Results. NHTSA Report HS 809 901. Washington, DC: National Highway Traffic Safety Administration.
General Motors & Delphi Electronic Systems. 2005. Automotive Collision Avoidance System (ACAS) Field Operational Test – Final Program Report. NHTSA technical report DOT HS 809 866. Washington, DC: National Highway Traffic Safety Administration.
Green, P., Sullivan, J., Tsimhoni, O., Oberholtzer, J., Buonarosa, M. L., Devonshire, J., Schweitzer, J., Baragar, E., & Sayer, J. 2008. Integrated Vehicle-Based Safety Systems (IVBSS): Human Factors and Driver-Vehicle Interface (DVI) Summary Report. NHTSA DOT HS 810 905. Washington, DC: National Highway Traffic Safety Administration.
Houser, A., Pierowicz, J., & Fuglewicz, D. 2005. Concept of Operations and Voluntary Operational Requirements for Lane Departure Warning Systems (LDWS) On-Board Commercial Motor Vehicles. FMCSA. FMCSA-MCRR-05-005, DTMC75-03-F-0087. Washington, DC: Federal Motor Carrier Safety Administration.
Houser, A., Pierowicz, J., & McClellan, R. 2005. Concept of Operations and Voluntary Operational Requirements for Forward Collision Warning Systems (CWS) and Adaptive Cruise Control (ACC) Systems On-Board Commercial Motor Vehicles. FMCSA-MCRR05-007, DTMC75-03-F-0087. Washington, DC: Federal Motor Carrier Safety Administration.
International Organization for Standardization. 2002. Intelligent Transportation Systems – Forward Vehicle Collision Warning Systems – Performance Requirements and Test Procedures. Draft international standard ISO/DIS 15623.
International Organization for Standardization. 2004: Intelligent transportation systems – lane departure warning systems– performance requirements and test procedures. Draft international standard ISO/DIS 17361.
International Organization for Standardization. 2006. Intelligent Transportation Systems – Lane Change Decision Aid Systems – Performance Requirements and Test Procedures. Draft international standard ISO/DIS 17387.
IVBSS Project Team. 2007. Preliminary Functional Requirements for the Integrated
Vehicle-Based Safety System (IVBSS) – Light-Vehicle Platform. Ann Arbor, MI:
University of Michigan Transportation Research Institute.
IVBSS Project Team. 2007. Preliminary Functional Requirements for the Integrated Vehicle-Based Safety System (IVBSS) – Heavy-Truck Platform. Ann Arbor, MI: University of Michigan Transportation Research Institute.
IVBSS Project Team. 2007. Preliminary Performance Guidelines for a Prototype Integrated Vehicle-Based Safety System (IVBSS) – Light-Vehicle Platform. Ann Arbor, MI: University of Michigan Transportation Research Institute.
IVBSS Project Team. 2007. Preliminary Performance Guidelines for a Prototype Integrated Vehicle-Based Safety System (IVBSS) – Heavy-Truck Platform. Ann Arbor, MI: University of Michigan Transportation Research Institute.
Kiefer, R., Cassar, M., Flannagan, C., LeBlanc, D., Palmer, M., Deering, R., & Shulman, M. 2003. Forward Collision Warning Requirements Project Final Report – Task 1. NHTSA Report HS 809 574. January 2003. Washington, DC: National Highway Traffic Safety Administration.
Kiefer, R., LeBlanc, D., Palmer, M., Salinger, J., Deering, R., & Shulman, M. 1999. Development and Validation of Functional Definitions and Evaluation of Procedures for Collision Warning/Avoidance Systems. NHTSA report HS 808 964. Washington, DC: National Highway Traffic Safety Administration.
LeBlanc, D., Bezzina, D., Tiernan, T., Freeman, K., Gabel, M., and Pomerleau, D. 2008. Performance Guidelines for a Prototype Integrated Vehicle-Based Safety System (IVBSS) – Light-Vehicle Platform. Ann Arbor, MI: University of Michigan Transportation Research Institute.
LeBlanc, D., Sayer, J., Winkler, C., Bogard, S., Devonshire, J. Mefford, M., Hagan, M. L., Bareket, Z., Goodsell, R., & Gordon, T. 2006. Road Departure Crash Warning System (RDCW) Field Operational Test – Final Report. NHTSA. Washington, DC: National Highway Traffic Safety Administration.
LeBlanc, D., Sayer, J., Winkler, C., Bogard, S., Devonshire, J. Mefford, M., Hagan, M. L., Bareket, Z., Goodsell, R., & Gordon, T. 2006. Road Departure Crash Warning System Field Operational Test – Methodology and Results. Report No. UMTRI-2006-9-1. Ann Arbor, MI: University of Michigan Transportation Research Institute.
Najm, W. G., & Smith, J.D. 2007. Development of Crash Imminent Test Scenarios for Integrated Vehicle-Based Safety Systems (IVBSS). DOT VNTSC-NHTSA-07-01, DOT HS 810 757.Washington DC: National Highway Traffic Safety Administration.
NHTSA, “Preliminary Assessment of Crash Avoidance Systems Benefits”, Version II, Chapter 3, NHTSA Benefits Working Group. December 1996. Washington, DC: National Highway Traffic Safety Administration.
Nowakowski, C., Friedman, D., & Green, P. 2001. Cell Phone Ring Suppression and HUD Caller ID: Effectiveness in Reducing Momentary Driver Distraction Under Varying Workload Levels. UMTRI-2001-29. Ann Arbor, MI: University of Michigan Transportation Research Institute.
Pomerleau, D., & Everson, J. Run-Off-Road Collision Avoidance Using IVHS Countermeasures – Final Report. NHTSA Report DOT HS 809 170, December 1999. Washington, DC: National Highway Traffic Safety Administration.
Pomerleau, D. Kumar, P., Everson, J., Lazofson, L., & Kopala, E. 1999. Run-off-Road Collision Avoidance using IVHS Countermeasures. NHTSA technical report DOT HS 809 170. Washington, DC: National Highway Traffic Safety Administration.
Talmadge, S., Chu, R., Eberhard C., Jordan K., & Moffa, P. 2001. Development of Performance Specifications for Collision Avoidance Systems for Lane Change Crashes. NHTSA technical report. Washington, DC: National Highway Traffic Safety Administration.
Tan, A. K., & Lerner, N. D. 1995. Multiple Attribute Evaluation of Auditory Warning Signals for In-Vehicle Crash Avoidance Warning Systems. Washington, DC: National Highway Traffic Safety Administration.
Thorpe, C. E. 2002. Side Collision Warning System (SCWS) Performance Specifications for a Transit Bus. Federal Transit Administration under PennDOT, 62N111, Project TA 34. Washington, DC: Federal Transit Administration.
United States Department of Transportation. 2005. IVBSS Program Plan. Washington, DC: Department of Transportation. Retrieved June 18, 2007, from http://www.its.dot.gov/ivbss/ivbss_workplan.htm.
University of Michigan Transportation Research Institute (UMTRI). 2007. Integrated Vehicle-Based Safety Systems First Annual Report. NHTSA DOT HS 810 842. Washington, DC: National Highway Traffic Safety Administration.
Young, S. K., Eberhard, C.A., & Moffa, P. J. 1995. Development of Performance Specifications for Collision Avoidance Systems for Lane Change, Merging and Backing. TRW Space and Defense. NHTSA Report. DOT HS 808 432. Washington, DC: National Highway Traffic Safety Administration.

Appendix A: Complete Project Schedule

Figure 81.Complete project schedule for light-vehicle platform

Figure 81.Complete project schedule for light-vehicle platform

Figure 82. Complete project schedule for heavy-truck platform

Appendix B: Driver-Vehicle Interface Warning Sounds

B.1 Existing Sounds

Examples of sounds tested on the 2007 Accord EX include:

Safety belt reminder
Key in ignition
Parking
Lights on; door open (2048 Hz followed by 1650 Hz)

B.2 Experiment E1.3—Warning Suites

Three candidate suites of four warning sounds were investigated for learnability, confusability, and response efficiency.

Subsystem	Hybrid Auditory Icons (Urgent)	Hybrid Auditory Icons (Lower Urgency)	Abstract Sounds
FCW
LCM
CSW
LDW

Integrated Vehicle-Based Safety Systems (IVBSS) Phase I Interim Report