Automotive Collision Avoidance System Field Operational Test Program
FIRST ANNUAL REPORT

3 SYSTEM INTEGRATION (Task A)

The ACAS Team has been following the GM Vehicle Development Process to ensure that a robust, safe vehicle is provided for the field operational test. Task A consists of the following Subtasks, which are discussed in this Section.

  1. Functional Description (Task A1)
  2. System Architecture/Mechanization (Task A2)
  3. Interface Management (Task A3)
  4. System Verification (Task A4)
  5. Risk Management Plan (Task A5)

Milestones and Deliverables for Task A are summarized below. The overall schedule for Task A is given at the end of Section 3.

Milestones and Deliverables

The CW Architecture Definition was completed in December 1999. The Functional Description Document was delivered in December 1999 followed by the System Architecture and Mechanization Report in January 2000.

3.1 Functional Description (Task A1)

Objectives

The purpose of this Subtask is to:

  1. Capture the system functional requirements
  2. Allocate system functional requirements to subsystems and components

Approach

The approach for this task is based on the work of Hatley-Pirbhai [Strategies for Real-Time System Specification, 1988, Doerst House Publishing Co.]. System Requirement, Architecture and Specification models are developed using the Process Model (Data Context Diagram and Data Flow Diagram) and the Control Model (Control Context Diagram and Control Flow Diagram). Here functions are presented as bubbles with Data and Control Flows indicating their interactions.

Work Accomplished and Research Findings

The following paragraphs provide a description of the controls, displays and operating modes that will be provided for the ACC and FCW systems.

The vehicle will provide an adaptive cruise control capability that:

    1. Detects and tracks motor vehicles in its forward path,
    2. Maintains the selected cruise speed when there is no vehicle limiting its forward motion,
    3. Maintains a selected headway between the host vehicle and a lead vehicle, which is traveling slower than the selected cruise speed and thus limiting the forward motion of the host vehicle.

The ACC Subsystem will provide operating modes similar to conventional cruise control with the following additional features:

    1. For the purposes of the FOT, the cruise control may be commanded to operate like a conventional cruise control. The conventional cruise control mode will be maintained until conditions specified by the ACAS/FOT engineers cause it to change to adaptive cruise mode.
    2. When active, the ACC will have two modes, maintaining the set speed and maintaining the selected headway.
    3. When maintaining headway, the system will be capable of slowing the vehicle to pace a moving lead vehicle that is traveling slower than the set speed.
    4. Once the ACC Subsystem slows the host vehicle below the minimum cruise speed, a message will indicate that the driver should take full control of the vehicle. The system will not command the host vehicle to accelerate until the driver manually accelerates above the minimum set speed and then initiates the resume function or the set speed function.

The primary driver interface to engage and operate the ACC function will consist of the standard production cruise controls and a headway selection switch. Using this interface, the driver will be provided with the following capabilities:

    1. Turn the ACC On and Off
    2. Set the desired cruise speed (set speed)
    3. Increase Set Speed by fixed steps
    4. Decrease Set Speed by fixed steps
    5. Accelerate to a new set speed
    6. Coast (decelerate) to a new set speed
    7. Resume a previously set speed
    8. Set the desired headway (Headway Adjustment)

Additionally, the accelerator pedal may be used to over-throttle the ACC system. As in standard cruise control, manual braking shall cause the system to go to standby mode. When the ACC is first turned on, the initial headway setting will be set to the maximum.

The primary ACC Subsystem display will be in a head-up display. The primary ACC display will include the following information:

    1. ACC On/Off
    2. Set Speed
    3. Current Speed
    4. Tracking/Not Tracking a Lead Vehicle
    5. ACC Operational/Failed

The vehicle will provide a forward collision warning capability that will provide alerts and advisory displays to assist drivers in avoiding or reducing the severity of crashes involving the equipped vehicle striking the rear-end of another motor vehicle. For the purposes of the FOT, the FCW will have enabled and disabled modes. The FCW will be enabled and disabled when conditions specified by the ACAS/FOT engineers are met using the same mechanism that enables and disables the adaptive capability of the cruise control. The driver will not be able to disable the FCW, but the driver will be provided with a control to adjust the sensitivity (alert range) of the FCW function. The sensitivity adjustment will not permit the FCW function to be disabled by the vehicle operator.

The FCW crash warnings will include visual, auditory, and perhaps haptic cues to the driver. The FCW crash warning should be sufficiently conspicuous and interpretable to support timely return of an inattentive driver to active driving involvement under conditions where the system determines that driver involvement may be lacking. The visual indicator will support the driver in maintaining a safe distance behind other motor vehicles.

The process model, functional diagrams, and descriptions resulting from work performed under this Subtask can be found in Appendix A. The process model shows the functional decomposition of the system through data and control flow diagrams.

Modality Tables

The Advanced Features Disabled/Enabled modes (Table 3.1) are used in the field operational test. The advanced features include the adaptive capability of the ACC and the FCW features. The advanced features will be disabled when the vehicle is initially provided to each subject. After a preset condition, and while the vehicle is not in use, the advanced features will be enabled.

Table 3.1 Advanced Features Disabled/Enabled Modes

Disabled The cruise control system operates like a conventional cruise control system. No collision warnings are provided. No displays associated with the adaptive cruise capabilities or the collision warning functions are provided. The system is put in this state before the vehicle is provided to each subject.
Enabled The adaptive capability of the cruise control system is available and the collision warning functions are provided. The system goes into this mode when predefined conditions are met. Generally this would be at night one week after the vehicle is turned over to a subject but only when the vehicle is not being operated.

The FCW algorithms (Table 3.2) depend upon whether the ACC is active. The ACC is considered to be active in the Maintain Speed or Maintain Headway modes.

Table 3.2 FCW Modes

FCW with ACC Inactive In this mode the FCW does not expect the ACC to provide any braking.
FCW with ACC Active In this mode the FCW warning algorithm takes into account the braking function that the ACC can provide. An alert is produced if the ACC braking authority is inadequate to prevent a collision.
 

Cruise Control Modes-Adaptive Cruise Control Enabled

The cruise control behaves like a standard cruise control system until the adaptive features are enabled (Table 3.3). Figure 3.1 shows the states and transitions for the cruise control when the adaptive features are enabled.

Figure 3.1 ACC Vehicle Controls

Figure 3.1 ACC Vehicle Controls

 

Table 3.3 Adaptive Cruise Control Modes

ACC Off The ACC system is not functional. This state is entered whenever the ignition is on and the ACC is turned off.
Standby without speed set The system is waiting to take control of the throttle and brakes. This state is entered when the ignition is turned on and the ACC is turned on. From this state the system can be activated by pressing the set button after the vehicle has reached the minimum set speed.
Standby with speed set The system is waiting to take control of the throttle and brakes. A set speed has been established previously.
Maintaining Speed In this mode the ACC system attempts to reach and hold a specified speed. While in this mode the set speed can be increased or decreased by pushing or tapping on the resume/accel or set/coast buttons.
Maintaining Headway In this mode the ACC system attempts to reach and hold a specified headway. While in this mode the set speed can be increased or decreased by pushing or tapping on the resume/accel or set/coast buttons.
Manual Throttle Override In this mode the driver is pushing on the throttle to force the vehicle to go faster than the cruise control function would command.
Under Minimum Speed While Active In this mode the ACC has reduced the vehicle speed below a minimum cruise speed because a slow vehicle is ahead. Once this happens the ACC will not cause the vehicle to accelerate. When this state is entered the driver is given a message to take control of the vehicle.
 

Subsystem/Component Partition Diagram

Table 3.4 below lists the system modules and their primitive functions. The left column lists the physical modules and the right column lists the primitive functions performed by the software in each module. The connections between the modules are shown in Figure 3.2. A more detailed description of the primitive functions is given in Appendix A.

Table 3.4 System Modules and Their Primitive Functions

Architecture Module Function
Scene Tracking Scene Tracking
Path Prediction & Target Selection Yaw-Based Path Estimation
Lane Position Estimation
Target Selection
Map-based Road Geometry Map-Based Road Geometry Estimation
FCW Processor All of the Data Fusion Functions
Threat Assessment
ACC Controller ACC Vehicle Controls
Data Acquisition System (DAS) All of the Data Acquisition Functions
Radar Target Detection
Multi-Target Tracking
Target Classification
Auto-alignment and Blockage Detection
Vision Vision-Based Lane Tracking
Vehicle Sensor Filtering & Interface Vehicle Sensor Filtering
Driver Vehicle Interface (DVI)

Driver-Vehicle Interface function

Plans Through December 2000

This work is essentially complete and we foresee only minor changes in the future.

3.2 System Architecture/Mechanization (Task A2)

Objectives

The main objectives of this Subtask are to:

  1. Partition the system into subsystems and components
  2. Allocate functional requirements to the subsystems and components
  3. Designate interfaces among the subsystems and components

Approach

Following the structured method of Hatley and Pirbhai, the total vehicle, with all its embedded systems, was considered as one supersystem. All our functional requirements must fit and be allocated to a well-defined physical structure, interconnected by communication buses with appropriate protocols meeting safety, maintainability and reliability requirements.

The supersystem was partitioned into physical boxes which, in their totality, satisfy all the functional requirements in an optimum way. Processes in our requirement model are allocated to slots in the architecture model.

Work Accomplished and Research Findings

Figure 3.2 shows the physical architecture, subsystems and components of the system with connections and buses between the processors. This mechanization provides the top-level hardware required for the Prototype Vehicle and the flow and sources of information from and for each physical box (block). The functional interaction between the blocks as well as the internal functions of each block has been explained in Section 3.1. The main information artery is a high-speed CAN Bus (500kbs) which transfers a large body of communication messages among the subsystems or the components. Additionally, a GM Class 2 Bus provides information linkage from the vehicle-based signals to all subsystems requesting such signals, either directly or indirectly via the CAN Bus. Other harnesses are direct wires.

Figure 3.2 Prototype Vehicle System Block Diagram and Mechanization
Figure 3.2 Prototype Vehicle System Block Diagram & Mechanization

Plans through December 2000

This work is essentially complete and we foresee only minor changes in the future.

3.3 Interface Management (Task A3)

Objectives

The main objective of the Interface Management Task is to ensure that subsystems or components developed independently satisfy the prescribed requirements and operate according to the specifications and in adherence with the communication protocol when connected as a system.

Approach

To ensure subsystem interface compatibility and traceability, a systematic approach is followed. First, the interface signals between each and every hardware block in the Prototype Vehicle System Block Diagram & Mechanization diagram are labeled. For example, C1 can indicate the set of signals being communicated between the CAN bus and the Scene Tracking Processor. The individual signals between these two modules will be designated by C1_1, C1_2, etc. Then, every signal source, destination, type of harness, bit structure, and other relevant information will be tabulated. This approach allows:

  1. Developing a complete record of all signals among different subsystems or components,
  2. Mapping a one-to-one correspondence between each requested signal (by a block) and its source,
  3. Implementing changes with minimal effort.

Work Accomplished

Presently, this is work in progress. A complete set of signals and their associated attributes will be provided to NHTSA in March 2001.

Plans through December 2000

We will continue working towards the completion of the Interface Control Management document. This draft will be used as a living document to guarantee correct and well-understood interfaces among all subsystems and components.

3.4 System Verification (Task A4)

Objectives

The overall objective of the ACAS System Verification Task is to make sure the system is ready for use by subjects in the FOT. This requires verification that the system satisfies certain minimum performance requirements at the component, subsystem, and system level. The System Verification Task (Task A4) includes:

  1. Definition of the system verification process
  2. Supervision of the definition and execution of verification tests at the component and subsystem level
  3. Definition and execution of the verification plan at the system level

Approach

Verification will occur at several levels: component, subsystem, and system. Component-level verification will include the operation of the ACAS-specific on-board sensors. These include sensors for vehicle kinematics, environment sensors, and driver activity sensors. Subsystem-level verification will include testing the operation of the interfaces between the subsystems and the functionality of each subsystem. System-level verification will include subjecting the prototype vehicle to crash and nuisance alert scenarios on a test track and driving the vehicle on a prescribed route in traffic. The subsystem designers are responsible for definition of the test procedures at the component and subsystem level. The subsystem designers under supervision of the systems engineers will perform execution of these tests. The systems engineers will be responsible for definition of the test procedures at the system level. The systems engineers will perform execution of these tests.

The dynamic scenarios, shown in Tables 3.5 and 3.6 were selected for use for system-level verification.

Table 3.5 Crash/In-Path Alert Scenario Test Descriptions

Test Scenario Description ACC
On
ACC
Off
C-1 100 kph to lead vehicle stopped in travel lane (night) X X
C-2 80 kph to lead vehicle at 16 kph (uneven surface) X X
C-3 100 kph to lead vehicle braking moderately hard from 100 kph X X
C-6 Host vehicle to lead vehicle stopped in transition to curve (wet pavement) X X
C-8 Host vehicle to slower moving lead vehicle, in tight curve X X
C-9 Lead vehicle at 67 kph cuts in front of 100 kph host vehicle X X
C-10 Host vehicle at 72 kph changes lanes and encounters stopped lead vehicle X X
C-12 Lead vehicle brakes while host vehicle tailgates at 100 kph.   X
C-13 Greater size and equal distance (100 kph host vehicle approaches 32 kph motorcycle that is alongside two 32 kph trucks) X X
C-14

Greater size and greater distance (100 kph host vehicle approaches 32 kph motorcycle that is behind a 32 kph truck)

X X
C-16 Host vehicle to lead vehicle stopped in transition to curve (poor lane markings) X X
V-8 Both following and lead vehicles are traveling at constant speed on a curve; lead vehicle then decelerates. X X
A-7 At highway speeds when tailgating a lead vehicle X
A-9 Lead vehicle brakes at unusual intensity X
A-13 Lead vehicle comes to a stop X
A-14 2 lead vehicles; closer one moves out of lane to reveal a slow or stopped vehicle ahead X X


Table 3.6 Nuisance Alert Test Description

Test Scenario Description ACC
On
ACC
Off
N-2 Road surface objects on flat roads X X
N-4 Guard-rails and concrete barriers along curve entrance X X
N-5 Roadside objects along straight and curved roads (dry & wet pavement) X X
N-6 U-turn with sign directly ahead X
N-7 Slow cars in adjacent lane, in transition to curve X X
N-8 120 kph between two 60 kph trucks in both adjacent lanes X X
N-9 Slow cars in adjacent lane at a curve (poor lane markings) X X
A-1 Following a lead vehicle at typical distances  X X
A-2 Lead vehicle cuts in at higher speed with typical clearances X X
A-3

Open road (no other traffic) with hills & curves

X  

Work Accomplished

Briefings were prepared and presented on the validation plan during technical interchange meetings in Malibu, CA on November 16, 1999 and in Warren, MI on June 29, 2000. In addition, a briefing and discussion was held on system level testing scenarios with NHTSA, Volpe, and other government representatives in Washington, DC on March 28, 2000. These technical interchange meetings led to the preparation and delivery of a testing scenarios report that was delivered to NHTSA in April 2000.

Plans Through December 2000

This task will produce a detailed System Verification Plan, which will be delivered to NHTSA in October 2000.

3.5 Risk Management Plan (Task A5)

Objectives

The overall objective of the Risk Management Task is to define the hazard analysis and safety risk management program to be implemented by the Team in the performance of the ACAS/FOT program. The plan is being developed using guidelines from Mil Standard 882C and SAE J1789. Safety plan presentations have been prepared and presented at meetings in November 1999 and June 2000. In addition, the Safety Engineering team has met with the principal engineers working on each subsystem to gather the required information for the safety analysis and hazard mitigation plan. The Risk Management Plan is deliverable to NHTSA in November 2000.

Work Accomplished

Through June 2000 the primary focus under Subtask A5 was on developing:

  1. A preliminary list of significant hazards
  2. Guidelines for risk severity and likelihood analysis
  3. A sample fault tree analysis
  4. Guidelines for hazard mitigation

Plans Through December 2000

The Safety Teamís plan is to develop the detailed Risk Management Plan for delivery to NHTSA in January 2001. Simultaneously, team members are reviewing the designs and testing plans for each subsystem and the systems as a whole with the responsible engineers to ensure that the Risk Management Plan is properly implemented.

Figure 3.3 Task A Schedule

Figure 3.3 Task A 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]