software requirements specification (srs) project …435cruise3/resources/srsfinalpdf.pdf ·...

Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have

been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)

Software Requirements Specification (SRS)

Project License to Cruise

Cooperative Adaptive Cruise Control System

Authors: Anthony Curley, Justin Mrkva, Devan Sayles, Grayson Wright

Customer: William P. Milam, Ford Motor Company

Instructor: Dr. Betty H.C. Cheng

Introduction

This Software Requirements Specification (SRS) document describes the requirements of a

Cooperative Adaptive Cruise Control system. The SRS begins with an introductory section

describing its overall purpose, scope, and defining terms and acronyms that will be utilized

therein. The following section will describe the software product in detail, including functions,

constraints, and user characteristics. Then, a detailed list of requirements will be provided, after

which those requirements will be modeled using a domain model, data dictionaries, use case

diagrams, sequence diagrams and system state diagrams. In the final three sections, a product

prototype is described, references for this document are listed, and a point of contact for the

project is provided.

1.1 Purpose

The purpose of this Software Requirements Specification (SRS) document is to provide a

complete description of both the purpose and functionality of the software system that is to be

developed. This document includes the details of the system’s requirements, user interface,

subsystem interactions, and design considerations.

The main intended audience for this SRS is the customer for whom the system is to be

implemented. However, this document may also be helpful to others, such as developers or

automotive engineers, who might be trying to understand the interactions of the system with other

vehicle components. The tone of the document is fairly technical, but the goal is to depict the

system at a high enough level such that it can be understood by domain experts as well as

developers.



1.2 Scope

The software described in this SRS document is a Cooperative Adaptive Cruise Control (CACC)

system. It is designed as an embedded system to be used in consumer vehicles. The major goals

of the system are to provide convenience and safety measures to vehicle drivers and their

passengers by utilizing increased automation and control authority.

The CACC system will attempt to maintain a constant forward vehicle speed as specified by the

driver. The system can use a combination of forward radar and camera sensors to detect another

vehicle (target vehicle) in its forward path and is able to adjust its own speed via throttle and

braking controls in order to maintain a certain following distance, also specified by the driver.

The vehicle receives GPS information (location, speed, and direction) from vehicles ahead of it

and broadcasts its own GPS information to vehicles behind it using the Dedicated Short-Range

Communications (DSRC) radio communicator. This additional information can be used to set up

a platoon of vehicles that follow a lead vehicle at the same speed and maintain spacing between

each vehicle. The system is also responsible for arbitrating situations in which the actions of

various features would work against each other (such as when one feature intends to accelerate

the vehicle, while another recommends deceleration).

1.3 Definitions, acronyms, and abbreviations

Table 1.1: A listing of terms and acronyms used throughout this document.

Term Definition

ACC Adaptive Cruise Control: A system running inside of a vehicle that is able to

adjust speed according to the speed and position of nearby vehicles.

CACC Cooperative Adaptive Cruise Control: a system running inside of a vehicle that is

able to communicate with other nearby vehicles and adjust its speed accordingly.

CAN Bus Controller-Area Network Bus: a vehicle bus standard that allows devices within a

vehicle to communicate with one another. [2]

CC Cruise Control: A system running inside of a vehicle that maintains a steady

speed of the vehicle as set by the driver.

DSRC Dedicated Short-Range Communications: Two-way short range wireless

communication channels specifically designed for automotive use. [3]

GPS Global Positioning System: provides precise position data for the vehicle as it

moves along.

Platoon Multiple vehicles all following a lead vehicle at the same speed while maintaining

a safe following distance.

SRS Software Requirements Specification: A complete and in-depth document

describing the behavior and purpose of a system to be developed.

Target Vehicle A vehicle identified in the forward path of a CACC vehicle, sometimes in a

situation in which it may be necessary to adjust speed to maintain a safe following

distance behind it.

Throttle A vehicle component that can regulate the amount of power supplied to the

engine in order to alter the vehicle’s speed.

VC Vehicle Controller: the command center of the CACC system, responsible for

communicating with all sub-systems and issuing commands based on information

it receives and processes.

Vector A data member containing a distance and direction.



1.4 Organization

This SRS document continues with sequential, in-depth descriptions of the software system’s

requirements. First, a detailed overall description of the software is provided, including a product

overview, constraints, and assumptions/dependencies. Next, specific requirements are listed,

followed by models of the features, scenarios and system states. Lastly, the document presents a

full description and sample scenarios for the product prototype.

2. Overall Description

This section provides a more detailed overview of the system under development, including a

description of the product’s function and overarching constraints.

2.1 Product Perspective

The CACC system represents the cooperation of several systems within an automobile, designed

to interact in such a way as to increase safety, comfort, and ease-of-use for the driver. The main

component of this new system will be the Vehicle Controller (VC) that will integrate with

existing systems and utilize them for the functions of the system as a whole. Figure 2.1 is a

representation of the system within the vehicle context.

This system must fit within the current constraints of

the subsystem components within the vehicle. These

subsystems communicate through the Controller Area

Network (CAN) bus, operate with limited memory

usage and with compact hardware so as to fit physically

within the vehicle. This system should fit within similar

constraints. Additionally, the user must be able to

interface with this system easily and efficiently while

still remaining in complete control of the vehicle in a

safe and legal fashion. External communications

between the CACC system and any other system must

meet FCC regulations for automotive communications.

Figure 2.1: A diagram of system components within the vehicle context.



2.2 Product Functions

The system can function at one of three specified levels: Cruise Control (CC), Adaptive Cruise

Control (ACC), or Cooperative Adaptive Cruise Control (CACC). At the CC level, only the basic

cruise functionality is enabled, meaning that the vehicle can maintain a driver-specified speed but

will not utilize any sensors or react to external events. The ACC level builds on this functionality,

enabling the vehicle to sense and adapt its motion to changes in the movements of surrounding

vehicles. The CACC level builds on the previous two, encompassing their functionality in

addition to enabling cooperation with neighboring vehicles via radio communications.

At the ACC and CACC levels, the system utilizes the existing forward radar and camera sensors

to detect other vehicles within its forward path. It has the ability to adjust its own speed by

utilizing the throttle and braking controls to maintain a driver specified distance from the vehicle

in front, if one is present. The system will also receive GPS information about the vehicles and

infrastructure around it and will also broadcast and receive similar GPS data. This additional

information may be used to set up a platoon with a chain of vehicles, each with a safe distance

between them. Each vehicle in the platoon then use GPS data, gathered from the other vehicles

over the DSRC radio communicator, as well as its own radar and camera sensing to control the

vehicle’s speed to achieve and a set following distance.

By periodically performing functionality checks, the system is able to detect subsystem failure

and provide a low-priority alert to the driver before disengaging. In the event of a more serious

situation, such as imminent collision, a high-priority alert that includes flashing lights and loud

beeping is activated before the system is disengaged.

2.3 User Characteristics

The CACC system will be installed in consumer vehicles, which implies that all users will have

obtained drivers’ licenses and have a basic knowledge of traffic rules and regulations. Because of

the cooperative nature of CACC, the system’s usefulness increases as more vehicles become

equipped with the system. Therefore, the system should not require a high level of technical

knowledge to operate, and should be readily usable by a large number of consumers. The system

should have support for multiple languages.

2.4 Constraints

Because the system is operating in consumer vehicles, safety is a critical concern. In order to minimize

the chances of roadway accidents, the following constraints must be satisfied:

The system must sample its surroundings for new objects at least once every 0.1 seconds.

If the system is unable to operate correctly, it must be able to detect the failure and power

off the system.

The systems must keep logs of events and data that can be reviewed in the case of failure.



2.5 Assumptions and Dependencies

Necessary subsystems are in place and working correctly in the vehicle.

Communications between systems take place over the CAN Bus, and the vehicle

controller is able to read and send messages.

2.6 Approportioning of Requirements

Based on communications with our customer, there are a few related features and enhancements

that have been determined to be out of scope for the current project. The current CACC system

has limited abilities to interact with the infrastructure and receive alert messages from it. Future

versions of the system could incorporate a ‘smarter’ infrastructure, including intersections and

traffic lights that have the ability to communicate with vehicles and help prevent collisions.

Current communication functionality within the CACC system would be an asset to leverage in

the implementation of such features. Another related feature that has been determined out of

scope for this project is lane centering. This would involve additional coordination between

infrastructure and the vehicle controller.

3. Specific Requirements

Below is a list of enumerated requirements that provides additional specifications for the behavior

and functionality of the system.

1. General System Information 1.1 Constants

1.1.1 "Car" is 20' wide by 30' long.

1.1.2 One car length is defined as 30 ft.

1.1.3 1.5 car lengths (45 ft) is the absolute closest following distance allowed.

1.2 Assumptions

1.2.1 CC functionality of maintaining a single set speed has already been

implemented.

1.2.2 All ACC/CACC logic and communications take place through the

Vehicle Controller component.

1.2.3 All internal subsystem communication is broadcast over a CAN bus

(Controller Area Network).

1.2.4 The User Interface component has not been previously implemented. All

other subsystem functionality has been previously implemented, with the

exception of interactions with the Vehicle Controller.

1.3 Technical constraints

1.3.1 No dynamic memory allocation used; only fixed memory.

1.3.2 No garbage collection, no Object Oriented programming, no

constructors/destructors needed.



2. System States 2.1 When CACC is 'off', subsystems are in low-power standby mode (with exception of

CAN bus, which is always on).

2.2 When in the active state, cruise control functionality can be at one of three levels:

2.2.1 Cruise Control (CC): Only basic cruise control is active. The vehicle

does not cooperate or adapt to the movements of others around it.

2.2.2 Adaptive Cruise Control (ACC): The vehicle utilizes cruise control and

its ability to adapt to changes in the movement of neighboring vehicles.

2.2.3 Cooperative Adaptive Cruise Control (CACC): The vehicle exercises full

system functionality; is able to cooperate with neighboring vehicles via

radio communications (platooning), as well as automatically adapt cruise

control based on those vehicles' movement (following).

3. System Startup 3.1 Upon pressing the 'On' button, the Vehicle Controller will verify which subsystems

are fully operational and use this information to determine which cruise levels can be

safely entered.

3.2 After determining viable cruise level options, the Vehicle Controller will request that

the User Interface display these options and request that the driver select one.

3.3 Upon the driver making a cruise level selection and subsequently engaging the

system using the Set or Resume buttons, the Vehicle Controller will verify that the

vehicle's current speed and desired speed are both greater than 25 mph. Upon

verifying this information, the system will engage and enter the active state in the

selected level.

4. GPS Subsystem 4.1 GPS continuously determines the vehicle's position and velocity vectors and

communicates these values to the Vehicle Controller.

5. Radar Sensor 5.1 Radar scans in a 180-degree arc with a 150-foot radius in front of the vehicle.

5.2 Radar sensor is mounted near the bumper at the very front of the vehicle.

5.3 Radar sensing of a given object may be obstructed by other, nearer objects.

6. Camera Subsystem 6.1 The Camera is used to capture image frames of the area ahead of the vehicle.

7. Electronic Throttle Control 7.1 The Throttle Control detects vehicle speed and periodically sends its data to the

Vehicle Controller.

7.2 The Throttle Controller moves the throttle to a commanded position.

8. Brake By Wire 8.1 The Brake By Wire system periodically sends the braking magnitude to the Vehicle

Controller.

8.2 The Brake By Wire system applies brakes according to a desired braking magnitude.

9. Radio Communication (DSRC) 9.1 An inter-vehicle message contains:

9.1.1 Vehicle ID (sender, receiver).

9.1.2 Authentication data.



9.1.3 Position and velocity vectors.

9.1.4 Status message such as platooning availability.

9.2 Messaging

9.2.1 Messages should be encrypted to prevent spoofing.

9.2.2 Status messages should be broadcast about once per second.

9.2.3 Messaging should always be available to receive, even when in low-

power standby mode.

9.2.4 A vehicle can send a message over DSRC to request another vehicle’s

identification information.

9.3 Infrastructure

9.3.1 Infrastructure will use a separate ID system.

9.3.2 Infrastructure can provide alert messages, such as weather conditions.

10. Gathering and Processing Sensor Data 10.1 The Radar Sensor and Camera Subsystems periodically send data to the Vehicle

Controller.

10.2 The Vehicle Controller processes the data to extract a list of tracked objects along

with their position and velocity vectors.

10.3 A maximum of 256 tracked objects will be maintained at any given time due to

fixed memory constraints.

10.4 The Vehicle Controller has the ability to determine priorities of tracked objects

based on their relative positions and velocities.

10.5 The Vehicle Controller will compare radar and camera data to ensure accuracy.

Radar is considered the primary sensor while the camera is secondary. However,

both must be fully functional for the system to operate.

10.6 The Vehicle Controller can utilize the camera data to detect visual events such as

brake lights.

10.7 GPS data aids the Vehicle Controller in differentiating between fixed and mobile

targets.

10.8 GPS inaccuracies are acknowledged, but have minimal effect on relative position

and velocity vectors.

11. Handling Errors and Shutdowns 11.1 For a given cruise level, all necessary subsystems must be functional to enter that

level.

11.2 If a subsystem necessary for the current level fails at any time, the system will shut

down.

11.3 In the event of a shutdown due to subsystem failure, the driver must manually

restart the system at a lower level.

11.4 In order for each feature to be available:

11.4.1 CACC: All subsystems must be fully functional.

11.4.2 ACC: All subsystems except Radio Communication, Radar Transponder

and GPS must be fully functional.

11.4.3 CC: Does not require any communication or sensor subsystems.

12. User Interaction and Interface 12.1 Components of the Driver Interface:

12.1.1 On/off button.

12.1.2 Pause button.

12.1.3 Set/+ button.

12.1.4 Resume/- button.



12.1.5 Following gap switch (3 levels of following gap).

12.1.6 LCD screen.

12.1.7 Up/Down selection button.

12.1.8 Accept button.

12.1.9 Back/Cancel button.

12.1.10 Cruise control status lights, that will turn on and off as necessary to

show the following when appropriate:

12.1.10.1 A bird's eye view of the car.

12.1.10.2 Target speed.

12.1.10.3 Tracked objects on each side of the vehicle (In front, to

the rear, to the left and right sides).

12.1.10.4 Following gap setting.

12.1.11 Speedometer.

12.2 Driver Alerts

12.2.1 The Driver will be notified of low-priority alerts via a text message

displayed on the LCD screen, accompanied by low-volume warning

beeps. Low-priority alerts must be acknowledged using the Accept

button.

12.2.2 The Driver will be notified of critical alerts via a text message displayed

on the LCD screen, accompanied by loud, brassy beeping and flashing

lights positioned to draw attention to the road ahead.

13. Imminent Collision Event 13.1 When a collision is imminent, the vehicle will prepare by doing the following:

13.1.1 The ACC or CACC system will be shut down.

13.1.2 The driver will be alerted via a critical alert.

13.1.3 Seatbelts will be tightened.

13.1.4 Brakes will be pre-pressured so that they will have maximum stopping

power the moment the driver touches the brake pedal.

13.1.5 Airbag velocity will be precalculated.

13.1.6 An emergency alert will be broadcast over the DSRC to alert other

vehicles of the imminent collision.

14. Vehicle Controller 14.1 The Vehicle Controller coordinates among all subsystems. It is the decision-making

hub and handles most of the logic and data processing.

14.2 When a CAN bus message arrives, the Vehicle Controller will process the message

and decide what action to take.

14.3 The Vehicle Controller runs code to produce the desired behavior of the ACC and

CACC cruise control levels.

14.4 Messages should be sent on events (brakes, airbag deployment, traction lost, and

other errors) regardless of cruise level.

14.5 Messages should be broadcast except for direct platoon queries.

14.6 Upon receiving a weather condition alert from the infrastructure, the Vehicle

Controller should adjust the speed and following distance appropriately, decreasing

the speed in poor weather situations and allowing higher speeds in good weather

conditions.

14.7 If a component that is relevant to the current cruise level fails, the problem will be

flagged and the system will be disengaged. The driver will be notified via a low-

priority alert.



15. Adaptive Cruise Control (ACC) 15.1 The goal of ACC is to achieve and maintain a closing rate of zero with the vehicle

directly ahead, called the Lead Vehicle.

15.2 The distance to the Lead Vehicle is defined by a Following Gap, that may be set to

one of three levels:

15.2.1 Aggressive: 1.5 car lengths distance.

15.2.2 Intermediate: 2.5 car lengths.

15.2.3 Passive: 3.5 car lengths.

15.3 If another vehicle begins merging ahead at a distance and speed that will cause the

closing rate to be positive and the resulting distance to be less than the current

following gap, the vehicle should slow down in order to maintain the following gap

and a nonzero closing rate.

15.4 If the lead vehicle begins to brake, the vehicle should slow down in order to

maintain the following gap and closing rate.

15.5 If a collision is imminent, the system will be disengaged, the driver will be given a

critical alert, and the imminent collision preparation scenario will be triggered.

16. Platooning 16.1 Criteria:

16.1.1 At least two CACC capable vehicles must be traveling in the same

direction at the similar speed in the same lane.

16.2 To engage platooning:

16.2.1 The Vehicle Controller checks the list of targets and determines which

targets are capable of and available for platooning using the Radar

Transponder.

16.2.2 The driver is presented with the option to join the platoon. If they do not

respond within five seconds, a platoon is not formed.

16.2.3 If the driver accepts, the vehicle joins the platoon.

16.3 Platooning Responsibilities:

16.3.1 When the vehicle begins to brake or slow down, a message will be sent

to the trailing vehicle, if it exists, in the platoon to slow down so as to

maintain the proper following gap and closing rate.

17. Cooperative Adaptive Cruise Control (CACC) 17.1 All functionality provided by ACC will also be provided by CACC.

17.2 The vehicle will attempt to join or form a platoon given the opportunity.

18. System disengage 18.1 The system should always disengage when:

18.1.1 The brakes are applied.

18.1.2 The off button is pressed.

18.1.3 Vehicle speed falls below 25mph.

18.1.4 A system (radar, camera, communications) fails.

18.1.5 Shifting gears.



4. Modeling Requirements

The following section contains different methods for modelling the requirements to elaborate on

the form and function of the system, and enable the reader to gain a more conceptual

understanding of the system.

Use Cases

Use cases are meant to depict the high level services of a system. Each use case involves an

external actor who interacts with the system in a specified way in order to achieve a distinct goal.

Use case templates describe what the use case is, which actors are involved, what actions are

taken to achieve the actor’s goal, and provide references to related use cases and requirements.

The use case diagram (Figure 4.1) shows the system boundary as a large central rectangle, the

actors that interact with the system as labelled stick figures, and the ways (use cases) in which

they can interact as labelled ovals within the system boundary.

Figure 4.1: Use Case Diagram depicting the system boundary and ways in which external

entities can interact with the system.



Use Case Turn On

Actors Driver

Description The driver turns on the system. The system checks that

subsystems are operational and prompts the driver for the

desired cruise level.

Type Primary, Essential

Includes N/A

Extends N/A

Cross-refs 3, 12.1.7, 12.1.8, 12.1.9

Dependent Use Cases N/A

Use Case Turn Off

Actors Driver

Description The driver turns the system off. The system immediately

relinquishes control of the vehicle’s speed and does not store

the target speed for future use.

Type Primary, Essential

Includes N/A

Extends N/A

Cross-refs 18.1.3


Use Case Pause

Actors Driver

Description The driver tells the system to pause. The system immediately

relinquishes its control of the vehicle’s speed and stores the

target speed for future use.

Type Primary

Includes N/A

Extends N/A

Cross-refs 12.1.3


Use Case Resume

Actors Driver

Description The driver tells the system to resume its previous speed. If the

system was engaged at some time since it was last turned on,

the system will set its target speed to the target speed that was

set at the time it was paused. No action is taken if the system

was not engaged since it was last powered on or if the vehicle’s

current speed is less than 25 miles per hour.

Type Primary

Includes N/A

Extends N/A



Cross-refs 12.1.5


Use Case Set Following Gap

Actors Driver

Description The driver sets the size of the vehicle’s following gap using the

Following Gap switch and selecting from three pre-set options:

Aggressive (1.5 car-lengths), Intermediate (2.5 car-lengths), and

Passive (3.5 car-lengths).

Type Primary

Includes N/A

Extends N/A

Cross-refs 12.1.5, 15.2


Use Case Set Target Speed

Actors Driver

Description The driver sets the vehicle’s target speed for cruise control,

using the ‘Set /+’ and ‘Resume/–’ buttons or by engaging the

system at a certain vehicle speed.

Type Primary

Includes N/A

Extends N/A

Cross-refs 3.3, 12.1.3, 12.1.3


Use Case Set Functionality Level

Actors Driver

Description The driver sets the CACC system level from the following three

options: Cruise Control (CC), Adaptive Cruise Control (ACC),

and Cooperative Adaptive Cruise Control (CACC).

Type Primary

Includes NA

Extends N/A

Cross-refs 2.2, 3


Use Case Acknowledge Message

Actors Driver

Description If a camera error has occurred, the driver is shown a message



about the error that must be acknowledged. The message will

not go away until the driver has done so.

Type Primary

Includes N/A

Extends N/A

Cross-refs 12.2.1


Use Case Request ID

Actors Other Vehicle

Description A trailing car requests and is sent the ID of this vehicle.

Type Primary

Includes N/A

Extends N/A

Cross-refs 9.2.4


Use Case Broadcast Alert


Description The system broadcasts an alert to nearby vehicles after detecting

an imminent collision.

Type Primary

Includes N/A

Extends N/A

Cross-refs 13.1.6


Use Case Request Platoon


Description Another CACC-equipped vehicle requests to form a platoon

with this vehicle.

Type Primary

Includes Approve Platoon

Extends N/A

Cross-refs 16.2.2, 16.2.3


Use Case Approve Platoon

Actors Driver, Other Vehicle (indirect)

Description The driver must acknowledge and approve a request from

another vehicle to form a platoon. If the driver does not respond



within five seconds, the request times out and the platoon is not

formed.

Type Primary

Includes Form Platoon

Extends Acknowledge Message

Cross-refs 16.2.2, 16.2.3

Dependent Use Cases Request Platoon

Use Case Form Platoon

Actors Driver (indirect), Other Vehicle (indirect)

Description The system forms a platoon with the requesting CACC-

equipped vehicle.

Type Secondary

Includes N/A

Extends N/A

Cross-refs 16.1, 16.2

Dependent Use Cases Approve Platoon, Request Platoon

Domain Model

A domain model is meant to depict the key elements in a system and how they interact. Each box

represents an element of the system, and the connecting lines indicate which elements can

communicate and affect one another through their operations. On the next page, Figure 4.2 gives

a domain model for the CACC system.



Figure 4.2: CACC System domain model



Data Dictionaries

Data dictionaries are used to provide more detail for each element in the domain model and

elaborating on attributes, operations, and relationships between the elements.

Element Name Description

Brake By Wire The Brake By Wire subsystem regulates

vehicle speed by applying brakes when

commanded to decrease the vehicle

speed by some magnitude.

Operations

isOperational():

bool

Brake By Wire subsystem performs a

self-check for full functionality:

returning true if no faults or errors are

detected; false otherwise.

getMagnitude():

float

Returns the current magnitude by which

the vehicle’s speed is being reduced.

setMagnitude(float):

void

Sets the magnitude by which the

vehicle’s current speed should be

reduced.

Relationships The Brake By Wire subsystem communicates with the Vehicle

Controller via messages sent over the CAN bus. The Vehicle Controller

issues commands to it when the vehicle’s speed must be reduced by a

specific value.


Camera Represents the camera subsystem, used

to capture image frames and confirm the

presence of objects near to the vehicle.

Operations

isOperational():

bool

Camera subsystem performs a self-

check for full functionality: returning

true if no faults or errors are detected;

false otherwise.

getImageData(): data Returns the most recent set of image

data.

Relationships The camera subsystem communicates with the Vehicle Controller via

messages sent over the CAN bus. The Vehicle Controller continuously

collects the camera’s image data and tries to coordinate between the

radar data and camera data to track the existing objects around the

vehicle.




DSRC Radio Communication The DSRC Radio

Communication subsystem is

utilized to communicate with

surrounding vehicles and the

infrastructure.

Operations

isOperational():bool DSRC performs a self-check for

full functionality: returning true

if no faults or errors are detected;

false otherwise.

getIncomingMessage():data DSRC receives a message

transmitted from another vehicle

or the infrastructure.

sendMessage(objectID,

data)

DSRC sends a message

(containing specific data) to an

object specified by its objectID

broadcastAlert(data) DSRC broadcasts a critical

message to all objects within

range.

Relationships The DSRC Radio Communication subsystem communicates with the

Vehicle Controller via messages sent over the CAN bus. The Vehicle

Controller has the ability to command the DSRC radio to send messages

to specific tracked objects and to receive and interpret messages from

external entities.


Electronic Throttle Control The Electronic Throttle Control

regulates vehicle speed by adding and

removing power.

Operations

isOperational():

bool

Electronic Throttle Control performs




getPower(): float Returns the current target power level



for the vehicle.

setPower(float

value): void

Sets the current target power level for

the vehicle.

Relationships The Electronic Throttle Control subsystem communicates with the

Vehicle Controller via messages sent over the CAN bus. The Vehicle

Controller issues commands to the throttle control when the vehicle’s

power levels must be modified.


GPS The GPS subsystem gathers data about

the vehicle’s surroundings, that is used

to help differentiate between fixed and

mobile objects. The vehicle location

data acquired from the GPS is also

broadcasted to trailing vehicles.

Operations

isOperational():

bool

GPS subsystem performs a self-check

for full functionality: returning true if no

faults or errors are detected; false

otherwise.

getLocalization():

data

Returns the vehicle’s current

localization data.

Relationships The GPS subsystem communicates with the Vehicle Controller via

messages sent over the CAN bus. The Vehicle Controller continuously

gathers the vehicle’s localization data so that it can be broadcasted to

trailing vehicles.


Radar Sensor The Radar Sensor subsystem scans in an

arc in front of the vehicle, gathering

data about the vehicle’s surroundings

and helping to detect, ID and track

nearby objects.

Operations

isOperational():

bool

Radar Sensor subsystem performs a






getRadarData(): data Returns the most recent set of processed

radar sensor data.

Relationships The Radar Sensor subsystem communicates with the Vehicle Controller

via messages sent over the CAN bus. The Vehicle Controller

continuously requests data from the Radar Sensor to be used in

identifying and tracking objects in the surrounding area.


Radar Transponder The Radar Transponder

subsystem sends vehicle ID

information to a requesting

trailing vehicle in order to

establish a DSRC radio link

between the two vehicles.

Operations

isOperational(): bool Radar Transponder subsystem

performs a self-check for full

functionality: returning true if

no faults or errors are detected;

false otherwise.

sendVehicleInfo(): void Sends information about this

vehicle out to the requesting

vehicle.

getIncomingRequest(data):

void

Receives an incoming message

requesting vehicle information.

sendRequest(vector

location): void

Sends a request to a vehicle at a

specific location, asking for the

vehicle’s ID information.

getIncomingResponse(data):

void

Receives an incoming response

message containing vehicle ID

information that can be used to

establish a DSRC radio link.



Relationships The Radar Transponder subsystem communicates with the Vehicle

Controller via messages sent over the CAN bus. The Vehicle Controller

issues commands to send an information request over the Radar

Transponder, and also provides vehicle data to respond to external

requests received by the transponder.


TrackedObject A tracked object represents an entity in

close proximity to the vehicle. It is

detected by the CACC system and

tracked so that the vehicle can react to

or communicate with the object as

needed.

Attributes

long:objectID The unique ID assigned to the tracked

object

velocity: vector Vector describing the velocity of the

tracked object as of the latest sensor

data processed by the Vehicle

Controller.

position: vector Vector describing the position of the

tracked object as of the latest sensor

data processed by the Vehicle

Controller.

Relationships Tracked objects are created and managed by the Vehicle Controller as it

processes data it receives from the camera and radar subsystems. The

Vehicle Controller maintains an array of tracked objects and updates

their velocity and location vectors as it processes new sensor data.


User Interface The User Interface represents the

physical components of the system

that the vehicle operator interacts

with directly to modify the system

state.

Operations

pressOnOffButton(): void Called when driver presses the

system On/Off button.

pressPauseButton():void Called when the driver presses the

system Pause button.

pressSetPlusButton():

void

Called when the driver presses the

system Set/+ button.

pressResumeMinusButton(): Called when the driver presses the



void system Resume/- button.

pressSetFollowingGap(int

level): void

Called when the driver presses a

Following Gap button.

pressBrakePedal(float

amount): void

Called when the driver steps on the

vehicle’s brake pedal.

pressGasPedal(float

amount): void

Called when the driver steps on the

vehicle’s gas pedal.

pressAcknowledgeMesage():

void

Called when the driver presses the

Accept button.

displaySpeed(float

speed): void

Displays the target speed on the

LCD screen.

displayMessage(data

maessage, bool

ackRequired)

Displays a message on the LCD

screen, with ackRequired set to true

if the driver is required to actively

respond to the message.

displayEmergencyWarning()

: void

Displays an emergency warning on

the LCD screen.

displayCruiseState(data

state): void

Displays cruise state information on

the LCD screen.

Relationships The User Interface communicates with the Vehicle Controller via messages

sent over the CAN bus. When an event occurs, the corresponding function is

called and a message is sent to the Vehicle Controller so that it can

appropriately respond to the event.


Vehicle Controller The Vehicle Controller is the central

hub of the CACC system. It processes

sensor data that is fed to it continuously

from the subsystems, responds to User

Interface events, coordinates

communication with all subsystems

over the CAN bus, and contains the

logic to make system decisions based on

information it receives.



Attributes

cruiseLevel: int Represents the current system cruise

level: CC (1), ACC (2), CACC (3).

followingGapLevel:

int

Represents the current system following

gap level: Passive (1), Intermediate (2),

Aggressive (3)

isPlatooning: bool Indicates whether or not the vehicle is

currently engaged in a platooning effort.

Operations

engageCruise(int

level): void

Engages the system at the specified

cruise level.

disengageCruise() Disengages the system.

setFollowingGap(int

gapLevel)

Sets the system following gap level.

processData(data

incoming)

Called when the Vehicle Controller

receives data from a subsystem and

needs to process and analyze it.

addTrackedObject

(TrackedObject obj)

When the Vehicle Controller detects and

confirms the presence of a new object in

its immediate surroundings, it adds

information about that object to its

Tracked Objects array.

removeTrackedObject

(TrackedObject obj)

Removes a tracked object from the

Vehicle Controller array.

Relationships The Vehicle Controller communicates with every subsystem involved in

the CACC system by sending messages over the CAN bus. The Vehicle

Controller also keeps track of TrackedObjects and responds to events

that occur via the User Interface.



Scenarios and Sequence Diagrams

Scenarios provide representative examples of how each use case could occur in the real world.

The sequence diagrams corresponding to each scenario depict the flow of messages between

system elements that occurs as the scenario takes place. The boxes at the top of the diagram

represent system elements, and the arrows going between the elements are meant to demonstrate

how the elements interact using messages and operations. The sequence diagrams for each

scenario are shown in Figures 4.3 to 4.14

Turn On: The driver is driving down a highway and decides to use the cruise control. The driver

presses the On button. A moment later, the LCD screen on the dashboard lights up with a

message listing Cruise Control, Adaptive Cruise Control, and Cooperative Adaptive Cruise

Control as options, with Cooperative Adaptive Cruise Control selected. The driver then selects

the desired mode of operation with the Up/Down selection buttons on the steering wheel, then

presses the Accept button when the desired mode is selected. The dashboard then indicates that

the desired cruise control mode is in the on state and ready for the target speed to be set.

Figure 4.3: Sequence diagram for system Turn On scenario



Pause: The driver approaches a traffic jam and realizes that the cruise control will be useless. In

preparation, the driver decides to temporarily stop using the cruise control. The driver presses the

Pause button. Immediately the vehicle begins to coast until the driver reapplies throttle using the

gas pedal. The dashboard indicates that the cruise control is paused but still on.

Figure 4.4: Sequence diagram for Pause scenario

Resume: The driver leaves a traffic jam area in which he or she decided to pause the cruise

control. As the road ahead is now clear, the driver presses the Resume button. If the vehicle speed

is below 25 miles per hour, nothing will happen. If the vehicle speed is above 25 miles per hour,

the dashboard indicates that the cruise control is on and active, and the vehicle begins

accelerating to the target speed from when it was paused.

Figure 4.5: Sequence diagram for Resume scenario



Turn Off: the driver is nearing their neighborhood and decides to deactivate the cruise control.

The driver presses the Off button. Immediately the dashboard indicates the cruise control is off

and the vehicle begins to coast until the driver reapplies throttle using the gas pedal.

Figure 4.6: Sequence diagram for system Turn Off scenario



Set Following Gap: the system is fully functional and engaged at the CACC level. The vehicle is

taking part in a platoon, and the driver decides that their vehicle is following the lead vehicle too

closely, and they want to increase the following gap. The driver presses the Passive following gap

button to lower the gap from the Intermediate level to the Passive level. Once the passive level is

achieved, the vehicle maintains a set speed and following distance.

Figure 4.7: Sequence diagram for Set Following Gap scenario



Set Target Speed: the system is fully functional and engaged at the ACC level. The vehicle’s

target speed is set at 65 mph, but it is approaching a construction zone where the speed limit will

be reduced to 50 mph. The driver presses the ‘Set –’ button multiple times in order to lower the

vehicle’s target speed to accommodate the new speed limit.

Figure 4.8: Sequence diagram for Set Target Speed scenario



Set Cruise Level: the driver presses the system ‘On’ button and after vehicle startup processes,

the LCD screen displays the cruise level options that are currently available. The driver uses the

Up/Down Arrow button to select cruise level ACC on the screen and presses the Accept button.

The system engages in the ACC level.

Figure 4.9: Sequence diagram for Set Cruise Level scenario



Request Platoon: a fully working system, running CACC, not platooning. The system is

following another vehicle, also equipped with CACC, at the same speed and direction. The

system detects that the requirements for forming a platoon have been met and sends a message to

the user interface asking for the driver’s permission to form a platoon. The driver gives

permission, and the system sends a radio broadcast to the leading car asking for its permission to

form a platoon. The radar communication system gets confirmation, and the system enters the

platooning state.

Figure 4.10: Sequence diagram for Platoon Request scenario



Platoon Requested: A fully working system, running CACC, not platooning. Another trailing

vehicle requests to form a platoon with our vehicle. The system sends a message to the user

interface asking for the driver’s permission to form a platoon. The driver gives permission, and

the system sends a radio broadcast to the trailing car giving permission to form a platoon. The

system enters the platooning state.

Figure 4.11: Sequence diagram for receiving a Platoon Request scenario



Acknowledge Message: A fully working system, running CACC, not platooning. The camera

has a hardware issue where the lens can no longer refocus and take accurate photos. Encountering

this error, the camera sends a message to the vehicle controller, that will then shutdown the

CACC system and alerts the driver of the error. The diver must then respond to the message.

Figure 4.12: Sequence diagram for Acknowledge Message scenario



Request ID: A fully working system, running CACC, not platooning. Another car that is also

running CACC, pulls behind the vehicle and sends a request for vehicle ID. The radar

transponder will receive the request, process it through the vehicle controller, and send the

requested vehicle data back to the trailing vehicle.

Figure 4.13: Sequence diagram for receiving an ID Request scenario

Broadcast Alert: A fully working system, running CACC, not platooning. Suddenly, another car

pulls in front of our vehicle at a velocity and distance that is going to cause an imminent collision.

The radar senses the other vehicle’s position and sends the information to the vehicle controller.

The vehicle controller will then shutdown the CACC system, display the emergency warning for

the driver through the User Interface, and send out an emergency broadcast alert over DSRC

radio communication.

Figure 4.14: Sequence diagram for Broadcasting an Alert scenario



System State Diagrams

State diagrams are used to show the different states that a system can be in and the events that

must occur for the system to switch between states. Each state of the system has specific attribute

values that differentiate it from the other states. The transitions between states can occur due to

events or actions (generated as a result of an event), and can have guard conditions (that require a

condition to be true for the transition to occur).

The first state diagram shown below depicts the entire system, with the CACC and ACC substates

broken out into separate graphs for better readability. Figures 4.15, 4.16, and 4.17 show the

system states and transitions between.

Figure 4.15: Overall system state diagram

Figure 4.16: ACC level state diagram

At the ACC level of functionality, the vehicle can be in a Following or Not Following

state. When in the Following state, the vehicle is continually adjusting and maintaining

its speed based on the movement of the vehicle in front of it. In the Not Following state,

the vehicle is maintaining a set speed while continually sensing for a vehicle ahead.



Figure 4.17: CACC level state diagram



5. Prototype

The prototype will show a view of the car's dashboard displays, including speedometer, cruise

control indicator lights, multifunction display, and warning lights. These indicators will mimic

the displays that would be found in a real automobile in the given scenarios.The prototype will be

controlled by first selecting a scenario from the top of the screen and then pressing the "Run"

button. The user can then provide input to the prototype by clicking the buttons below the

dashboard display, such as On/Off, Pause, Set/+, Resume/-, and Accept.

5.1 How to Run Prototype

To run the prototype, a web browser with JavaScript is required. Examples of browsers that have

been confirmed to be compatible are:

Safari 5.1.1

Firefox 7.0.1

Google Chrome 15.0.874

Many other browsers should work but have not been tested. The browsers recommended by the

framework used to build the prototype are:

Internet Explorer 7+

Firefox 2+

Safari 3+

Google Chrome

Opera 9+

The prototype has been tested on the iPad and has been confirmed to be functional but not ideal

for touch input. It has not been tested on smartphones or other tablets and should not be expected

to work on these devices.

The URL of the protype is:

http://www.cse.msu.edu/~435cruise3/cappuccino_prototypes/prototype_2/

5.2 Sample Scenario

An example of a scenario in which the prototype might be used is to simulate what happens in an

imminent crash situation.

Upon selecting the "Imminent Crash" scenario and running it, the vehicle will be traveling at 60

miles per hour with the cruise control activated and an aggressive following gap. Ten seconds

later, another vehicle traveling at a very low speed will cut in front of the vehicle. The system,

recognizing that a crash is unavoidable, will deactivate. At the same time, warning lights near the

windshield will flash, drawing the driver's eyes to the road. Although not shown in the prototype

interface, the vehicle will also prepare for impact by tightening seatbelts, pre-pressuring brakes,

precalculating airbag velocity, and broadcasting an emergency alert to other vehicles.

Figures 5.1 and 5.2 show screenshots of the system prototype upon selecting and running the

Imminent Crash scenario.



Figure 5.1: Prototype screenshot showing selection of Imminent Crash scenario.



Figure 5.2: Prototype screenshot while running the Imminent Crash scenario.



6. References

[1] Project Website: http://www.cse.msu.edu/~435cruise3

[2] Guo-sheng Feng; Wei Zhang; Su-me Jia; Han-sheng Wu; , "CAN Bus Application in

Automotive Network Control," Measuring Technology and Mechatronics Automation

(ICMTMA), 2010 International Conference on , vol.1, no., pp.779-782, 13-14 March

2010.

[3] Yasser L. Morgan, “Managing DSRC and WAVE Standards Operations in a V2V

Scenario,” International Journal of Vehicular Technology, vol. 2010, Article ID 797405,

18 pages, 2010.

7. Point of Contact

For further information regarding this document and project, please contact Prof. Betty

H.C. Cheng at Michigan State University (chengb at cse.msu.edu). All materials in this

document have been sanitized for proprietary data. The students and the instructor

gratefully acknowledge the participation of our industrial collaborators.

http://www.cse.msu.edu/~435cruise3

software requirements specification (srs) project …435cruise3/resources/srsfinalpdf.pdf ·...

Documents