Integrated Vehicle-Based Safety Systems

First Annual Report

Prepared by
The University of Michigan Transportation Research Institute
2901 Baxter Road, Ann Arbor, Michigan 48109-2150
for
U.S. Department of Transportation
Cooperative Agreement DTNH22-05-H-01232
June 19, 2007

Technical Report Documentation Page

1. Report No. DOT HS 810 842	2. Government Accession No.			3. Recipient's Catalog No.
4. Title and Subtitle Integrated Vehicle-Based Safety Systems First Annual Report				5. Report Date
				6. Performing Organization Code
7. Author(s) University of Michigan Transportation Research Institute (UMTRI)				8. Performing Organization Report No.
9. Performing Organization Name and Address University of Michigan Transportation Research Institute (UMTRI) 2901 Baxter Road Ann Arbor, MI 48109-2150				10. Work Unit No. (TRAIS)
				11. Contract or Grant No. Cooperative Agreement DTNH22-05-H-01232
12. Sponsoring Agency Name and Address U.S. Department of Transportation National Highway Traffic Safety Administration 1200 New Jersey Avenue, SE Washington, DC 20590				13. Type of Report and Period Covered Progress Report November 2005 – December 2006
				14. Sponsoring Agency Code Office of Human Vehicle Performance Research – Intelligent Technologies Research Division, NVS-332
15. Supplementary Notes
16. Abstract The IVBSS program is a four-year, two phase cooperative research program being conducted by an industry team led by the University of Michigan Transportation Research Institute (UMTRI). The program began in November 2005 and will continue through December 2009 if results from vehicle verification tests conducted in the second year of the program indicate that the prototype system meets its performance guidelines and is safe for use by lay drivers in a field operational test planned for July 2008. The decision to execute Phase II of the program will take place in December 2007. The goal of the IVBSS program is to assess the safety benefits and driver acceptance associated with a prototype integrated crash warning system designed to address rear-end, road departure and lane change/merge crashes on light vehicles and heavy commercial trucks. This report describes accomplishments and progress made during the first year of the program (November 2005-December 2006). Activities during the first year focused on system specification, design and development and construction of the prototype vehicles.
17. Key Word Vehicle safety research, crash avoidance research, verification testing, collision avoidance, crash warning systems.			18. Distribution Statement Document is available to the public through the National Technical Information Service, Springfield, Virginia 22161
19. Security Classif. (of this report) Unclassified		20. Security Classif. (of this page) Unclassified			21. No. of Pages 116	22. Price

Table of Contents

1 Executive Summary

1.1 Introduction and Background

1.1.1 Crash Problem

1.1.2 IVBSS Program Plan

1.1.3 Phase I – IVBSS Development

1.1.4 Phase II – IVBSS Deployment and Analysis

1.2 First Year Accomplishments

1.2.1 Systems Architecture Development

1.2.2 Sensor Suite Identification

1.2.3 DVI Option Space and Testing

1.2.4 Preliminary Functional Requirements and Performance Guidelines

1.3 First Year Summary

2 Introduction

2.1 Crash Problem

2.2 Program Purpose

2.3 Previous Countermeasure Development

2.4 Expected Benefits of an Integrated System

2.5 Program Approach

2.5.1 IVBSS Team Membership

2.5.2 Structure of the Program

2.6 First Year Accomplishments

2.7 Report Structure

3 Light-Vehicle Platform

3.1 Functional Requirements and System Architecture

3.1.1 Overview

3.1.2 Functional Requirements

3.1.3 System Architecture

3.1.4 Second Year Activities and Schedule

3.2 System Design, Development, and Integration

3.2.1 Overview

3.2.2 Design

3.2.3 Development

3.2.4 Integration

3.2.5 Second Year Activities and Schedule

3.3 Development of Performance Guidelines

3.3.1 Overview

3.3.2 Integrated System Performance Guidelines

3.3.3 Second Year Activities and Schedule

3.4 Subsystem Development

3.4.1 Overview

3.4.2 Subsystem Descriptions and Sensor Suite

3.4.3 Second Year Activities and Schedule

3.5 Development of Driver-Vehicle Interface

3.5.1 Overview

3.5.2 Light-Vehicle DVI Option Space

3.5.3 Second Year Activities and Schedule

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

3.6.1 Overview

3.6.2 Light-Vehicle Prototype Build Plan

3.6.3 Second Year Activities and Schedule

4 Heavy-Truck Platform

4.1 Functional Requirements and System Architecture

4.1.1 Overview

4.1.2 Functional Requirements

4.1.3 System Architecture

4.1.4 Second Year Activities and Schedule

4.2 System Design, Development, and Integration

4.2.1 Overview

4.2.2 Design

4.2.3 Development

4.2.4 Integration

4.3 Development of Performance Guidelines

4.3.1 Overview

4.3.2 Integrated System Performance Guidelines

4.3.3 Second Year Activities and Schedule

4.4 Subsystem Development

4.4.1 Overview

4.4.2 Subsystem Descriptions and Sensor Suite

4.4.3 Second Year Activities and Schedule

4.5 Development of Driver-Vehicle Interface

4.5.1 Overview

4.5.2 Heavy-Truck DVI Option Space

4.5.3 Second Year Activities and Schedule

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

4.6.1 Overview

4.6.2 Heavy-Truck Prototype Build Plan

4.6.3 Second Year Activities and Schedule

5 Development of Verification Test Procedures and Phase I Testing

5.1 Overview of the Verification Test Procedures

5.2 Status of Verification Test Plan

5.3 Vehicle and Hardware Descriptions

5.4 Summary of Verification Tests

5.4.1 Rear-End Crash Threat Tests

5.4.2 Lane-Change Crash Threat Tests

5.4.3 Road Departure Crash Threat Tests

5.4.4 Multiple-Threat Tests

5.4.5 No-Warn Threat Tests

5.5 Verification Test Schedule

5.6 Verification Test Schedules (Track and Road)

5.7 Second Year Activities and Schedule

6 DVI and Human Factors Simulator/Laboratory Testing

6.1 Overview

6.2 Experiments

6.2.1 E1: Auditory Warning Selection

6.2.2 E2: Time Course for Various Test Conditions

6.2.3 E3: Shared Warnings

6.2.4 E4: System Time/Accuracy Tradeoff

6.2.5 E5: Co-Occurring Warnings

6.2.6 Environmental Characterization

6.2.7 Jury Selection

6.2.8 Pilot Testing

6.3 Accomplishments

6.4 Second Year Activities and Schedule

7 Field Operational Test Preparation

7.1 Data Acquisition System

7.1.1 Overview

7.1.2 Status of the Prototype DASs

7.1.3 Prototype DAS Delivery Schedule

7.1.4 Field Test DAS Development

7.2 Second Year Activities and Schedule

8 Conclusions

9 References

Appendix A: Complete Project Schedule

Appendix B: Driver-Vehicle Interface Warning Sounds

List of Figures

Figure 1. Breakdown of crash types in the United States (2003)
Figure 2. Appproximate timing for IVBSS vehicle development and testing
Figure 3. Major IVBSS program tasks
Figure 4. Breakdown of crash types in the United States (2003)
Figure 5. Organizational structure of IVBSS partnership team
Figure 6. Overall timeline for IVBSS Phase I and Phase II
Figure 7. Systems engineering process for the light-vehicle platform
Figure 8. High-level system functional model
Figure 9. Mid-level system functional model showing selected IVBSS components
Figure 10. Light-vehicle functional partitioning
Figure 11. IVBSS system architecture
Figure 12. Light-vehicle schedule for functional requirements and system architecture
Figure 13. Overall light-vehicle development plan
Figure 14. Light-vehicle schedule for performance guideline development
Figure 15. Light-vehicle sensor coverage overview
Figure 16. Forward-looking LDW camera system hardware
Figure 17. LDW forward camera mounting location
Figure 18. High-level LDW software overview
Figure 19. Low sun angle tests of old CCD and new CMOS cameras
Figure 20. LDW camera and processor packaging, up close and mounted on the windshield
Figure 21. Concept of operations for arbitration
Figure 22. Light-vehicle schedule for subsystem development
Figure 23. Driver-vehicle interface block diagram
Figure 24. IVBSS module, sensor, and camera placement in vehicle
Figure 25. LCM short-range radar sensors
Figure 26. Schedule for light-vehicle system integration and prototype building
Figure 27. Schedule for light-vehicle verification testing
Figure 28. System engineering process for the heavy-truck platform
Figure 29. Heavy-truck sensor suite overview
Figure 30. Schematic diagram of the system hardware architecture
Figure 31. Heavy-truck schedule for functional requirements and system architecture
Figure 32. Overall heavy-truck development plan flow
Figure 33. Lateral-drift crash alert timing concepts
Figure 34. Heavy-truck schedule for performance guideline development
Figure 35. “Big Red” with M/A-Com radar and camera mounting
Figure 36. M/A-Com radar mounting and rear radar (sufficient) coverage
Figure 37. Side vision detection results for moving vehicles and stationary targets
Figure 38. Heavy-truck schedule for subsystem development
Figure 39. Heavy-truck DVI space in truck cockpit
Figure 40. Suburban mule vehicle with trailer
Figure 41. Suburban mule vehicle with DVI
Figure 42. Schedule for heavy-truck system integration and prototype building
Figure 43. Rear-end crash scenario 1
Figure 44. Rear-end crash scenario 2
Figure 45. Rear-end crash scenario 3
Figure 46. Rear-end crash scenario 4
Figure 47. Rear-end crash scenario 5
Figure 48. Rear-end crash scenario 6
Figure 49. Rear-end crash scenario 7
Figure 50. Rear-end crash scenario 8
Figure 51. Rear-end crash scenario 9
Figure 52. Rear-end crash scenario 10
Figure 53. Rear-end crash scenario 11
Figure 54. Rear-end crash scenario 12
Figure 55. Lane-change crash scenario 1
Figure 56. Lane-change crash scenario 2
Figure 57. Lane-change crash scenario 3
Figure 58. Lane-change crash scenario 4
Figure 59. Lane-change crash scenario 5
Figure 60. Road departure crash scenario 1
Figure 61. Road departure crash scenario 2
Figure 62. Road departure crash scenario 3
Figure 63. Road departure crash scenario 4
Figure 64. Road departure crash scenario 5
Figure 65. Road departure crash scenario 6
Figure 66. Road departure crash scenario 7
Figure 67. Road departure crash scenario 8
Figure 68. Multiple-threat crash scenario 1
Figure 69. Multiple-threat crash scenario 2
Figure 70. No-Warn threat crash scenario 1
Figure 71. No-Warn threat crash scenario 2
Figure 72. No-Warn threat crash scenario 3
Figure 73. No-Warn threat crash scenario 4
Figure 74. No-Warn threat crash scenario 5
Figure 75. No-Warn threat crash scenario 6
Figure 76. No-Warn threat crash scenario 7
Figure 77. No-Warn threat crash scenario 8
Figure 78. Light-vehicle verification test procedures and Phase I testing
Figure 79. Heavy-truck verification test procedures and Phase I testing
Figure 80. Average ranked urgency by scenario (lower numbers indicate greater urgency)
Figure 81. Schedule for development of driver-vehicle interface
Figure 82. Schedule for development of data acquisition system
Figure 83. Onboard DAS module and its interfaces
Figure 84. Schematic of data movement paths
Figure 85. Milestones and deliverables undertaken in year 1 (part 1)
Figure 86. Milestones and deliverables undertaken in year 1 (part 2)
Figure 87. Milestones and deliverables undertaken in year 1 (part 3)

List of Tables

Table 1. Light-vehicle IVBSS sensor suite versus warning function
Table 2. Preliminary crash alerts for the light-vehicle platform
Table 3. Preliminary advisories for the light-vehicle platform
Table 4. Scenario classification analysis matrix
Table 5. Heavy-truck IVBSS sensor suite versus warning function
Table 6. Support vehicles for mule activity and prototype use in Phase I
Table 7. IVBSS heavy-truck DVI warning strategy space
Table 8. Sequence of experiments
Table 9. Generations of DAS modules and DMAS networks

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 Requirements Management program
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
LFAD	Light-vehicle module for LCM, FCW, Arbitration, and DVI
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
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 System 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 the U.S. DOT 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. 26 27 28 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 of 24 months each. The UMTRI-led team is responsible for the design, build, and field-testing of the prototype integrated crash warning systems. This report summarizes work performed during the first year of the IVBSS program, and discusses contributions by UMTRI and its team members, emphasizing the design and development of the integrated system.

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.

• Forward crash warning provides warnings to drivers to assist them in avoiding or mitigating rear-end crashes with other vehicles.
• Lateral drift warning consists of a system that warns drivers that they may be drifting inadvertently from their lane or departing the roadway. The light-vehicle platform also includes a curve speed warning subsystem.
• Curve-speed warning warns drivers that they may be driving too quickly into an upcoming curve and as a result might lose control and depart the roadway.
• Lane-change/merge warning warns drivers of possible unsafe maneuvers based on adjacent or approaching vehicles in adjacent lanes, and includes full-time side-object-presence indicators.

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. 18 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. Figure 1 illustrates the crash problem for the three major crash types addressed in the IVBSS program for both light vehicles and heavy commercial trucks.

Figure 1. Breakdown of Crash Types in the United States (2003)

All the 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, for example, have addressed forward crash warning, 3 4 14 15 road-departure crash warning, 16 17 20 and lane-change/merge systems. 21 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. In order to realize the maximum potential benefits, the level of integration being undertaken in the IVBSS program is greater than that undertaken in any prior program of its kind.

The scope of systems integration on the IVBSS program includes the integration of sensor data across subsystems (data sharing), the arbitration of warnings based upon threat severity, and the development of an integrated driver-vehicle interface to ensure driver comprehension of warnings, reduction of driver workload, and reduction of driver reaction times. The overall integration effort should dramatically improve the IVBSS system performance relative to the standalone subsystems by increasing system reliability and reducing false warnings. As a result, consumer acceptance of crash warning systems in general might be expected to improve.

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 team led by UMTRI working on the light-vehicle platform includes Visteon Corporation, Honda R&D Americas, and Cognex Corporation. On the heavy-truck platform the partners are Eaton Corporation, International Truck, and Cognex Corporation. In addition, Con-Way Freight (a commercial trucking company) is working on the program with the expectation that it will soon be under contract to UMTRI to serve as the fleet through which the IVBSS field test is conducted. The involvement of industrial partners on the IVBSS program is seen to be critical, given the partners’ technical knowledge of and ultimate ability to deploy actual systems into the U. S. vehicle fleet. Additional members of the team include Battelle Memorial Institute, which is assisting in the development of the heavy-truck driver-vehicle interface, and the Michigan Department of Transportation, which is providing technical support as it relates to the acquisition of crash and roadway geometry data.

The first year of the IVBSS program was comprised primarily of research, engineering, development, and verification efforts, including performance improvements to non-integrated crash warning systems that can be gained through sensor and data fusion, and improved warning effectiveness that can be generated by an integrated driver-vehicle interface. If the viability of the integrated systems can be demonstrated in the second year of Phase I, as determined by verification tests and performance criteria, then the program will proceed and the field operational test conducted using vehicles built early in Phase II.

1.1.3    Phase I – IVBSS Development

Figure 2 illustrates the timing and number of vehicles included in the program. In the first year, eight vehicles have been purchased or leased on which the developmental subsystems are being deployed. 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). Development on the heavy-truck platform has initially taken place on the surrogate vehicle in order to allow various members of the team who do not hold commercial driver licenses to experience the systems under development.

Figure 2. Approximate timing of IVBSS vehicle development and testing

Work in the first year of the IVBSS program focused primarily on system design, subsystem development, system performance guidelines, functional requirements, and verification test procedures. Because the subsystems being integrated were in varying stages of development at the beginning of the IVBSS program, Visteon, Eaton, and Cognex needed to complete development on some subsystems and refine others.

Specific first-year efforts included the development of the functional partitioning, system architecture, and interface control documents. Performance guideline and functional requirements documentation was also begun. Concepts of operation for the individual warning functions were developed and subsystem modeling was performed. The development vehicles purchased during the first year were outfitted with subsystem hardware and initial releases of software to allow for subsystem development. Preliminary work on the arbitration of warnings and integration of subsystems also began in the first year of the program and will continue into the second year.

The UMTRI-led team and the U.S. DOT worked extensively to develop verification test procedures that outline testing to be performed in the second year of the program. The results from these tests will serve as the basis of a decision on the likelihood of the integrated system’s success and, therefore, whether to proceed with the field operational test.

The preliminary development and specification of the driver-vehicle interfaces (visual, audio, and haptic information provided to the driver) also began in the first year. This included the development of prototype hardware, followed by the design of a series of laboratory and driving simulator studies. To support the IVBSS development process, data acquisition systems that permit the collection of data from the developmental vehicles were also designed, and represented the initiation of a plan to develop future data acquisition systems to support the field operational test.

In the second year of Phase I, the physical integration of IVBSS into vehicles and subsystem refinement will continue, as will the development of verification test procedures and human factors testing to support the development of the driver-vehicle interfaces. Major tasks to be initiated in the second year of Phase I include the development and revision of threat assessment algorithms, the conduct of the verification tests (test track and on-road testing), analysis of the verification test data, jury drives, and detailed preparation for the pilot and field operational tests in Phase II.

1.1.4    Phase II – IVBSS Deployment and Analysis

In Phase II, the following activities will take place:

• Extensive 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 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     First-Year Accomplishments

1.2.1    Systems Architecture Development

System architecture development was also completed for both the light-vehicle and heavy-truck platforms in the first year. The systems architecture includes the partitioning of the IVBSS system into its major subsystems, specifies the sensors and software envisioned to reside in the subsystems, and identifies 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 on the IVBSS program were identified and a series of human factors tests to examine design alternatives was initiated. This included identifying visual and auditory display requirements in addition to beginning the characterization of the warnings or messages themselves. Furthermore, extensive engineering development went into providing prototype hardware of the DVI to support IVBSS evaluation.

1.2.4    Preliminary Functional Requirements and Performance Guidelines

The preliminary functional requirements and system performance guidelines developed in the program’s first year describe the anticipated 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.

1.3    First-Year Summary

Overall, the first year of IVBSS has been successful in the completion of several important engineering tasks that will prepare the program for a successful field operational test. In particular, significant progress has been made in the design and development of the IVBSS system architecture, the identification of sensors and equipment, preliminary DVI development and specification, system performance guidelines, and functional requirements. Additional tasks that began in the first year, and which continue into the second year of Phase I, include DVI testing, the development of verification test procedures, the construction of developmental vehicles, and preparation of data acquisition systems to support vehicle development. A high-level Gantt chart identifying major tasks on the IVBSS program is provided in Figure 3. (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 3. Major IVBSS program tasks

2     Introduction

This report documents the IVBSS program’s first-year activities and accomplishments in the design and development of an integrated vehicle-based safety system under a cooperative agreement between U.S. DOT and a team led by UMTRI. The IVBSS program is a four-year, two-phase safety research effort aimed at accelerating deployment of integrated crash warning systems in the passenger vehicle and commercial truck fleets.

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: forward crash warning, lateral drift warning, and lane-change/merge crash warning. The light-vehicle platform also includes a curve speed warning subsystem.

• 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.
• 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.
• Curve-speed warning 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 being addressed by the IVBSS program represents approximately 6,318,000 police-reported crashes that took place in the United States in 2003. 18 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-commercial-truck crashes. Perhaps the most striking description of the rear-end, road departure, and lane-change crash problem to be addressed by the IVBSS program is that these crash types account for approximately 50 percent, or 21,000 annual, crash-related fatalities. Figure 4 illustrates the crash problem for the three major crash types addressed in the IVBSS program for both light vehicles and heavy commercial trucks.

Figure4. 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 the coordination and sharing of sensor data 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 warning systems for light vehicles in the Collision Avoidance Metrics Partnership (CAMP) and Automotive Collision Avoidance Systems (ACAS) programs. The CAMP program developed performance guidelines for radar-based forward crash warning systems by characterizing the forward crash conflict and conducting studies on the timing of warnings to drivers. 14 15 The ACAS program furthered the development of forward crash warning systems by deploying a system in a fleet of vehicles, and the data from this field testing was subsequently used to evaluate the safety benefits and user acceptance of the system . 3 4 For heavy commercial trucks, U.S. DOT has also sponsored work on the development of operational requirements for forward crash warnings systems. 6

The Run-Off-Road and Road Departure Crash Warning programs, also sponsored by U.S. DOT, have contributed extensively to the development of crash countermeasures for light vehicles by addressing road-departure crash warning systems, including curve speed warning. The Run-Off-Road program contributed to crash countermeasure design by studying the potential benefits of lane departure warning systems and characterizing the single-vehicle road departure crash threat. 19 The RDCW program built upon these previous efforts by developing and field testing a crash warning system that addressed lateral drift and curve speed crash conflicts. A 2006 report 16 summarizes the RDCW program, including an evaluation of the safety benefits and user acceptance for the road departure crash warning system. A program to develop operational requirements for lateral drift warning systems in heavy trucks has also been undertaken, 5 as has a field test of these lane departure warning systems. 6 Lastly, lane-change/merge crash warning system development has been supported to a lesser degree with the development of performance guidelines. 21

2.4    Expected Benefits of an Integrated System

The IVBSS program differs significantly from previous efforts to develop crash countermeasures in that the primary goal is to identify the benefits of integrating three collision warning subsystems, each otherwise independently capable of presenting warnings to a driver, and to do so on two vehicle platforms. The scope of the systems integration task on the IVBSS program is greater than that undertaken in any prior program of its kind, and includes the integration of sensor data across subsystems (data sharing), the arbitration of warnings based on threat severity, and the development of an integrated driver-vehicle interface.

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. In essence, individual subsystems will benefit from sensor data collected from the remaining subsystems. In addition, unlike stand-alone 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. Integration at the level of the driver-vehicle interface should offer significant benefits in the form of improved driver recognition of warnings, improved driver reaction times, and potentially reduced driver workload. Overall, the improvements that can be achieved with an integrated crash warning system should result in increased consumer acceptance and earlier adoption relative to standalone warning systems.

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 the management of the program. In addition, UMTRI is responsible for coordinating the development of the IVBSS system on both platforms, developing data acquisition systems, and, in Phase II, conducting the light-vehicle and heavy-truck FOTs. UMTRI’s Human Factors Division, with support from Battelle and in close collaboration with industry partners, is leading the experimental work on issues related to integrating the driver-vehicle interface. The Michigan Department of Transportation is also supporting UMTRI by assisting in the acquisition of crash and roadway geometry data to support analyses during the field operational test. Figure 5 illustrates the organizational structure of the partnership.

Visteon, with support from Cognex Corporation, is the lead system developer and systems integrator on the light-vehicle platform in the development of the lateral drift warning subsystem. Visteon is responsible for the development of the forward crash, lane-change/merge, and curve speed warning subsystems and the overall systems integration effort, including warning arbitration and hardware development for the driver-vehicle interface. Visteon is also providing digital map matching capabilities on the heavy-truck platform. Honda R&D is providing engineering assistance to Visteon and Cognex throughout the program in the integration of IVBSS into the passenger vehicles. This includes but is not limited to technical contributions in systems design and evaluation.

The industrial partners on the heavy-truck platform are Eaton Corporation, International Truck, Cognex, and Battelle. Eaton is serving as the lead system developer and system integrator on the heavy-truck platform, and is responsible for the development of the forward crash and lane-change/merge warning subsystems. Cognex is supporting Eaton in the development of the lateral drift and lane-change/merge warning subsystems, as well as collaborating on data fusion and system learning capabilities. International Truck is providing engineering assistance and will be responsible for installation of IVBSS into the heavy-truck fleet. Battelle is supporting Eaton in the development of the heavy-truck driver-vehicle interface and warning arbitration strategies. In addition, Con-Way Freight (a commercial trucking company) is currently cooperating on the program, with the expectation that it will soon be under agreement to serve as the heavy-truck fleet for conducting the IVBSS field test.

Figure 5. Organizational structure of IVBSS partnership team

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 cooperative agreement is being administered by NHTSA. 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. FMCSA is assisting with the development and monitoring of the heavy-truck platform. The Volpe Center will be responsible for assessing system performance and viability in Phase I, as well as serving as the independent evaluator of results from the field operational test in Phase II. NIST is responsible for developing an independent data measurement system for use during verification testing, and subsequently analyzing the data.

2.5.2    Structure of the Program

IVBSS is a four-year cooperative agreement between the UMTRI-led team and the U.S. DOT that began on November 23, 2005. The program is evenly divided into two, non-overlapping phases of two years each, with efforts in Phase I primarily focused on system design, development, specification, and testing. Phase II includes the buildup of a vehicle fleet, the conduct of the field operational test, and subsequent analyses of system benefits and driver acceptance. The overall timeline for these major phases is shown in Figure 6.

Figure 6. Overall timeline for IVBSS Phase I and Phase II

2.5.2.1    Phase I

The first year of the IVBSS program was comprised primarily of systems engineering and systems development. This includes 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 driver-vehicle interface. 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.

Efforts in the second year of Phase I will concentrate primarily on building prototype vehicles to support verification testing, including the complete physical integration of IVBSS into both a passenger car and a heavy-truck. Verification testing will be performed on test tracks and public roads. Additional second-year efforts will focus on development and revision of threat assessment algorithms, analysis of data from the verification testing, jury drives, completion of the driver-vehicle interface tests, and detailed preparation for the pilot and field operational tests in Phase II.

2.5.2.2    Phase II

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. Upon approval of the second phase of the program, the primary task will be to order sensors and related hardware to immediately begin the build of the vehicle fleet. This includes the installation of the complete IVBSS system into 16 passenger cars and 10 heavy trucks. During the build-up period, prototype vehicles will be used to begin pilot testing with unaccompanied drivers. Once the first fleet vehicles are complete and their performance verified the field operational tests will begin.

The field test will be conducted over a 12-month period for light vehicles 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. Subjective instruments used in assessing driver acceptance of IVBSS will also be developed and used in the conduct of the field test. An evaluation plan will be created early in the second phase to guide analysis of the FOT data, and analysis routines will begin while the field operational test is ongoing to expedite system evaluation and reporting at the end of the program.

2.6    First Year Accomplishments

The UMTRI-led team accomplished several important engineering tasks on both platforms in the first year of the IVBSS program. Significant progress was made in the development of the functional requirements and the design and development of the IVBSS system architectures. The functional requirements describe how the system is intended to operate, the circumstances under which it will present a warning, as well as when it will not warn the driver; the system architecture describes the physical connectivity of the hardware and exchange of data. Concepts of operation for the individual warning functions were developed and subsystem modeling was performed.

The team also identified the sensors and other equipment needed to implement IVBSS. Tasks that began in the first year include the development of performance guidelines, preparation of data acquisition systems to support vehicle development, and the construction of developmental vehicles. The development vehicles purchased this year were outfitted with subsystem hardware and initial releases of software to allow for onboard subsystem development. Initial efforts on the arbitration of warnings and integration of subsystems into vehicles began in the first year of the program, and will continue into the second year of the program.

In addition, the UMTRI-led team and the U.S. DOT began to develop verification test procedures, and will continue this effort into the following year. These procedures outline testing to be performed in the second year, the results of which will serve as the basis for a decision on the likelihood of the integrated system’s success and, therefore, whether to proceed with Phase II and the field operational test.

Finally, development and specification of the driver-vehicle interfaces on both platforms were accomplished in the first year of the program. This includes the development of prototype hardware, followed by a series of laboratory and driving simulator studies that began in the first year. Testing to identify desirable and recognizable warning characteristics was performed, and significant upgrades to the UMTRI simulator were made to support further testing. Refinement and testing of the driver-vehicle interfaces continue, and will be completed in the second year of the program.

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 (on-line version only).

3    Light-vehicle Platform

The light-vehicle team is comprised of UMTRI, Honda, Visteon, and Cognex. The team will integrate 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 will be installed on the 2006 Accord EX for development and the 2007 Accord EX for field-operational-test deployment.

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

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 7 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 7 are described in later sections.

Figure 7. Systems engineering process for the light-vehicle platform

A preliminary functional requirements report for the light-vehicle platform was delivered and posted for public access. 10 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 8 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 9), 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) maximize potential safety benefits by providing the driver with critical information, and (2) gain driver acceptance.

Figure 8. High-level system functional model

Figure 9. 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.

A further development of these situations is encapsulated as two tables of key scenarios used for requirements development, both pre-crash scenarios and scenarios in which nuisance and false alerts are likely to occur. These tables were reported in the preliminary functional requirements document, 10 and were based on earlier work by the U.S. DOT.

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:

1. 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.
2. 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.
3. 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.
4. Estimating road condition parameters: Each warning function is required to obtain and use available data that may indicate low road friction.
5. 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. 10 12 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 are contained in the preliminary 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 year of the program. The first step was functional partitioning, the outcome of which is illustrated in part in Figure 10. 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 10. 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 11.

Figure 11. IVBSS system architecture

The three IVBSS CAN buses are shown as vertical features running up and down on the page. The five major elements to the left of 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 LFAD module;
• LCM/FCW/arbitration/DVI module: A chassis that includes processors and other hardware on which LCM, FCW, arbitration, and DVI are hosted; and
• Data acquisition system module: A two-CPU module with peripherals that records data for analysis during development and the FOT.

The additional elements above the three IVBSS CAN buses include:

• Two vision-based modules that assist with LCM functionality on the left and right side of the vehicle (shown in the upper left corner);
• Another vision-based module shown in the upper right that assists FCW target selection; and
• Three pairs of short-range radars, with each pair communicating with the IVBSS CAN buses through a radar processing unit (RPU).

There are also several sensing and driver interaction elements associated with many of these elements. The individual subsystem functions are described in more detail in following sections.

3.1.4    Second Year Activities and Schedule

In the second year of the program, the functional requirements and vehicle architecture will be updated as required during the vehicle-level development phase. A final Phase I release will occur in November 2007 to incorporate design changes and key results. A revised public document on the functional requirements will be available in early 2008.

Figure 12. Light-vehicle schedule for functional requirements and system 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 10. 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. Communications will be verified in a static environment on the bench. Once the vehicles are built during the second year, the program will move into the vehicle-level development phase. 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 have been installed on a Mercedes test vehicle for development. The LCM algorithms have been developed on the bench. An Accord EX has been equipped with the six short-range radar sensors in the installed position, as well as RPU modules for LCM development.

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 will be built to incorporate the IVBSS system architecture on the 2006 Accord EX platform. These vehicles will be 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. This included the wiring and power requirements, brackets, and miscellaneous components required to integrate IVBSS. All hardware was received to complete the first three development vehicles and the majority of the hardware was received to complete the remaining three development vehicles. The first development vehicle was completed in January 2007; vehicles #2 and #3 are currently being built.

3.2.5     Second-Year Activities and Schedule

Figure 13 shows the steps of the design, development, and integration plan (early subsystem development has already been discussed). In the second year, a series of system releases have been scheduled to install the IVBSS on light-vehicle development vehicles. This culminates in a vehicle verification activity using verification test procedures on the test track, as well as public on-road testing. By the end of the second year, all design, development, and integration activities will have been completed according to the overall schedule shown in Figure 13.

Figure 13. Overall light-vehicle development plan

3.3     Development of Performance Guidelines

Figure 7 illustrates the system engineering process; given the functional requirements, a set of performance guidelines will be developed and published in mid-2007. These will be quantitative and measurable performance metrics that are considered achievable and appropriate for the IVBSS system. As indicated in Figure 7, these guidelines drive details of the actual system implementation and will serve to guide the pass-fail criteria of verification testing to be conducted near the end of the second year. A preliminary set of guidelines will be released in mid-2007 and a final revised set following the completion of Phase I in early 2008.

3.3.1    Overview

The process of developing the preliminary guidelines is currently underway, building upon previous project reports that present preliminary functional requirements. 10 This effort will use previous guideline efforts for standalone crash warning systems, especially prior U.S. DOT projects 1 3 15 16 17 21 and ISO standards efforts (ISO 2002, 2004, and 2006). The focus, however, will be 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 will include specific bounds on system-level performance that may be observable 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.

3.3.3    Second Year Activities and Schedule

The integrated system performance guidelines document (Task 1.d) will be delivered by the end of the first quarter of 2007. This will be a preliminary set, with a final set provided after the completion of system development and testing at the end of Phase I.

Figure 14. Light-vehicle schedule for performance guideline development

3.4    Subsystem Development

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

3.4.1     Overview

The six subsystems have been developed somewhat independently on the bench, in the simulation environment, and on test vehicles (non-IVBSS-equipped vehicles). All of the hardware and sensors have been 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.

3.4.2     Subsystem Descriptions and Sensor Suite

The sensor suite for the light-vehicle application of IVBSS consists of multiple vision, radar, inertial, and vehicle sensors and is depicted in Figure 15. 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 77-GHz radar, two rear-looking mid-range 24-GHz radars, and four side-looking short-range 24-GHz radars); four cameras; 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 15 . 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	X	X
Long-range forward vision (1)		X
Side/rear vision (left and right)	X (AMR)		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*

* = 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 and major activities in the upcoming year.

3.4.2.1.     Forward Collision Warning) Concept of Operation and 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 Operation

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 LFAD module, as previously described. FCW will use long-range Bosch radar to detect and track objects in the forward scene, and a CMOS long-range forward-looking camera to supplement the radar data for object validation and characterization.

3.4.2.1.4.    Software

There are seven 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;
• Vision-based primary target validation and characterization: Validates the choice of primary target, and includes verification that the target is a relevant vehicle;
• Threat assessment: Given the primary target, decides whether to issue an FCW crash alert request; and
• FCW false alarm management: Manages false alarms to reduce the nuisance alarm rate. Employs historical data including previous FCW alerts and subsequent driver responses.

3.4.2.1.5.    Interaction with Other Subsystems

FCW uses information from other warning systems. For example, CSW map-matching and road characterization data is used to enhance forward situational awareness and to locate false alarm areas. Lane position information and vehicle data is also used. FCW also provides other subsystems with the predicted path data.

3.4.2.1.6.    Development Activity

CAN and serial communications have been established between the FCW and other systems. FCW algorithms have been implemented in Matlab/Simulink and used in a simulation environment. For the simulation, real-world data has been 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. FCW system development is well underway and interactions with other subsystems will begin once an integrated vehicle build is available.

The current algorithm development status is as follows:

• A radar-based FCW algorithm was implemented and is running in the vehicle;
• Vehicle detection and tracking has been implemented;
• Forward-radar sensor-track filtering was implemented based on a Visteon algorithm (filters 32 targets to eight targets);
• Vehicle-based target validation and characterization are nearing completion;
• Long-range vision algorithm development is underway;
• A fused FCW algorithm (vision and radar) is in progress, with completion expected in February 2007; and
• 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.

3.4.2.2.     Lateral Drift Warning Concept of Operation and Progress and Accomplishments

3.4.2.2.1.    Subsystem Overview

LDW has the distinct advantage of being the only function addressed by the same technology solution across both light-vehicle and heavy-truck platforms. This cross-platform solution takes the form of the SafeTRAC lane tracking system from Cognex. A cross-platform approach allows advances made for one vehicle platform to be quickly and synergistically employed by the other. The approach also makes some activities common across the two platforms logistically more tractable (e.g., 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.

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.

3.4.2.2.3.    Hardware

The commercially available SafeTRAC system consists of an LDW processing module with a driver interface and a small camera as shown in Figure 16.

Figure 16. Forward-looking LDW camera system hardware

The camera for the LDW subsystem is mounted near the top center of the windshield of the vehicle. The camera is mounted within the sweep of the windshield wipers, but outside the areas where the windshield wipers cause water to pool (Figure 17).

Figure 17. LDW forward camera-mounting location

The LDW module (1) is connected to the camera by a camera cable, (2) has a 12- to 24-volt power supply, and (3) is approximately 6 inches deep, 7.5 inches wide, and 2.5 inches tall. The LDW subsystem communicates over the IVBSS system CAN bus.

For Phase II, the LDW module and camera will migrate to a single-box solution, where the microprocessor, imager, and camera are housed in one unit. The footprint for the new LDW module for the FOT is approximately that of a typical electronic toll collection transponder unit.

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. 16 The overarching lesson from RDCW relating to the LDW subsystem was the need to maximize availability without an unacceptable rate of false alarms. A high-level overview of the software functionality is shown in Figure 18 .

The software consists of three basic components. “Get image” is responsible for acquiring the image and selecting the region of interest. “Process image” is responsible for identifying key features in the image such as lane markings and then interpreting the locations of these features to determine key variables such as lateral position and lateral velocity. “Threat assessment” is responsible for determining when a warning should be issued based on the key variables. The primary output of these computations is the crash alert request (shown on the right side of the figure), with intermediate information for other subsystems resulting from image processing (outputs shown at the top of the figure).

Figure 18. High-level LDW software overview

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.
   1. If the LCM subsystem detects a nearby object in an adjacent lane, the LDW warning threshold will be adjusted to warn earlier.
2. LDW will send information to the other subsystems so that they can improve their performance.
   1. Lateral velocity 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. The FCW subsystem can delay a warning if there is an adjacent lane (dashed boundary) that is unoccupied (LCM reports no adjacent obstacle).
   3. Vehicle position and lane-change information will be posted by the LDW subsystem. The FCW subsystem can use this data to improve its estimation of which radar returns are in the subject vehicle’s path.
3. LDW and other subsystems will work together to improve situational awareness, e.g., refined curvature estimate.

3.4.2.2.6    Development Activity

During the first year of the IVBSS program, researchers implemented a three-pronged approach to meet the challenge of increased availability of:

• A new, more capable imager and processor (CMOS);
• Improved image processing algorithms that are accurate about – when to warn; and
• Improved false and nuisance alarm management to allow for accuracy – when not to warn.

The combination of switching to a CMOS imager and improving the low-level algorithms for addressing lighting extremes will help ensure that the LDW subsystem availability will increase and the false alarm rate will decrease as compared to RDCW. The new CMOS camera that will be used in the IVBSS LDW system can image both the bright and dark parts of the scene better than the CCD imager used in RDCW.

Figure 19 shows similarly promising results with the new camera in on-road experiments driving towards a setting sun, a situation that was found to be challenging for LDW during RDCW. Notice the “blooming artifacts” (bright vertical stripes) in the CCD image on the left. The new CMOS imager on the right is able to image the lane markers much more effectively, which will make tracking the lane easier for LDW.

Another major LDW activity this year has been to design a new imager, along with a new, more powerful image-processing microprocessor, into a small, ruggedized package that will be used on both light vehicles and heavy trucks. The new design, shown in Figure 20, mounts directly to the windshield.

During the second year, the hardware and software for the new LDW will be completed and tested, first in isolation and then after integration, as part of the larger IVBSS system.

Figure 19. Low-sun-angle tests of old CCD and new CMOS cameras

3.4.2.3.    Lane-Change/Merge (LCM) Concept of Operation and Progress/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. (See reference 12 for more information.)

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. (See reference 12 for more information.)

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 the LFAD module as previously described. Radar sensor data will be processed using three RPU modules, which will communicate with the LFAD 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-spot-detection algorithms and applications, which saved a significant amount of time to the overall LCM development time.

The two side-vision modules will also communicate with LFAD over the LCM CAN bus. For the light-vehicle IVBSS FOT, the LCM algorithms will migrate to three next-generation RPU modules designed and manufactured at Visteon. The next-generation RPU is under development. It will have a 32-bit dual-processor microcontroller architecture.

The Visteon multi-function vision board module with integrated CMOS camera is planned for the LCM subsystem. The MFVB module packaging constraints and lens selection for a side-looking system are being developed.

For the IVBSS program, vision is bei