Software Requirements Specification (SRS)cse435/Projects/F2014/Groups/CACC/web/... · The purpose...
Transcript of Software Requirements Specification (SRS)cse435/Projects/F2014/Groups/CACC/web/... · The purpose...
1
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)
Cooperative Adaptive Cruise Control System
Authors: Andy Lieblich, Elizabeth Florian, Marco Botros, Zachary Ray
Customer: William Milam, Ford Motor Company
Instructor: Betty H.C. Cheng
1 Introduction This document outlines the requirements of the Cooperative Adaptive Cruise Control
system (CACC). Following the introduction, the purpose of this document as well as the
scope, definitions, and organization of the project are expanded. After this, the system is
described in more detail with respect to product perspective and function as well as user
characteristics. This section of the document also describes constraints, assumptions and
dependencies, and the appropriation of requirements. To aid in the formalization of the
system, a detailed list of requirements is used to capture the overall functionality. Next,
models are provided to show visually how the system interacts with users, other vehicles,
and the surrounding environment. Finally the prototype is described in detail to give the
customer a better idea of how the system functions. The last section of this document
gives all references and points of contact for further inquiries about the system.
1.1 Purpose
The purpose of the Software Requirements Specification (SRS) is to describe how the
CACC system behaves functionally so that the customer understands exactly what is
being developed for their desired product. The document also helps to complete the
agreement between the developer and customer so that the specified requirements are
being implemented to the customer’s satisfaction.
The SRS explicitly defines requirements, system behavior through modeling diagrams,
and prototypes to aid the customer in their understanding. This document also helps to
aid programmers in the solidification of requirements to be implemented and as a general
guide to aid future development, improvement, and maintenance.
2
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)
1.2 Scope
The software system being developed is the CACC system. This system is being
implemented as an embedded system for automobiles. The goal of this system is to make
highway travel safer by automating tasks typically handled by a human driver.
The CACC system functions much like the standard cruise control system that most users
are familiar with. The CACC system also utilizes forward facing radar and camera
systems. Both the camera and radar systems work to track vehicles in front of the user’s
vehicle. Once a vehicle has been detected, the CACC system automatically decreases the
user’s vehicle to the following distance specified by the user. After a vehicle is detected
the user has the option to start or join a platoon. Once the user is part of a platoon, the
vehicle communicates via radio to other vehicles in the platoon to get their GPS
information including speed, position, and direction of travel. Once the system is
engaged, the user has the option to increase or decrease the speed by increments of one
mile per hour. The user is still responsible for keeping their vehicle in its lane as the
system only affects the vehicle’s forward motion. The GPS system then works to help
detect possible collisions. Since all of the vehicles in the platoon are sharing information,
if one vehicle has to stop suddenly, then there is a significantly reduced chance of getting
into an accident because all of the vehicles are connected and can share data almost
instantly effectively making highway cruise control safer.
1.3 Definitions, acronyms, and abbreviations
Table 1.1 contains the definitions of all terms, acronyms, and abbreviations used in this
document.
Term Description
CACC The Cooperative Adaptive Cruise Control software system is responsible for tracking
other vehicles through GPS, radar, and camera systems and adjusting the braking and
acceleration of a user's vehicle accordingly
GPS The Global Positioning System is used to determine where a vehicle is, what speed
the vehicle is traveling at, and what direction the vehicle is headed. This system is
also used to help track and detect possible collisions between vehicles in the platoon
Lead Vehicle The vehicle at the front most position in the platoon that sets the speed of the platoon
Platoon A group of vehicles all engaged in the Cooperative Adaptive Cruise Control system.
The group may only travel in a single lane. A vehicle leaving the lane results in the
vehicle leaving the platoon
Target Vehicle The vehicle directly in front of the user’s vehicle. This is the vehicle that will be
tracked by the camera and radar systems
Trailing Vehicle The vehicle directly behind the user’s vehicle
CAN BUS The Controller Area Network Bus is the primary way that subsystems in the vehicle
will communicate with each other
VC The Vehicle Controller is responsible for coordinating all CACC subsystems and
3
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)
ultimately the main controller of the vehicle’s throttle and braking systems
ETC The Electronic Throttle Control is responsible for managing the power of the engine
CC The Cruise Control system ensures speed of the vehicle is constant and equal to the
speed set by the user
ACC The Adaptive Cruise Control system controls a vehicle’s acceleration and braking
depending on the location of the vehicle in front of it
Performance
Envelope A data set shared between vehicles in a platoon that describe a vehicle’s acceleration
and braking capabilities
Table 1.1: Definitions, acronyms, and abbreviations
1.4 Organization
Following the introduction of the CACC system the SRS describes the system in further
detail. The SRS does this by defining system design and layout through product
perspective and function as well as user characteristics and constraints. The CACC
system is then described in terms of requirements and accompanying models. Finally the
system prototype is explained as a practical implementation of the listed models. Lastly
references and points of contact are listed.
2 Overall Description This section provides a detailed description of the system. First the system’s functionality,
constraints, use prerequisites, and dependencies are discussed. This section also discusses the
context in which the system is used and what other subsystems it makes use of.
2.1 Product Perspective The CACC system will work closely with different subsystems in the vehicle. As shown in
Figure 2.1 below, the system receives information from the radar, GPS, and camera systems. The
system then sends this information to the radio where it is broadcast to other vehicles in the
platoon. The system also controls the Electronic Throttle Control system (ETC) and the Braking
system. Both of these subsystems work to control the speed of the vehicle. The system works with the limited resources of processing and memory in the vehicle while still
being very reliable. The system works in the current context of the vehicle using the Controller
Area Network (CAN) bus. The system also uses different peripherals that are shared between
systems. For instance, the camera is also used by the lane keeping system which is separate from
CACC. The user is also able to interact with the system easily. In the event of software failure,
the system informs the user that they are resuming control of the vehicle.
4
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)
Figure 2.1 Block Definition Diagram
2.2 Product Functions The system maintains a constant forward vehicle speed, as specified by the user. In addition,
using a combination of forward facing radar and camera systems, the system detects when a
target vehicle is in the user vehicle’s forward path and adjusts its own speed via throttle and
braking control to maintain one, two, or three car length(s) behind the target vehicle. The system
also receives GPS information such as, location, speed, and direction from other vehicles in the
platoon, and broadcasts its own GPS information. The system also receives information from the
satellite which helps with collision avoidance by checking to see if any vehicles are going to
collide with each other. Using the information from the different subsystems, the CACC system sets up a platoon of
vehicles that follow a lead vehicle with at least one car length of space between each vehicle. Any
vehicle with the system can receive requests to lead a platoon or send requests to join one. The
vehicle at the forefront of the platoon sets the speed for the whole platoon. Each following
vehicle in the platoon uses a combination of GPS information from the vehicles in front of it,
along with information from its own radar and camera sensors, to control its throttle and brakes to
achieve the desired following distance. A description of the vehicle’s performance envelope is
also shared among vehicles in the platoon, which includes acceleration and braking abilities of
the vehicle. The braking capabilities are shared in units of gravitation force (Gs). The
performance envelope helps the vehicles in the platoon make decisions about their braking when
it needs to be applied.
2.3 User Characteristics The user is expected to know how to drive a vehicle, have some minimal training about operating
a cruise control system, and have prior knowledge about the functionality of the buttons and
dashboard indicators.
5
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)
2.4 Constraints The system must be secure and safe to use in order for it to be used commercially. The constraints
of the system are:
1. The system must process information and make decisions in real-time.
2. The system must be able to inform the users of its status effectively and clearly.
3. The system must be able to hand control to the user in case of a system failure.
2.5 Assumptions and Dependencies The main dependency for the system is that all subsystems that the CACC system requires such
as camera, GPS, radar, radar transponder, radio, brakes, and ETC are all in place, operable, and
can communicate with the VC.
2.6 Appropriating of Requirements All the requirements of the project will be included in this version of the system.
3 Specific Requirements This section defines the requirements of the CACC system. The requirements are
enumerated below for clarity.
1. Radar Sensing
1.1. Radar will look to the target vehicle and constantly monitor for vehicles in
the vehicle’s path. If a vehicle is outside of the safe range, then the vehicle
will maintain its current speed. Once a vehicle enters an unsafe range in
front of the vehicle, this data would be given to the VC to handle when the
speed would be adjusted. The safe and unsafe ranges are determined by
the following distance that the user set. Anything less than the following
distance set by the user is considered an unsafe range. Anything greater
than or equal to the following distance is considered a safe range.
1.2. The system transponder is constantly monitoring at a rate of one cycle per
10 milliseconds for incoming link requests and sending out link requests
for other vehicles to connect to.
2. Radio Communication
2.1. The system will constantly broadcast its current speed and position to the
rest of the platoon and it will constantly communicate with the
infrastructure to get environmental conditions.
2.2. Radio communication will also be responsible for receiving metrics such
as speed and position from the rest of the platoon and the infrastructure.
3. ETC
3.1. The system will regulate the vehicle’s speed based on environmental
conditions such as rain or snow, and speed limits that are determined by
the infrastructure communication, by adding or removing power to the
vehicle.
3.2. The ETC will also increase or decrease the speed by adding or removing
power when the user increases or decreases the speed control.
4. The system will apply the vehicle’s brakes to a force that does not exceed 2Gs.
6
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)
5. The system will give its ID to requesting trailing vehicles on demand. The two
vehicles will then stay in contact with each other after initializing the radio
communication to relay GPS and speed data.
6. GPS System
6.1. The GPS system will communicate with satellite data to get the vehicle’s
position, speed, and direction information.
6.2. The GPS system will aid the radar system in compensating for curves and
hills on the roadway by communicating the information about their
location several seconds in advance.
6.3. If the radar system fails, then the GPS system will be used in place of
radar to maintain current platoon function.
7. Camera Sensing
7.1. Along with the radar system, the system will use a camera to identify a
target vehicle as well as estimate the target vehicle’s distance and relative
speed.
7.2. In the event of radar failure, the camera will aid the GPS system in
maintaining the platoon functionality.
8. Vehicle Controller
8.1. The system will coordinate all subsystems by taking in data from the
radar, camera, and GPS systems and determining a safe output for the
ETC and Braking System. This output will also take into consideration the
following distance that was set by the user.
8.2. The system will determine the vehicle’s speed, take into account the speed
of the lead vehicle, and adjust its own speed to maintain a ‘safe’ distance
based on environmental conditions, such as rain or snow and road
conditions, such as icy roads or flooded roads.
8.3. The system will maintain a current state consisting of its speed and
relative position to the target vehicle. The system will also include relative
environmental information in the state such as speed limits and road
conditions
8.4. The system will command the vehicle’s brakes and throttle to maintain a
speed within a predetermined minimum and maximum speed at a relative
distance to the target vehicle. This speed is set by the user when the user
turns on the CACC system.
8.5. The system will receive information from the radar system to update the
system’s current state at a rate of 10 milliseconds.
8.6. The system will send any requested information, such as speed and
position to other vehicles within the platoon though radio communication
links
8.7. The VC manages safe function of the platoon by setting the maximum
speed of the platoon to 85 miles per hour and the maximum number of
vehicles allowed in the platoon to 8 vehicles. If a vehicle is going over 85
miles per hour, then it will not be allowed to join or form a platoon.
7
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)
4 Modeling Requirements In order to give both the customer and developers a better understanding of the how the
CACC system functions, the following sections give examples of models of the system.
Use cases are first expanded followed by the domain model and data dictionary. Finally
sequence diagrams are showcased and the section is closed with system state diagrams.
4.1 Use Cases
The Use Case diagram in Figure 4.1 shows the functionality of the CACC system. In this
diagram, the actors are represented by people. These are the different entities that are not
a part of the system itself, but have an effect on the system. The box represents the
CACC system and anything within this box is a part of this system. The ovals inside of
the system represent the different uses of the system. There are lines connecting either
actors to use cases, or use cases to other use cases. These lines represent associations.
There are also lines with arrows pointing towards a use case. One is an include which
shows that the use case that is pointed to by an arrow is included as a part of the use case
that the arrow is coming from. Another line with an arrow is an extends. These lines
show special cases that have to be met by a certain circumstance. The arrow is pointing to
the use case that has the regular functionality.
Figure 4.1 Use Case Diagram
8
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)
Use Case: Start Up
Actors: User
Description: The user starts the CACC which initiates the camera, radar sensors, GPS
system, and communication systems.
Type: Primary
Includes: Communication, Car Monitor
Cross References: All Requirements
Use Cases: All
Use Case: Manual Override
Actors: User
Description: The user is able to override the CACC system at any time
Type: Primary
Cross References: Requirements 3, 3.2, and 4
Use Cases: Speed Control, Car Monitor
Use Case: Speed Control
Actors: Electronic Throttle Control, Braking System, User
Description: The user is able to control the speed of the vehicle. The speed is either
maintained, increased, or decreased depending on the distance and speed of the target
vehicle. The ETC increases or decreases power to the engine depending on the speed of
the vehicle and whether or not the vehicle is within a safe or unsafe range as specified by
the following distance. If the lead vehicle wants to set the speed to over 85 miles per
hour, then the system will be turned off, the user will be notified that the system is
shutting down because they are exceeding the maximum speed of the platoon, and the
user will be handed back control.
Type: Primary
Cross References: Requirements 3, 3.1, 3.2, 4, and 8.7
Use Cases: Distance Maintaining, Car Monitor
Use Case: Communication
Actors: Radio
Description: This is the short range communication between multiple vehicles. This
communication will tell the other vehicles in the platoon about its location and speed.
There can be up to 8 vehicles in the platoon that the radio will need to communicate with.
If the short range communication can not broadcast to all of the vehicles at once because
some are out of range, then the information can be retransmitted through other vehicles
throughout the platoon so that the vehicles outside of the broadcast range can receive the
information.
Type: Primary
Cross References: Requirements 2, 2.1, 2.2, 8, 8.6, and 8.7
Use Cases: Communication Failure, Start Up
Use Case: Communication Failure
Actors: Radio
Description: If the communication between two vehicles fails due to weather or the
9
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)
communication link was dropped, then the VC needs to know so that it can try to
reestablish the communication. If the communication can not be reestablished or the
process times out while trying to reconnect, then the system needs to be turned off and
the control needs to be handed back to the user. If the radio malfunctions, then the system
needs to be turned off and the control needs to be handed back to the user.
Type: Primary
Extends: Communication
Cross References: Requirements 2, 2.1, 2.2, 8, and 8.6
Use Cases: Communication
Use Case: Radar Failure
Actors: Radar
Description: The radar sensors work with the camera sensors to detect target vehicles. In
addition, it identifies the target vehicle’s ID so that a communication link can be
established. If the radar sensors fail, then the camera sensors will still be used to identify
target vehicles and estimate their distance and speed. The GPS will be used to maintain
platoon function.
Type: Primary
Cross References: Requirements 1, 5, 6, 6.3, and 8
Use Cases: Car Monitor
Use Case: Camera Failure
Actors: Camera
Description: The camera is used to visually identify target vehicles and estimate their
distance and relative speed. If the camera fails, then the GPS system can be used in its
place to gain the speed and position information. The radar will continue to track and
identify vehicles, and the radio will continue to communicate with the other vehicles.
Type: Primary
Cross References: Requirements 1, 2, 4, 6, 6.3, and 8
Use Cases: Car Monitor
Use Case: GPS Failure
Actors: GPS
Description: The GPS is used to maintain vehicle position, speed, and direction
information. Also, it helps the radar system differentiate between vehicles and other fixed
targets along with helping with the curves and hills in the roadway. When the GPS fails,
the system will need to be shut down because the GPS maintains the vehicle’s position,
speed, and direction information and this is information that is essential to maintain the
platoon functionality.
Type: Primary
Cross References: Requirements 6, 6.2, 6.3, 8, 8.1, and 8.6
Use Cases: Car Monitor
10
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)
Use Case: Car Monitor
Actors: Radar, Camera, GPS
Description: This use case contains the radar, camera, and GPS systems that work
together to carry out the following functions: detect other vehicles, maintain position,
maintain speed, and collect the directional information on other vehicles. This will also
be used to differentiate between vehicles and fixed objects as well as compensate for hills
and curves in the roadway.
Type: Primary
Includes: Distance Maintaining
Cross References: Requirements 1, 1.1, 1.2, 3, 3.1, 3.2, 4, 5, 6, 6.1, 6.2, 6.3, 7, 7.1, 7.2, 8,
8.1, 8.2, 8.3, 8.4, and 8.5
Use Cases: All
Use Case: Distance Maintaining
Actors: Radar, Camera, GPS, Electronic Throttle Control, Braking System
Description: The GPS, camera, radar, and radio systems work together to detect other
vehicles and gain information about their speed, direction, and position. It uses this
information to maintain a safe distance from the target vehicle.
Type: Primary
Includes: Speed Control
Cross References: All Requirements
Use Cases: Speed Control, Car Monitor, Communication
4.2 Domain Model The domain model gives a visualization of how the major system components
communicate with each other. Each box represents a subsystem of the CACC system.
Each line represents a communication link between the subsystems. This means that the
subsystems can directly talk to each other through the given operations of each
subsystem. Figure 4.2 below gives a representation of the CACC domain model.
11
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)
Figure 4.2: CACC System Domain Model
4.3 Data Dictionary
The data dictionary further expands the domain model by detailing the functions and
attributes used in the subsystems and further explains how the system communicates
within itself. Data dictionaries are made up of element names and descriptions, their
attributes, operations, and relations to other subsystems.
12
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)
Element Name Description
Vehicle Controller The Vehicle Controller (VC) is the main class in
the CACC system. It takes input from all of the
sensors and determines the speed of the vehicle.
Attributes:
int:cruiseSpeed The maximum cruising speed of the vehicle.
int:followDistance The distance to follow behind a target vehicle.
bool: isLead A flag to show an indicator to the user if they are
the lead vehicle in a platoon.
Operations:
isFunctioning() Does a check to make sure the VC is functioning
correctly by making sure all subsystems are
responding correctly.
increaseSpeed() Increases the cruising speed by increasing the
power of the ETC.
decreaseSpeed() Decreases the cruising speed by decreasing the
power of the ETC.
systemOn() Turns on the CACC system.
systemOff() Turns off the CACC system.
sendJoinPlatoon() Sends a request to a vehicle outside the platoon to
join the platoon if their CACC system is turned on.
receiveJoinPlatoon() Handles when another vehicle wants to join a
platoon the user is currently in.
exitPlatoon() Handles when a user exits from a platoon.
splitPlatoon() Splits one platoon into two separate platoons when
a vehicle unexpectedly enters or exits from the
middle of the platoon.
resume() Resumes CACC with the same variables before the
cancel button was pressed.
cancel()` Cancels the current CACC system and puts the
system in a neutral state without shutting down the
system.
getFollowDistance() Returns the follow distance of the user’s vehicle.
increaseDistance() Increase the following distance of the user’s
vehicle.
13
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)
decreaseDistance() Decrease the following distance of the user’s
vehicle.
receiveJoinRequest() Receives a request from another vehicle to join its
current platoon or create a new one.
setSpeed() Sets the user’s cruising speed.
response() A success or failure response sent as an
acknowledgement.
memoryCheck() Before a vehicle is accepted in a platoon the VC
checks to make sure it has enough space in
memory to accommodate another vehicle.
Relationship The VC talks to every other subsystem within the
system. It also handles the user’s control requests
and is responsible for electronic throttle and
braking management.
Element Name Description
Camera The camera is used to aid the radar tracking
subsystem by identifying the target vehicle’s speed
and distance from the user’s vehicle.
Attributes:
Operations:
isFunctioning() Check to make sure that the camera system is
functioning correctly.
identifyTargetVehicle() Aids in the detection of a target vehicle.
estimateSpeed() Returns the estimated speed of the target vehicle.
estimateDistance() Returns the estimated distance of the target
vehicle.
Relationship The camera subsystem continuously talks to the
VC to help aid the radar system in the tracking of
target vehicles so that the VC can determine
whether or not to increase or decrease speed and
braking force.
Element Name Description
Braking Controller The braking subsystem is responsible for
14
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)
controlling vehicle speed by applying braking
pressure.
Attributes:
int:brakeForce The braking force the braking system will apply
when the brakes are engaged.
Operations:
isFunctioning() Check to make sure that the braking system is
functioning correctly.
getBrakeForce() Returns the braking force that the braking system
will use.
setBrakeForce(int brakeForce) Sets the braking force that the braking system will
use.
applyBrakes(int brakeForce) Applies a given brake force to slow the vehicle.
Relationship The braking system talks with the VC. Brakes are
the system default for any safety issue where there
is conflicting information from other subsystems.
Element Name Description
Electronic Throttle Control The Electronic Throttle Control (ETC) subsystem
is responsible for controlling vehicle speed by
regulating power to the engine.
Attributes:
int:power The amount of power that the subsystem will apply
when the ETC is engaged.
Operations:
isFunctioning() Check to make sure that the ETC system is
functioning correctly.
getPower() Returns the engine power that the ETC system will
use.
setPower(int power) Sets the engine power that the ETC system will
use.
applyPower(int power) Applies the given power to the engine.
Relationship The ETC system talks with the VC to set engine
power appropriately.
15
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)
Element Name Description
Radar The main function for the radar subsystem is to
scan in front of the user’s vehicle to help detect,
identify, and track other vehicles.
Attributes:
Operations:
isFunctioning() Check to make sure that the radar system is
functioning correctly.
detectTargetVehicle() Scans the area in front of the vehicle looking for
other vehicles.
identifyTargetVehicle() Identifies target vehicles after detection, looking
for the CACC system.
trackTargetVehicle() Tracks the target vehicle to keep the user vehicle at
a safe distance behind.
getTargetVehicleData() Gets the target vehicle’s information such as speed
and position.
noTargetVehicle() Lost track of target vehicle, or scanned but was
unable to find any.
Relationship The radar subsystem is the primary system for the
detection and identification of target vehicles.
Once detected the radar feeds information to the
VC where the VC can determine if it should
increase or decrease braking pressure or engine
power. It also talks to the radar transponder to send
vehicle information to the vehicle behind it.
Element Name Description
User Controls The user controls refer to the buttons and
indicators located on the dash of the vehicle that
the user will control the subsystem with.
Attributes:
Operations:
16
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)
isFunctioning() Check to make sure that the user control subsystem
is functioning correctly.
btnOn() Turns the CACC system on.
btnOff() Turns the CACC system off.
btnIncreaseSpeed() Increases the set cruising speed if only in CC mode
or maximum cruising speed if in CACC mode.
btnDecreaseSpeed() Decreases the set cruising speed if only in CC
mode or maximum cruising speed if in CACC
mode.
btnIncreaseDistance() Increases the distance of the gap between the user's
vehicle and the target vehicle.
btnDecreaseDistance() Decreases the distance of the gap between the
user's vehicle and the target vehicle.
btnEngage() Sends a request to a platoon to join.
setDistanceIndicator() Sets the distance indicator based on the current
following distance.
setInPlatoonIndicator() Sets the indicator to let the user know they are part
of a platoon.
setLeadCarIndicator() Sets the indicator to let the user know they are the
lead vehicle in a platoon.
setActiveIndicator() Sets the indicator to let the user know that the
CACC system is active, not canceled.
setInactiveIndicator() Set the indicator to let the user know that the
CACC system is not active, that it is currently
canceled.
btnCancel() Cancels the current CACC system without turning
the system off. This has the same functionality as a
pause function.
btnResume() Resumes the CACC system from a canceled state
as long as the whole system was not shut off.
btnSetSpeed() Sets the user vehicle’s cruising speed.
Relationship The user controls are the primary way for the user
to interact with the system. This subsystem talks
directly to the VC to help determine the action the
VC should take.
Element Name Description
17
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)
GPS Responsible for gathering vehicle data,
broadcasting it to other vehicles, as well as
differentiating between vehicle targets and known
fixed targets.
Attributes:
Operations:
isFunctioning() Check to make sure that the GPS subsystem is
functioning correctly.
getSpeed() Returns the speed of the user’s vehicle.
getPosition() Returns the position of the user’s vehicle.
getDirection() Returns the direction of the user’s vehicle.
Relationship The GPS talks to the VC to give it information
about the position of the vehicle so that the VC can
determine the action it should take. From here, the
VC can broadcast the GPS information through the
radio.
Element Name Description
Radio The primary means of communication within the
platoon for the vehicles to talk to each other and
pass information.
Attributes:
Operations:
isFunctioning() Check to make sure that the radio subsystem is
functioning correctly.
requestID() Ask for a vehicle’s unique identification.
broadcastGPS() Sends out the user vehicle’s GPS to the entire
platoon.
receiveGPS() Receives GPS information being broadcast by all
other vehicles in the platoon
sendJoinPlatoon() Sends request to vehicle in front to join it in
already formed platoon or new platoon.
sendRequestResponse() Sends an acceptance or denial to a request of
another vehicle to form a new platoon or join the
existing one.
18
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)
receiveInfrastructureSignal() Receives information broadcasted by the
infrastructure.
noTrailingVehicle() Does not receive GPS information of trailing
vehicle or receives an exit signal (when the system
is the lead vehicle).
reestablishConnection() If radio contact is lost for any vehicle in the
platoon, the radio first tries to reestablish a
connection before booting the lost vehicle from the
platoon
Relationship The GPS system communicates with the VC where
vehicle position, speed, and direction can be
stored, analyzed, and then sent to the platoon.
Element Name Description
Radar Transponder Responsible for giving vehicle ID information to
requesting trailing vehicle.
Attributes:
Operations:
isFunctioning() Check to make sure that the radar transponder
subsystem is functioning correctly.
sendVehicleID() Sends user vehicle’s identification to trailing
vehicle when requested.
Relationship The radar transponder talks with the trailing
vehicle, giving it information about the user’s
vehicle when requested.
Element Name Description
Platoon Vehicle Represents a vehicle in a platoon. This save
information about the vehicle including its ID and
position in the platoon.
Attributes:
int ID A vehicle’s unique identification number.
int Position The vehicle’s position in the platoon. 0 is the lead
vehicle and the number increases by 1 for each
19
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)
position in the platoon.
Operations:
Relationship Platoon vehicles interact with the camera, radar,
radar transponder, and radio subsystem to
effectively communicate vehicle information to the
other vehicles in a platoon.
4.4 Sequence Diagrams
Sequence diagrams show a more detailed view of how the system behaves technically
when certain events or activities happen within the system. Figures 4.3 through 4.10
show the sequences for user scenarios. In each scenario there is an actor who starts an
interaction with the CACC system. Arrows represents messages sent between subsystems
when certain events happen and the boxes represents the subsystem that the messages is
being received at or sent from.
Figure 4.3 depicts the “turn on” scenario where a user enters the highway and wants to
turn the CACC system on.
Figure 4.3: Turn On Sequence Diagram
Figure 4.4 depicts the “turn off” scenario where, a user is using the system on the
highway and is approaching an exit. The user decides to turn off the CACC system to
take control of the vehicle and exit the highway.
20
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)
Figure 4.4: Turn Off Sequence Diagram
Figure 4.5 depicts the “send request to join platoon” scenario where, a user is driving on a
highway and decides to turn on the system. Then the user notices a platoon of cars
engaged in the CACC system. They request to join the platoon.
Figure 4.5: Send Request to Join Platoon Sequence diagram
21
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)
Figure 4.6 illustrates the “receive request to join platoon” scenario where a user is driving
on a highway and has the CACC system on, but is currently not in a platoon. Another
vehicle requests to join the user by creating a platoon.
Figure 4.6: Receive Request to Join Platoon Sequence Diagram
Figure 4.7 shows the “cancel” scenario. A user is driving along a highway and is the last
person in a platoon of three vehicles. The user has been driving for a while and decides to
pull over at the next rest stop. Instead of turning the CACC system completely off the
user decides to hit cancel so they can resume with their previous settings after making the
stop.
Figure 4.7: Cancel Sequence Diagram
22
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)
Figure 4.8 displays the “resume” scenario. A user is returning from a quick break at a
rest stop while driving down the highway. After getting back up to speed the user decided
to resume their previous CACC state. The user pressed the resume button and their
settings from earlier are restored.
Figure 4.8: Resume Sequence Diagram
Figure 4.9 shows the “increase distance” scenario. A user is driving along the highway
with the CACC system engaged. The user is behind the lead vehicle. The lead vehicle is a
rather expensive vehicle and even though the user has full confidence that the system will
not fail, the user decides to increase their following distance.
23
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)
Figure 4.9: Increase Distance Sequence Diagram
Figure 4.10 depicts the “decrease distance” scenario. A user is behind the lead vehicle.
The user is coming home in rush hour traffic. They notice that vehicles keep cutting into
the space between their vehicle and the lead vehicle. The user decides to decrease their
following distance to keep this from happening.
Figure 4.10: Decrease Distance Sequence Diagram
24
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)
4.5 System State Diagrams
System state diagrams are used to show the various states that a system can take and how
the system can enter and exit from these states. The boxes represent the different states
the system can be in at any single time. The arrows represent the transition from one state
to another. The first diagram, Figure 4.11, explains the highest level view of the system
that starts and ends with the ignition off.
Figure 4.11: Vehicle system state diagram
The second diagram, Figure 4.12, explains the internal blocks when the system is on. It
also shows the different levels that the Cruise Control system can operate in.
Figure 4.12: CC system state diagram
The Third and Fourth diagrams, Figures 4.13 and 4.14 respectively, show the details of
the ‘ACC set’ state and ‘CACC on’ state from the second diagram.
25
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)
Figure 4.13: ACC system state diagram
Figure 4.15: CACC system state diagram
5 Prototype The prototype shows two views side by side. The first view is the view from the user’s position.
In this view, there are indicators that show if the user is in a platoon, if the user’s vehicle is the
lead vehicle in the platoon, and what the following distance is currently set to. It also displays
user controls for increasing or decreasing speed, turning the system on or off, and increasing or
decreasing the following distance. This system also has a button called engage that sends the
request for the user’s vehicle to join a platoon. The second view shows a bird’s eye view of the platoon as it drives down the highway. From
here the current state of the platoon can be seen based the buttons the user presses.
5.1 How to Run Prototype All that is needed to run the prototype is a modern Internet browser that can run HTML5 and has
JavaScript turned on. No system configurations or web plug-ins are needed.
26
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)
The prototype can be accessed at the follow link:
https://www.cse.msu.edu/~cse435/Projects/F2014/Groups/CACC/web/test_proto/protov3
.html
5.2 Sample Scenarios
Scenario 1: A user is driving down the highway without the CACC system turned on. The
user then turns the system on, sets the speed and follow distance, and then engages the
system. The user’s vehicle will now be in a platoon based on the leading vehicle.
Scenario 2: The lead vehicle exits the platoon and the user’s vehicle is now the platoon
leader. The user’s vehicle will continue at the same speed unless changed by the user.
Figure 5.1 shows the interface for the current prototype for Scenario 1.
Figure 5.1: Prototype Interface
Figure 5.2 shows the interface for the current prototype for Scenario 2.
Figure 5.2: Prototype Interface
27
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)
6 References
[1] BMW Technology Guide: Active Cruise Control." BMW Technology
Guide: Active Cruise Control. N.p., n.d. Tues. 14 Oct. 2014.
http://www.bmw.com/com/en/insights/technology/technology_guide/articles/activ
e_cruise_control.html
[2] Jones, Stephen. Cooperative Adaptive Cruise Control: Human Factors
Analysis. No. FHWA-HRT-13-045. 2013.
http://www.fhwa.dot.gov/publications/research/safety/13045/13045.pdf
[3] M. Austin. (2013). Toyota's Semi-Autonomous Cars Hit the Highway
[online]. http://www.popularmechanics.com/cars/news/industry/toyotas-semi-
autonomous-cars-hit-the-real-road-16024804
[4] Shladover, Lu, Nowakowski.(2015) Using Cooperative Adaptive Cruise
Control to From High-Performance Vehicle Streams
http://www.automatedvehiclessymposium.org/callforposters/using-cooperative-
adaptive
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.