Objectives

The objective of this task is to develop and document a computer simulation of ACAS threat assessment performance during forward collision scenarios. The product of this effort, the TASIM (Threat Assessment SIMulation), will be a ‘user-friendly’ computer code – to be run on a PC, with three-dimensional graphics available for use on a Silicon Graphics, Inc. (SGI) workstation – with appropriate models and fidelity to accurately gauge the effectiveness of unique user-defined ACAS threat assessment algorithms. In order to accomplish this, an important sub objective of the simulation development is to integrate ACAS-specific or relevant ‘reusable’ sensor, fusion, vehicle, and roadway models into a useable and reasonable simulation of ACAS performance.

A key component to ‘useable’ will be the provision of additional tools to provide a graphical user interface for setting up simulations based on scenario definitions, observing the effect of various threat assessment algorithms, and analyzing output data. Additionally, an annotated example of a forward collision scenario with ACAS operation will be provided to GM, plus the provision of a tutorial at Warren, Michigan by February 28, 2001.

Approach

The block diagram for TASIM is shown in Figure 11.1. It shows the integrated architecture of TASIM, with constituent blocks representing discrete modules. Note that the block diagram is divided at the top level into a "simulated world" and a "sensor & hardware model". The modules within the "simulated world" primarily draw from the UC Berkeley PATH Program’s SmartAHS model (http://www.path.berkeley.edu/smart-ahs/index.html) with ACAS-specific upgrades recently provided in the Host Vehicle States block (and described later in this report under Work Accomplished).

The modules within the "sensor & hardware model" block are provided by other members of the ACAS team, GM (In-Vehicle Sensors, Vision System, GPS/Map-Based Road Geometry, Radar Target Detection, Target Selection, Threat Assessment), Delphi (Driver Visual Interface) and HRL (Data Fusion). For the most part, these modules are provided in pseudo-code or block diagram form, and PATH developers have written them into C-language. Figure 11 2 illustrates how the configuration control is implemented.

Figure 11.1 Integrated Architecture for TASIM

Figure 11.2 Example HTML Interface: In-Vehicle Sensors Module

Consistency and control is maintained by defining input and output variable definitions via HTML scripting, wherein hyperlinks to summon these definitions can be called. For example, the In-Vehicle Sensors Module in Figure 11.1 can be double-clicked to show Figure 11.2. From Figure 11.2, variable declarations, internal modules, or source code can be accessed. Hence, with the module interfaces frozen, multiple developers at PATH can (and have) translated pseudo-code and block diagrams of the modules in Figure 11.1 into C-language code, with the primary formal interface enforced through a controlled check-in and check-out registry.

The TASIM tool development integrates:

1. SHIFT³ models of vehicles, highways and controllers
2. Uniform interfaces between the C and the SHIFT codes to support independent development and re-coding of C-code modules should new or refined models be added in the future
3. GUI supporting testing and evaluation.

In essence, and as illustrated in Figure 11.3, the TASIM development integrates user-provided C-code with a simulation kernel implemented in the SHIFT programming language, with 2-D visualization implemented in tcl/tk (in a version called TkSHIFT, with point-of-departure look and feel shown in Figure 11.4), and 3-D visualization implemented in SGI Performer software (with point-of-departure look and feel shown in Figure 11.5). The software will compile with MSVC 6 and run under Windows. This strategy allows:

1. Use of considerable legacy investment in SmartAHS
2. Simplified user interaction
3. In implementation, avoids delays and inefficiencies due to interprocess communication; and
4. Simplified programming, especially the task of porting from Unix to Windows.

Work Accomplished

Coding was underway with the set of TASIM modules received from GM, with an anticipated completion of August 2000. Some testing was conducted to eliminate memory and compilation mistakes. At this junction, there was no testing done to ensure the correctness of the model, but this is planned as a major component to the TASIM development effort, as discussed in Plans for Next Six Months.

The new PATH modules, host vehicle dynamics and controllers and target vehicle kinematics, have been integrated into the SHIFT-based world simulation, although there are a few remaining host vehicle lateral and longitudinal features (e.g., lateral dynamics under slip or wet conditions) that are not yet implemented; expected completion is September 2000.

The vehicle host dynamics models are designed to provide sufficient granularity and fidelity inputs to the in-vehicle sensors which later effect the threat assessment. Specifically, the host vehicle dynamics interface with the road geometry, environment and path planning modules. In order that the vehicle follows a pre-defined trajectory, a controller is also designed. The task internal to the vehicle model is following a reference trajectory such that the test scenario definitions are satisfied. The models are written such that in the closed loop mode, the vehicle will follow a desired trajectory while obeying its physical dynamics.

The existing SmartPath 3.2 animation suite is the basis for the TASIM 3-D visualization. In the current period, it was investigated for suitability for development and/or delivery as under x86 Linux and IRIX 6.4. Since SGI released Performer under Linux, it is possible to port SmartPath to Linux without rewriting the entire program to use another scene graphing package. This will allow a high performance, cost effective and stable platform (PC) for graphics and visualization.

Specific accomplishments include:

1. Compilation and running of SmartPath 3.2.1 on IRIX 6.4.
2. Installation and running of Performer for Linux at ~60 and ~120fps on TNT2 and GeForce2 GTS, respectively.
3. Compilation of running of SmartPATH 3.2.1 on Linux operating system underway; currently in the debugging process, particularly with overcoming need for SGI widgets.

Several tasks were accomplished with displaying synchronous video images:

1. In conjunction with GM, defined data specifications for:

• File transfer
• Video files (MJPEG, 320 x 240 pixels)
• Date file display headers (time counter, frame number)
• Playback controller functions

2. Using these specifications, digitized test files and generated MJPEG clips.
3. Implemented software utility created by GM to convert .log files into MJPEG files
4. Played back GM-created .log files at PATH (using Microsoft Media Player using MJPEG codec distributed by Pegasus Imaging (http://www.jpeg.com)

ACAS scenarios provided by GM and shown in Table 1 were examined and decomposed into constituent atomic maneuvers with the goal that each of these maneuvers can automatically be instantiated in SHIFT and that the user could therefore build the current or a similar expanded (or more complex) set of maneuvers.

Table 11.1 Nominal ACAS Scenarios

Two types of atoms are conceived:

1. Open loop with the following parameters:

• Modality: straight, turn left, turn right
• Duration
• Speed

2. Feedback (in increasing order of difficulty)

Follow center of the lane. Parameters:

• Speed
• Duration

Landmark based navigation. Follow center of lane until the detection of a static feature. Parameters:

• Static feature
• Time-out

Closed-loop based navigation. Examples:

• Follow a car, while following the center of the highway
• Upon detection of a certain-event invoke a certain behavior

From this, subject vehicle atomic maneuvers listed in Table 11.2 are conceived.

Undertaking a similar exercise, the set of atomic maneuvers for the target vehicle is listed in Table 11.3.

Table11. 4 lists the preliminary codification of inputs to these atomic maneuvers, while Table11. 5 lists the outputs. The internal state and termination conditions to these maneuvers are provided in Tables 11.6 and 11.7, respectively. The termination conditions, which will be user input, are the conjunction of the main condition and the enabling condition. Maneuver commands are to be recalculated at each time step. All these computations will be encapsulated in C functions that take the inputs to determine the current value of the commands. The acceleration and braking profiles are encapsulated in these functions, and they can be re-coded by the user.

Plan for Next Six Months

The critical focus will be to continue work on the combined simulation application, extending the user interface to support features desired for TASIM. Specifically, we will:

1. Develop 2-D GUI

2. Integrate legacy 3-D visualization

3. Integrate synchronized video playing into the application, to include GM road test files anticipated to be provided to PATH Oct – Nov 2000

4. Connect world simulation to threat assessment by way of vehicle sensors

5. Perform module- and system-level tests.

Testing in particular will be emphasized, with the philosophy of testing from "bottom to top", that is, all modules are tested individually first, then they are tested as part of the system. In the next 6 months, individual models will be tested separately. In doing so, test data for each of the models will be taken from the developer of the model. Alternatively, the tester will suggest test data. In both cases the developer of the model should approve test results in a checklist manner. Further discussion is warranted on the radar detection module testing for several reasons: at this writing it is the furthest along, and it is also a pivotal module within TASIM; its veracity will likely most affect that threat assessment algorithm.

The radar detection module is designed so that it can be tested in two ways: either test the probability of detection for a specific radar cross-section and type of weather, or test the whole radar detection for a specific scenario. The user can choose the target cross-section, the targets fluctuation model, the atmospheric conditions, and turn on or off multipath effects.

The basic radar detection model test plan is for five scenarios, ranging from one target to three targets in 3 lanes. The basis for verification is probability of detection for different cross-sections and different weather conditions per GM data set. Three additional test items supplement the basic test plan: a non-flat road, a sixth scenario (one target on a curved lane) and the sorting of track ID numbers in the target tracker. The target tracker could also be tested in the case of more than 15 targets in the field of view. Additionally, in the target discrimination test, an enhanced test plan could consider the case when the range is more than 2 m and the range rate more than 3 m/s. Also, the merged target could be put back into the oldest index. In the target tracker, the azimuth could be predicted in the case when the targets are not going straight down their lanes.

11.2 Threat Assessment In-Vehicle Development (Task C3B and 5B)

Objectives

The objectives of these tasks are to:

1. Develop threat assessment algorithms through analysis and simulation

2. Test the threat assessment algorithms in an instrumented vehicle on test tracks and real traffic

3. Coordinate the implementation of the NHTSA Algorithm on the GM EDV and Prototype vehicles.

Approach

The usefulness of the driver alert warning depends on the robustness of the threat assessment algorithm. The threat assessment algorithm must determine the probability of a collision with a vehicular target that is in the forward path of motion of the Host vehicle. This estimation is determined from the Host vehicle’s and target’s velocity and deceleration, the distance between the vehicle and object, and the driver’s reaction time. The time of collision could be determined from these parameters if these parameters were deterministic. However, in real-world traffic scenarios, these parameters are confounded by multiple traffic lanes, roadway curvature, multiple vehicles, roadside obstacles, and driver attentiveness and reaction times. Because of these non-deterministic occurrences, modeling techniques must be developed to assist in the selection of the algorithm or algorithms with the highest chance of success. Several iterations of algorithm candidates will have to be simulated and analyzed.

The threat assessment algorithms will be integrated into a project vehicle for real-time evaluation and assessment. This project vehicle will be driven in various traffic conditions and on test track situations, which simulate potential crash situations, to determine hit and nuisance rates for the various combinations of threat and path prediction algorithms. Six threat algorithms will be evaluated with each of the path prediction methods (e.g., conventional approach, scene tracking approach, vision sensor, and enhanced GPS approach). The six candidate algorithms are called GMR1, GMR2, NHTSA, CAMP, HW and TTC.

To measure the driver’s vigilance, selective subsystems of the instrument panel (e.g., windshield wiper control, HVAC & radio adjustments, etc.) will be monitored and used to further enhance the threat assessment processing by attempting to anticipate the attentiveness and potential reaction time to an imminent alert. For example, application of the windshield wipers would suggest rain, and adjustment of the radio would suggest momentary inattention/distraction of the driver. In these two cases, additional warning time might be provided to compensate for slippery roadway or slower driver reaction time.

Since these parameters are non-deterministic for the future state, only an estimate of a collision event can be provided. The algorithm development of the threat assessment process was initiated during the ACAS program. Further development of these threat assessment algorithms will continue based on the findings initiated during the ACAS Program. These algorithms will be evaluated in the collision warning simulation tool and project vehicles. They will be evaluated for collision warning usefulness and for nuisance alert potential. As previously discussed, minimization of nuisance alerts is paramount to the successful acceptance of this warning approach. Based on previous experience, many modeling, simulation, analysis, and vehicle test iterations will be required to obtain an alert system robust enough for field operation test drivers.

The algorithm development team will collaborate with the other subsystem development teams in order to provide both algorithm performance refinements and subsystem integration capabilities during the integration phase of the program. Additionally, this team will provide the appropriate support required to address any CW system anomalies experienced during the FOT phase.

Milestones and Deliverables

A joint Team/NHTSA collaborative meeting was conducted in order to develop a detailed work plan for securing access to relevant Government-sponsored studies/data.

Work Accomplished

The following threat assessment activities have been accomplished in the last year:

1. Characterization and first delivery of GM R&D Algorithms 1 and 2

2. Received Time to Collision and Time Headway Algorithms from GM

3. Have provided in software provisions for CAMP and NHTSA Algorithms

4. Hosted four of six algorithms (GMR1, CAMP, HW and TTC) on FCW Processor

5. Provided support for NHTSA Algorithm implementation

6. Started development of algorithm MOE’s

7. Made significant progress on FCW Simulation

8. Have almost completed GM EDV Hardware and Software

Research Findings

Research findings to date have been primarily in the areas of analytical development. Once completed, these results will be implemented in the simulation described in Section 11.1 and the vehicles described in Section 13. The following describes a summary of the GM Research threat assessment algorithm that is being readied for simulator and vehicle testing.

The I/O data to/from Threat Assessment are taken from and put onto the CAN bus by the system modules. The Threat Assessment process is as follows:

1. Target Selection inputs, to the FCW Processor (via the CAN bus), certain radar track data of selected radar track with the following criteria:

1. The closest in-path moving vehicle (CIPV)

2. The closest in-path stationary object (CIPS)

3. All moving vehicles that are projected to enter the host vehicle’s path (PIHP)

2. The FCW Processor collects (for the Threat Assessment Algorithms) the required radar track data (see Table 11.8) sent over by Target Selection, from the CAN bus.

3. The FCW Processor also collects the other required Threat Assessment input data (see Table 11.9), from other modules, from the CAN bus.

4. Threat Assessment then calculates an Alert Level and determines other messages (see table 11.10). The FCW Processor outputs this data to the CAN bus.

Figure 11.8 below defines the terms in the discussions to follow.

Vf = Following Vehicle velocity af = Following Vehicle acceleration Vl = Lead Vehicle velocity = Vf + Rdot al = Lead Vehicle acceleration T = delay time (before Following Vehicle starts to decelerate after Lead Vehicle starts to decelerate (at t = 0)	R = range (measured by the radar) between Lead and Following Vehicle Rdot = relative range rate (measured by the radar) between Lead and Following Vehicle Rca = collision avoidance range

The collision avoidance range, R_ca is the closest possible range that a driver can make a decision to stop, using the normal equations of motion, and still avoid a collision for parameters V_f, V_l, a_l, a_f and T. These parameters may be measured, assumed or a combination of measured or assumed values.

R_ca = f(V_f, V_l, a_l, a_f,T)

where

V_f = is a measurement from vehicle sensors

V_l = V_f + R_rate

a_f = g(a + bV_f)

g = f(Road_Surface)

a_l = -0.2 g for a_r > -0.4g

a_l = a_f__m + a_r for a_r < -0.4g

T = f(Distraction)

The alert onset range R_o is determined as follows.

R_o = R_ca + (V_f - V_l)(n-1)t

where

n = number of alert levels

t = time between alert level changes

However, when V_f - V_l <  1.12 m/s,

R_o = V_f  Th

where

Th = the desired time headway

The first expression for R_o is used for the case when the following vehicle is closing on the lead vehicle (algorithm 1). The second expression for R_o is used for the case when the following vehicle is "tail-gating" the lead vehicle at the same speed (algorithm 2). Algorithm 2 is automatically selected when V_f - V_l is less than 1.12 m/s.

The Alert Level, AL, is a number between 0 and 1 that is output to the Driver-Vehicle Interface. AL is an indicator to the driver of the potential for a rear-end collision, and is intended to drive a gradient display.

AL_i = 0, for (R > R_o) or (V_l > V_f)

for R_c ³ R ³ R_ca

AL_i = 1, for R < R_ca

The above concepts form the basis of the GM R&D threat assessment algorithm.

When Target Selection determines that a vehicle is changing lanes and will be in the host vehicle’s path in the future, Threat Assessment must use the projected range of the lead vehicle to calculate the Alert Level. Figure 11.9 below shows the geometry and definition of terms for a lead vehicle changing lanes into the following vehicle’s path.

Target Selection provides the offset X and offset rate Xdot to the threat assessment algorithm as seen in Figure 11.10.

Target Selection provides R, Rdot, X and Xdot for PIHP tracks

The time for path crossing, t_c is determined from X and Xdot as shown in Figure 11.11. From t_c and other known lead and following vehicle data, the projected range R_p is calculated. R_p is used in place of R in the threat assessment algorithm.

Figure 11.11 Determination of t_c and R_p

The following two scenarios illustrate how the alert algorithm would perform. Algorithm parameters have not yet been optimized. This will wait until the CW Simulation is available. Table 11.10 shows various vehicle parameters vs. time.

In Scenario 1, the following and lead vehicles are traveling at constant speeds of 70 and 60 mph respectfully. It is assumed that the following vehicle does not brake. Algorithm 1 is always in effect because V_f – V_l is always above 1.12 m/s. The last three columns of Table 11.11 shows the algorithm used, the brake status and the alert level vs. time. Figures 11.12 and 11.13 below show graphically the information in Table 11.11.

Table 11.11 Scenario 1

In Scenario 2, the following and lead vehicles are initially traveling at constant speeds of 70 and 60 mph respectfully. But as soon as the Alert Level exceeds 0.3, the following vehicle brakes until V_f = V_l. Algorithm 2 is in effect as soon as V_f – V_l is below 1.12 m/s. The last three columns of Table 11.12 shows the algorithm used, the brake status and the alert level vs. time. Figures 11.14 and 11.15 below show graphically the information in Table 11.12.

Table 11.12 Scenario 2

Plans through December 2000

1. Optimize choice of Algorithm Parameters by analysis, simulation, and in-vehicle tests.

2. Develop MOE’s for judging alternate Threat Assessment Algorithms.

3. Start in-vehicle testing.

Figure 11.16 Task C3B & 5B Schedule


[TITLE PAGE]      [TABLE OF CONTENTS]
[1 Executive Summary]     [2 Introduction]     [3 System Integration]     [4 Forward Radar Sensor]
[5 Forward Vision Sensor]     [6 Brake Control System]     [7 Throttle Control System]
[8 Driver-Vehicle Interface]      [9 Data Fusion]     [10 Tracking & Identification]     [11 CW Function]   
 [12 ACC Function]     [13 Fleet Vehicle Build]      [14 Field Operational Test]
[Appendix A]     [Acronyms]