s oft w a re r e qui re m e nt s s pe c i fi c a t i on

1

Software Requirements Specification Cooperative Adaptive Cruise Control (CACC) 1

Authors: Matthew Lane, Jake Baum, Nick Jones, Andrew Kim, Shawn Peerenboom

Customer: Mr. Bill Milam

Instructor: Prof. Betty H.C. Cheng

1 Introduction This document is intended to provide functional and non-functional requirements pertaining to the development of software for Ford’s Cooperative Adaptive Cruise Control++ (CACC++) system. The following subsections will contain detailed information regarding the purpose of this document, various scopes of work, commonly used acronyms, and the overall organizational structure of the documentation.

1.1 Purpose

The Software Requirements Specification is provided to function as a means to facilitate communication between users and software engineers. Depending on needs, readers can use this documentation as a guideline for development, reviewing project goals, or general reference. The document can also be utilized as a platform for continued revisions.

1.2 Scope

Software to be produced will control the Cooperative Adaptive Cruise Control through multiple system components. GPS, camera, radar, and speed sensors will be used to control and detect vehicle parameters such as the current speed of the vehicle. Radio communication is used to process and communicate data to and from the infrastructure and other platoon vehicles. The CACC++ system will allow for a platoon of vehicles to maintain a constant vehicle speed specified by the driver or relative position with other platoon vehicles. Changing lanes or other variables other than stated above will not be supported.

Cooperative Adaptive Cruise Control (CACC) 1 2

1.3 Definitions, Acronyms, and Abbreviations

CACC++: Cooperative Adaptive Cruise Control

SRS: Software Requirements Specification

SW: Software

GPS: Global Positioning System

Platoon: Unit consisting of multiple CACC++ equipped vehicles

CAN-Bus: Controller Area Network Bus

1.4 Organization

Section 1. Introduction - Introduction to SRS

1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations

Section 2. Overall Description - Description of CACC++ SW

2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics

2.4 Constraints 2.5 Assumptions and Dependencies

2.6 Apportioning of Requirements

Section 3. Specific Requirements - Enumerated list of requirements

Section 4. Modeling Requirements - Requirements specifications

Section 5. Prototype - System functionalities of prototype

5.1 How to Run Prototype 5.2 Sample Scenarios

Section 6. References - References used in document


2 Overall Description This section of the document contains a detailed description of the system. The description includes the context of the system, as well as the functionality and goals of the system. User characteristics, or expectations about the user, are included. Constraints, assumptions, dependencies, and apportioning of requirements are also listed below.

2.1 Product Perspective

The Cooperative Adaptive Cruise Control (CACC) system is meant to meet a number of requirements. First, the CACC allows the vehicle cruise control system to adjust cruising speed in order to match the flow of traffic more safely and effectively. Second, any group of two or more CACC equipped vehicles can group up, or “platoon.” The equipped vehicles form a relatively compact line of vehicles which share data on traffic conditions up and down the platoon. CACC-equipped vehicles would be able to navigate through traffic and reduce congestion, all while increasing the safety of driving.

Constraints:

- Speed and safety of communication - Hardware limitations (CPU, memory, storage, etc.) - Connectivity to other vehicles - Sensor limitations

2.2 Product Functions

The Cooperative Adaptive Cruise Control (CACC) system will maintain a constant vehicle speed, which is specified by the driver. Also, the system will use forward radar and camera sensors to detect other vehicles and adjust its own speed, with necessary braking or throttle, to maintain a safe following distance. In addition, the vehicle will receive and transmit GPS information from vehicles ahead of and behind it respectively. This information gathered from other vehicles GPS systems, along with data from its own sensors, can be used to create a platoon that can follow a single, lead vehicle. Using this information, a safe spacing between each vehicle can be maintained.

To supplement GPS information, platoons will also share performance envelopes, a description of a specific vehicles braking and acceleration capabilities, with each other. These performance envelopes help ensure that the platoon can stay together through the coordination of available


braking and acceleration metrics. In addition to these main features, lane keeping, curve speed assist, and hill management will be incorporated.

The above diagram showcases the functionality of the CACC system. The driver may engage the CACC system, which allows for a set speed and follow distance. The driver can then disengage the system temporarily and resume the system, or turn the system off. While the CACC system is on, any manual input by the driver, such as braking or accelerating, will disengage the system and allow the driver to immediately take control of the system. While operating, the car will obtain various data from its sensors, such as finding obstacles, identifying members of its platoon and obtaining GPS information. All of this information can be used to measure speed and distance, as well as check speed of the various vehicles and obstacles that one may encounter while driving. While CACC is engaged, the vehicle will communicate with other CACC-enabled vehicles various information, including GPS and performance envelope. All of this gathered information will allow the system to properly adjust speed to perform its functionality.


2.3 User Characteristics

The user for our system is expected to be an everyday driver. They shouldn’t need any additional experience or an above-average skill level. The system will be doing all the work, however the driver must stay alert and focused in case there are any warnings or errors. In the case of an error, the driver must be ready to resume control of the vehicle.

2.4 Constraints

Safety-Critical:

1. The entire system is constrained by communication between vehicles. Communication must be fast and reliable to allow the system to quickly process the information required to make the necessary actions in time. 1.1. To further complicate this, encryption is also necessary to make sure the

information being obtained is from a recognized and trusted source. Encrypting and decrypting information takes time and will put a strain on processing times.

Hardware:

2. The CACC system must be able to run on a vehicle, which is constrained by the hardware limitations of a car. This includes processing power, available memory, and storage.

3. Connectivity to other vehicles and infrastructure may be spotty. 4. Sensors are inherently flawed. Debris and weather can cause false readings and provide

an unsafe environment.

2.5 Assumptions and Dependencies

This project makes some assumptions about the hardware, software, environment, and user interactions regarding the CACC system. These assumptions include:

1. The hardware uses a CAN-Bus for communication. 2. The system does not operate under adverse conditions that impede normal operations.

2.1. If the sensors are unable to function normally, the system will not operate. 2.2. For example, this includes bad weather or other conditions / obstructions that

block sensors. 3. If for any reason the system determines that it would be unable to operate safely and

correctly, it will not activate. 4. The user (the driver) has the ability to turn the system on and off. 5. The user can manually override the system at any time.


2.6 Apportioning of Requirements

There are no requirements that have been identified that are beyond the scope of this project.

3 Specific Requirements General Requirements:

1. The system shall be able to maintain a constant forward vehicle speed while keeping relative distance with other vehicles in front. 1.1. Does not affect the overall motor functions of the car. The system acts on the

same acceleration and braking systems the driver could act on. The system may be temporarily disengaged if the driver takes control of the vehicle.

1.2. The system communicates with vehicles in front of it and the ones behind it to more effectively achieve this goal.

1.3. If available, the CACC system may also send and receive data to and from road infrastructures.

2. Ability to accurately measure the distance between vehicles through a variety of sensors. 3. The car decelerates or brakes when the relative distance to the car ahead of it becomes

less than the set minimum following distance. 4. Accelerates to match surrounding traffic and other CACC vehicles while active. 5. Share vehicle braking and acceleration capabilities with other CACC equipped vehicles.

5.1. Information about the car’s performance envelope will also be shared with all other members of the platoon.

5.2. Coordination of braking and acceleration maneuvers of the platoon by using information from performance envelopes.

6. The system will allow its driver to adjust the target speed without turning the system off. 7. Analyze the surroundings of the road (empty lanes, shoulders) so vehicle “outs” are

available if an emergency stop were to happen. 8. Ability to adjust to changing and varied weather conditions

Hardware Requirements:

9. Radar and camera sensors must be able to detect, identify, and target vehicles. 9.1. The system requires maximal coverage of video and radar sensors. 9.2. If the radar were to fail, the cameras will act as backup for tracking obstacles.

10. GPS system needs to keep vehicle position, speed and direction information accurate


10.1. GPS information shared by surrounding vehicles will be used to help differentiate between other cars and static objects.

11. State guards detect failure to start key tasks and notifies the driver of failure to do so. 12. Ability to diagnose lack of memory and decide how to recover. 13. Ability to restart the subsystems if commanded by the vehicle controller 14. If the radar and cameras are dirty, obstructed, or otherwise inoperable, the system will not

operate.

Security Specific Requirements:

15. The CACC system in general should be kept as isolated as possible from unrelated vehicle systems.

16. The Sensors of the CACC system must be parameterized to avoid being compromised by malicious actions.

16.1. The Radar and GPS systems will not accept readings outside the bounds of normal operation.

17. The Radio of the CACC system must be protected with extra precaution from accepting non-parameterized data.

17.1. The CACC system must recognize when it is compromised and shut down the radio in order to prevent its misuse.

17.2. The Radio must ignore long term connection attempts that in large quantities would deny Radio service to legitimate actors.

18. It must be recognized that the CACC system will be the target of malicious attacks from a variety of actors, including these common actors:

18.1. Ransomware attackers trying to threaten CACC users for monetary gains. 18.2. Cyber-Terrorist attacks attempting to exploit the inherently dangerous and

interconnected nature of the system. 18.3. Foreign and domestic governments and organizations: Any group looking to do

substantial economic damage or a regional or even national scale could do so by compromising this system.


4 Modeling Requirements

Use Case Diagram:

Use Case Descriptions:

Use Case: Engage System Actors: Driver (initiator) Description: The driver chooses to turn on the CACC system. When turning on the system, the driver must set a speed and a following distance to maintain while active. While active, the system may be automatically disengaged if either set values result in an unsafe situation. While the system is active, the vehicle will also attempt to communicate with other vehicles that CACC is currently active. Type: Primary and essential


Includes: Set Speed, Set Follow Distance, Disengage System, Communicate that CACC is Active Cross-refs: Requirements 1 Use cases: Set Speed, Set Follow Distance, Disengage System, Communicate that CACC is Active Use Case: Set Speed Actors: Driver (initiator) Description: The driver may set a speed for the system to maintain. While a speed is set and the system is active, the system will adjust the speed of the vehicle through a throttle control to match the set value. Type: Primary and essential Includes: Adjust Speed Cross-refs: Requirements 6 Use cases: Adjust Speed Use Case: Disengage System Actors: Driver or System (initiators) Description: The driver or system may disengage the system, requiring the driver to assume manual control of the vehicle. The system is then put in standby and waits for the user to resume the system. Type: Primary and essential Includes: N/A Cross-refs: Requirements 1.1, 13 Use cases: N/A Use Case: Resume System Actors: Driver (initiator) Description: The driver may resume the system when it is disengaged. This will act as if the user engaged the system with the previously set values for speed and following distance. Type: Primary and essential Includes: N/A Cross-refs: Requirements 13 Use cases: N/A Use Case: Turn System Off Actors: Driver (initiator) Description: The driver can turn off the CACC system requiring manual control of the vehicle. Type: Primary and essential


Includes: N/A Cross-refs: Requirements 13 Use cases: N/A Use Case: Set Follow Distance Actors: Driver or System (initiators) Description: The driver or system can set the minimum following distance. While the system is engaged, the car will attempt to maintain the follow distance while behind a vehicle. Type: Primary and essential Includes: N/A Cross-refs: Requirements 1 Use cases: N/A Use Case: Communicate that CACC is Active Actors: Other Cars (initiator) Description: While the CACC system is engaged, the car will communicate with other CACC-enabled vehicles through the system. The vehicle will also display to non-CACC-enabled vehicles that CACC is engaged as well. Type: Primary and essential Includes: Communicate Information Cross-refs: Requirements 1.2 Use cases: Communicate Information Use Case: Communicate Information Actors: Other Cars or Infrastructure (initiators) Description: While the system is engaged, the vehicle will communicate information to other vehicles. Information included in transmissions will be the vehicles speed and GPS information. Type: Primary and essential Includes: Get GPS Information, Check Speed Cross-refs: Requirements 1.3, 5, 5.1, 5.2, 10.1, 11 Use cases: Get GPS Information, Check Speed Use Case: Get GPS Information Actors: Car (initiator) Description: While the system is engaged, GPS information of all vehicles, current and surrounding, will be obtained. Type: Primary and essential Includes: N/A


Cross-refs: Requirements 10, 10.1 Use cases: N/A Use Case: Check Speed Actors: Car (initiator) Description: While the system is engaged, the speed of the vehicle and the surrounding vehicles will be obtained. Type: Primary and essential Includes: N/A Cross-refs: Requirements 10 Use cases: N/A Use Case: Measure Speed Actors: Car (initiator) Description: The sensors of the vehicle will be continuously monitoring the speed of the vehicle and surrounding vehicles. Type: Primary and essential Includes: N/A Cross-refs: Requirements 10 Use cases: N/A Use Case: Measure Distance Actors: Car (initiator) Description: The sensors of the vehicle will be continuously monitoring the distance between the vehicle and various objects in its environment. Type: Primary and essential Includes: N/A Cross-refs: Requirements 2 Use cases: N/A Use Case: Adjust Speed Actors: System, Car or Driver (initiators) Description: The system or sensors can alert the vehicle to adjust speed. While adjusting speed, the system uses a throttle control system to either brake or accelerate, depending on the circumstance. Type: Primary and essential Includes: Use Throttle Control Cross-refs: Requirements 1, 3, 4 Use cases: N/A


Use Case: Identify Platoon Actors: Car (initiator) Description: Sensors will continuously identify surrounding vehicles in the platoon, along with their speed and distance. Based on gathered information, the system may choose to adjust speed. Type: Secondary and essential Includes: Measure Speed, Measure Distance, Adjust Speed Cross-refs: Requirements 1.2, 10.1 Use cases: Measure Speed, Measure Distance, Adjust Speed Use Case: Find Obstacles Actors: Car (initiator) Description: Sensors will continuously identify surrounding obstacles, including other vehicles. Based on gathered information, the system may choose to adjust speed. Type: Secondary and essential Includes: Adjust Speed Cross-refs: Requirements 7 Use Cases: Adjust Speed Use Case: Sensors Actors: Car (initiator) Description: The car will be equipped with various sensors to identify the environment around the car and variables such as speed, distance and GPS coordinates of those objects. Type: Primary and essential Includes: Get GPS Information, Check Speed, Measure Speed, Identify Platoon, Measure Distance, Find Obstacles Cross-refs: Requirements 2, 8, 9, 9.1, 9.2, 14 Use Cases: Get GPS Information, Check Speed, Measure Speed, Identify Platoon, Measure Distance, Find Obstacles


High Level Model (Domain Model):

Data Dictionary for Domain Model:

Element Name Description Accelerator This system encompasses all the “Drive

by Wire” aspects that the vehicle and operator adjust to control acceleration of the vehicle

Attributes N/A N/A Operations adjustAcceleration(amount :

float) Adjusts the vehicle’s acceleration by a specified amount.


Relationships Controlled by Vehicle Speed Controller UML Extensions

None.

Element Name Description Automated Cruise Controller Uses data from local sensors along with

data from other platoon vehicles to calculate how to adjust the vehicle to match the driver’s set cruise control or to match the platoon’s speed.

Attributes Unprocessed Data : Data Contains all the information gathered

from sensors and other vehicles, which will be used in the systems calculations to determine vehicle action.

Processed Data : Data All the information produced as a product of calculating how to maintain speed. Processed data is used by other vehicles in the platoon for their calculations.

objectInPath : bool Represents whether the system has detected any obstacles in its intended path.

Operations correctSpeed(amount : float) Allows the Automated System to adjust

vehicle speed through the Vehicle Speed Controller until the specified amount is reached.

dataProcessed(data : Data) Checks to see if data has been correctly processed.

disengage() Allows the driver to stop the CACC system from performing services.

engage() Allows the driver to activate the services of the CACC systems.

inputProcessed(data : Data) Signals that the input data has been processed.

monitorDistance() Checks the current distance between the current vehicle and obstacles detected around it.

monitorSpeed() Checks the current speed of the vehicle.


shutdown() Completely disables the Automated Cruise Control.

sendStatus() Allows the system to transmit the status of the current vehicle to its corresponding Platoon Vehicle members.

Relationships Interprets information received from radio and sends Processed Data to the radio. Controls & monitors Vehicle Speed Controller. Monitored by Vehicle Speed Manager. Controls Warning Systems. Monitored by Memory Manager. Alerted by Sensor Manager. Receives Data from GPS, Radar, and Video Sensors. Has activity set by Driver

UML Extensions

None.

Element Name Description Brake This system encompasses all the “Drive

by Wire” aspects the vehicle and operator adjust to control braking of the Vehicle

Attributes N/A N/A Operations engageBrake(amount : float) Sets the vehicle braking system at the

desired amount. Relationships Controlled by Vehicle Speed Controller UML Extensions

None.

Element Name Description Camera Allows the current Vehicle to use

cameras to detect obstacles and judge their relative distance.

Attributes System Status The current state of the Camera. It can

be functional, obscured, or not responding.

Video Data Video footage frames gathered by the Camera when it is active.

Operations


gatherData() Inherited from the Vehicle Sensor class. Allows the Camera to get and prepare data.

sendData() Inherited from the Vehicle Sensor class. Sends data collected by the Camera to the Automated Cruise Controller.

Relationships Sends data to Automate Cruise Controller. Monitored by Sensor Manager. Inherits from the base Vehicle Sensor class.

UML Extensions

None.

Element Name Description Driver The person operating the vehicle; they

are able to control the high level operations of the system.

Attributes N/A N/A Operations desiredSpeed(amount : float) Set the Expected Speed of the

Automated Cruise Control should maintain to the specified amount.

engageCACC() Allows the driver to activate the whole of the CACC system.

disengageCACC() Allows the driver to deactivate the whole of the CACC system.

Relationships Controls the Vehicle Speed Controller. Sets activity of the Automated Cruise Control. Controls the Sensor Manager.

UML Extensions

None.

Element Name Description GPS This system encompasses all the aspects

of receiving GPS data. Attributes Sensor Status Current State of the GPS. It can be

functional or unresponsive. GPS Current GPS data for the vehicle.

Includes, but is not limited to, global position data.


Operations gatherData() Inherited from the base Vehicle Sensor

class. Allows the GPS system to collect a set of GPS position data.

sendData() Inherited from the base Vehicle Sensor class. Allows the GPS to send the data it has gathered to the Automated Cruise Controller.

Relationships Inherits from Vehicle Sensor. Sends Data to Automated Vehicle Controller. Is monitored by Vehicle Sensor Manager.

UML Extensions

None.

Element Name Description Infrastructure Represents all imbedded road sensors

and equipment capable of interacting with the CACC system.

Attributes Infrastructure Data : Data Any data that this system may send to

connected CACC equipped vehicles. Operations sendData(data : Data) Allows Infrastructure to send data it has

collected to connected Vehicles. sendStatus(status : Data) Informs the current vehicle of the

overall Infrastructure status. Relationships Zero or more instances of Infrastructure may send data to a CACC

system Raio. UML Extensions

None.

Element Name Description Memory Manager Monitors memory resources for the

system, freeing memory as needed to keep the system functioning properly.

Attributes Available Memory : int Amount of memory resources not

allocated for use by the Automated Cruise Controller


Used Memory ; int Amount of memory allocated by the Automated Cruise Controller

Operations freeMemory(amount : int) Allows the memory manager to

reallocate the specified amount of memory for the CACC system

Relationships Monitors the Automated Cruise Controller. UML Extensions

None.

Element Name Description Platoon Vehicles Other Vehicles connected to the same

platoon as the current vehicle. Attributes Vehicle Data : Data Data collected by another Vehicle in the

platoon Operations sendData (data : Data) Allows the Platoon Vehicle to send

specific data to the current vehicle. sendStatus(status : Data) Informs the current vehicle of the

overall status of the Platoon Vehicle. Relationships Sends and receives data from the current vehicle’s Radio. UML Extensions

None.

Element Name Description Radar Allows the current Vehicle to use radar

to detect obstacles and calculate their relative distance.

Attributes Radar Data : Data Radar data collected by the Radar

system. Operations gatherData() Inherited from the base Vehicle Sensor

class. Allows the Radar system to collect a set of Radar obstacle data.

sendData() Inherited from the base Vehicle Sensor class. Allows Radar to send the data is


has gathered to the Automated Cruise Controller.

Relationships Inherits from Vehicle Sensor. Sends Data to Automated Vehicle Controller. Is monitored by Vehicle Sensor Manager.

UML Extensions

None.

Element Name Description Radio Facilitates communication between the

current Vehicle, other Vehicles in the platoon, and road Infrastructure.

Attributes Platoon Data : Data Relevant data to be transmitted to

platoon members Road Data : Data Relevant data to be transmitted to road

Infrastructure. Operations requestData(data : Data) Allows the current vehicle to make a

request for a specific set of data. sendData(data : Data) Allows the current vehicle to send the

specified data to other members of the platoon and Infrastructure.

Relationships Interprets data for the Automated Cruise Controller and sends data from the Automated Cruise Controller. Communicates with Platoon Vehicles and Infrastructure.

UML Extensions

None.

Element Name Description Sensor Manager Monitor and maintain the working status

of vehicle sensors relevant to the CACC system

Attributes Operations checkStatus() Checks if the sensors it monitors have a

satisfactory status sendStatus() Alerts the Automated Cruise Controller

if any Vehicle Sensors have reported a poor status


Relationships Monitors Radar, GPS, and Camera. Alerts Automated Cruise Controller. Controlled by Driver.

UML Extensions

None.

Element Name Description Vehicle Sensor Base Class for every type of Vehicle

Sensor on the current Vehicle Attributes Sensor Status : data Lists whether each component of a

sensor system is operable Operations gatherData() Creates a set of sensor data sendData() Sends the current Data set to the

Automated Vehicle Controller. Relationships Radar, GPS, and Camera inherit from Vehicle Sensor. UML Extensions

None.

Element Name Description Vehicle Speed Controller Represents the system which

collectively controls the speed of the current Vehicle.

Attributes currentSpeed : float Current speed of the current vehicle. automatedCruiseSpeed : float The speed the Automated Cruise

Controller Speed is attempting to reach. desiredSpeed : float The eventual speed to reach when not

constrained by a platoon. Set by driver. currentDistance : float Current distance of current vehicle with

nearest obstacle desiredDistance : float The eventual distance to reach is respect

to other platoon vehicles and obstacles. Operations adjustAcceleration(amount

:float) Adjusts the vehicle’s Accelerator to the specified amount.

correctSpeed(amount : float) engageBrakes(amount : float) Adjusts the vehicle’s brake to the

specified amount.


newDriverSpeed(amount : float)

Updates the vehicle’s Expected Speed.

newTargetSpeed(amount: float)

Updates the speed desired by the Automated Vehicle Controller.

resume() Allows the system to resume control of the Vehicle’s cruising speed.

compareSpeed(amount: float) Calculates difference between the Current speed and Desired speed.

compareDistance(amount: float)

Calculates difference between the Current Distance and Desired Distance

Relationships Adjusts Accelerator and Brakes. Controlled by Driver and Automated Cruise Controller. Monitored by Vehicle Speed Manager.

UML Extensions

None.

Element Name Description Vehicle Speed Manager Checks that the Vehicle Speed

Controller and the Automated Cruise Controller are working as intended

Attributes discrepancyDetected : bool True if a substantial difference between

Value Speed Controller values and Automated Cruise Controller is detected.

Current Speed : float Current speed of Current Vehicle Operations monitorSpeed() Checks the various speed attributes of

the Automated Cruise Controller and the Vehicle Speed Controller.

correctSpeed(amount : float) Applies a correction to the attributes of the systems monitored by the Vehicle Speed Manager.

getACCSpeed() Returns the speed set by the ACC to the Vehicle Speed Manager.

getTrueSpeed() Returns the actual current speed of the vehicle to the Vehicle Speed Manager.

automaticControl() Engages the CACC system when called.

manualControl() Disengages the CACC system when called.


Relationships Monitors the Vehicle Speed Controller and the Vehicle Speed Manager UML Extensions

None.

Element Name Description Warning System Encompasses the systems used to warn

the vehicle Driver of danger or to notify them of potential hazards.

Attributes N/A N/A Operations engageLights() Enables the warning lights used to warn

the Driver.

disengageLights() Disables the waning lights used to warn the Driver.

playAudio() Triggers the vehicle warning audio track to play to notify the Driver.

warnDriver() Controls and runs the sequence of audio/visual cues used to warn the Driver of a perceived danger.

notifyDriver() Controls and runs the sequence of audio/visual cues used to notify the Driver of non-emergency situations.

newWarning(type : Warning) Add a new warning to the list of warning notifications to send.

newNotification(type : Notification)

Add a new note to the list of non-emergency notifications to send.

processWarning(type : Warning)

Controls the sequence of steps performed to notify the Driver of the warning of the specific type.

processNotification(type : Notification)

Controls the sequence of steps performed to notify the Driver of the notification of the specific type.

resetWarnings() Resets the warning system and cancels any pending warnings.

resetNotifications() Resets the warning system and cancels any pending notifications.

clearWarnings() Removes all warnings from the Warning System.

clearNotifications() Removes all notifications from the Warning System.


Relationships Controlled by Automated Cruise Controller. Sends alerts to Driver. UML Extensions

None.

Representative Scenarios:

● The Memory Manager system is designed to deal with memory management. ● When the Automated Cruise Controller notices that there is a memory issue, such as

when a task fails to start due to insufficient memory, it sets a flag that alerts the Memory Manager to the issue.

● A process in the Memory Manager then occurs when the issue flag is set that diagnoses the issue and makes the decision on how to recover.

○ The Memory Manager has the ability to decide what tasks are essential to the system and which tasks or objects can be destroyed to clear up memory for upcoming tasks, and performs garbage collection on the objects in memory.

○ The Memory Manager also has the ability to make the recovery decision.

● If a subsystem has an unresponsive status, the Automated Cruise Controller can restart

the subsystem. ● If the subsystem being restarted is critical to safe operation of the system, or if the entire

system is restarting, the car will return to the control of the driver.


○ The Automated Cruise Controller will utilize the Warning System to alert the driver before it relinquishes control.

● Following any restart, a check will be performed to make sure that all of the subsystems have a positive (operational and ready) status.

● If the system status is positive and ready to be active, the Automated Cruise Controller will resume control of the car and notify the driver.

● The Vehicle Speed Manager system monitors the speed inputs when the system has

control of the vehicle. ● If a discrepancy is detected between the cruise speed and the desired speed based on

monitoring, a correcting value is applied to return acceleration to acceptable levels.

● The system communicates through the lead vehicle to the vehicles behind alerting them

of the issue. ● Based on the information sent from the lead vehicle, an alert is sent to the driver

notifying them of the emergency stop. ● The vehicles in the platoon will apply braking as needed based on the situation and the

performance envelopes of the vehicles in the platoon. ● If the system detects that there is an opening to adjacent empty lanes, it will send a

message to the driver telling them to move to that lane. ● As our system is based on adaptive cruise control and doesn’t normally control steering,

the system will not automatically divert members of the platoon to open spaces. ● All alerts and messages are sent through the Warning System.


● The CACC system relies on the data provided by both the camera and the radar systems

in order to make judgements on what are and are not potential targets. ○ If the radar system detects a potential obstacle in the operational space of the

camera systems, then camera data will provide visual verification. ● The CACC system also has the option of querying the overall data provided by the

platoon to help identify targets. ● Communication with the infrastructure and GPS data are used to help identify corners in

the road which is used to help determine if another vehicle or object is in the path of the vehicle.

● The system will base the decisions for adjusting the speed on the worst performing

vehicle in the platoon, and it will give appropriate power to each respective vehicle to maintain a tight platoon.

Sequence Diagrams:

Use Cases: Engage System The Driver can request the Automated Cruise Controller to engage the system. The Controller will then communicate with the Warning System which display the Engagement lights to notify the Driver of successful engagement.


Use Case: Set Speed Speed can be set by sending the Desired Speed to the Automated Cruise Controller. The Controller will then attempt a speed check with the Vehicle Speed Manager which will then receive Current Speed from the Vehicle Speed Controller. If the Current Speed is faster than the Desired Speed, the system will apply the brakes. If the Current Speed is slower than the Desired Speed, the system will Accelerate.


Use Case: Disengage System The system can be disengaged by sending a request to the Automated Cruise Controller. Once disengaged, the Warning System will receive input which will then confirm and display disengagement with the Driver/System.

Use Case: Resume System Resume system is similar to that of Engage. The differentiating factor is if the ACC verifies that the status is disengaged and not off, it will resume. Once resumed, the Warning System will receive input and notify and display confirmation with the Driver.


Use Case: Turn System Off The system can be turned off through the Automated Cruise Controller. If successfully shut down, the Warning System will notify and display success to the Driver.

Use Case: Use Brakes Brakes will be used when the Vehicle Speed Monitor receives input of the Desired Speed. If the Desired Speed is faster than the Current Speed, the Vehicle Speed Controller with engage brakes.


Use Case: Use Accelerator Brakes will be used when the Vehicle Speed Monitor receives input of the Desired Speed. If the Desired Speed is larger than the Current Speed, the Vehicle Speed Controller will adjust acceleration.

Use Case: Get GPS Information When the GPS coordinates are requested, the GPS system will send Position Data to the Sensor Manager.


Use Case: Set Follow Distance A set following distance can be set via the Automated Cruise Controller. The Sensor Manager will receive distance data from the Vehicle Sensors and compare with the set Desired Distance. If the Actual Distance between vehicles is larger than the Desired Distance, the brakes will be engaged. If the Actual Distance is less than the Desired Distance, the system will accelerate.

Use Case: Communicate that CACC is Active When another vehicle communicates with the CACC’s Radio, it can request the current status. The Automated Cruise Control will be sent a request for the current status. If active, the radio will send out a signal that the CACC is currently active.


Use Case: Communicate Information If a vehicle requests speed parameters to the CACC’s radio, current parameters will be requested to the Automated Cruise Control. These parameters will then be communicated with the Other Car or requesting Infrastructure.

Use Case: Measure Speed The vehicle’s speed relative to other vehicles will be analyzed by the Automated Cruise Control system. Once the Sensor Manager sends sensor data of other vehicles, the Vehicle Speed Manager will also be sent a request for the driving vehicle’s speed data.


Use Case: Measure Distance Automated Cruise Control will be in control of managing distance with other vehicles. The Sensor Manager will send location data to the Automated Cruise Control.


Use Case: Identify Platoon Automated Cruise Controller will identify and process data from Platoon Vehicles and the Infrastructure. ACC will request data to the Radio which will receive data from the Platoon and Infrastructure. This data will then be sent back to ACC. ACC will then request the status from the Radio which will again receive the information from Platoon and Infrastructure to send back to ACC.

State Diagrams: Vehicle Speed Controller

This state diagram models the states of the Vehicle Speed Controller class. The class starts in a state of Manual Control, where the driver alone is controlling the

speed of the vehicle. If a newTargetSpeed event occurs, the state changes to Speed Set. Or if a resume event occurs and the desiredSpeed variable is greater than 0, the state changes to Speed Set.

In this state, the desiredSpeed variable is set but the driver is still controlling the vehicle. If another newTargetSpeed event occurs the state does not change. When a newDriverSpeed


event occurs, if the value from the event is less than or equal to the minimum of the desiredSpeed and the automatedCruiseSpeed, the automaticControl action is called and the state changes to Maintain Speed. Otherwise the state does not change.

While inside the Maintain Speed state, the action adjustSpeed is run. In this state, a newTargetSpeed does not change the state. A newDriverSpeed event where the value from the event is greater than the minimum of the desiredSpeed and the automatedCruiseSpeed will change the state back to Speed Set and call a manualControl action.

In both the Speed Set and Maintain Speed states, any engageBrake event will change the state to Manual Control.

This is the state diagram for the Vehicle Speed Controller class. Vehicle Speed Manager

This state diagram models the states of the Vehicle Speed Manager class. The class starts in the Standby state. This state represents when the driver is controlling

the speed of the vehicle. When an automaticControl event is received, the state changes to Monitoring.

In the Monitoring state, the monitorSpeed action is run to evaluate the system’s input to the throttle controller. Detection of a discrepancy in the monitorSpeed evaluation raises a discrepancyDetected event. This event triggers the correctSpeed action, passing a corrected value with the action. A manualControl event will cause a transition back to the Standby state.


This is the state diagram for the Vehicle Speed Manager class. Automated Cruise Controller

This state diagram models the states of the Automated Cruise Controller class. The diagram represents that 3 parts of the class run in parallel to each other. The Speed Control part of the diagram represents the class’s control of the vehicle speed, the Sensor Data part of the diagram represents the collection and processing of data from the sensors, and the Communication part of the diagram represents communication using the radio system.

The Speed Control part of the diagram starts in the Initize System state. In this state the system is initializing the subsystems and getting ready for operation. When a systemReady event is received, the state changes to System Running.

In the SystemRunning state, the systems and subsystems are running but the driver has manual control of the vehicle. When an automaticControl event is received, the state transitions to the Modify Speed state.

When in the Modify Speed state, the system is in control of the vehicle. If a dataProcessed event is received, the action correctSpeed is called but the state does not change. This is where the processed data from the sensors is used to determine if the vehicle needs to change speed. Otherwise if a manualControl event is received, the state changes back to System Running.

The Sensor Data part of the diagram starts in the Setup Sensors state. This state is used while the sensors are starting up and initializing. When a sensorsReady event is received, the state moves to the Standby state.

The system is waiting for data from the sensors while in the Standby state. When a receiveInput event occurs, the state transitions to the Handle Input state.


While in the Handle Input state, the processInput action is called. An inputProcessed event occurs after the data has been processed. This event calls a dataProcessed actions and causes the state to return to Standby.

The Communication part of the diagram starts in the Setup Radio System state. This state is used while the radio subsystem is being setup and initialized. When a radioReady event is received, the state changes to the Radio Active state.

Two events can occur in the Radio Active state. The sendData event is received when there is data ready to be sent, and the state does not change. The dataReceived event occurs when the radio subsystem received data, and it causes a dataProcessed action to be called while the state remains the same.

This is the state diagram for the Automated Cruise Controller class. Warning System

This state diagram models the states of the Warning System class. The diagram represents that 2 parts of the class run in parallel to each other. The Warnings part of the diagram represents urgent messages and alerts for the driver, while the Notifications part of the diagram represents non-urgent information for the driver.

The Warnings part of the diagram starts in the No Warnings state. In this state, there are no warnings being displayed to the driver. If a newWarning event is received, a processWarning event is called and the state changes to Show Warning.

In the Show Warning state, the warnDriver action is used to show some form of warning to the driver. When a clearWarning event is received, the action resetWarnings is called and the state changes back to No Warnings.


The Notifications part of the diagram starts in the No Notifications state. When in this state there are no notifications being shown to the driver. If a newNotification event is received, a processNotification action is called and the state transitions to the Show Notification state.

When in the Show Notification state, the notifyDriver action is used to display some kind of non-urgent notification to the driver. If a clearNotification event is received, a resetNotifications action is called and the state returns to No Notifications.

This is the state diagram for the Warning System class.

5 Prototype This prototype highlights six different scenarios that have unique outcomes. Navigate through each scenario outlined in this prototype by using the dropdown option.

Our prototype is designed to show exactly how our system reacts to six sample scenarios. Based on the prototype, you should be able to see the process that our system goes through when coming upon a possible issue and how it adjusts by making a positive decision.

5.1 How to Run Prototype

The prototype is executable via our team website. You may navigate through our team website at: http://cse.msu.edu/~baumjaco/ to get to the prototype page or you can also go directly there by accessing this link: http://cse.msu.edu/~baumjaco/prototype.html.


When viewing a specific scenario, read through a summary of the scenario in the “Scenario Description” section and then you will be walked through how our system functions in the “Scenario Outcome” section. Within that section you will be able to watch a clip demonstrating the system in action during that certain scenario.

There are no plugin downloads required to run the prototype scenarios. The browser must be able to play embedded videos in order to watch the animations.

5.2 Sample Scenarios

This tutorial will walk through how to work with our scenario one prototype.

Click on the Prototype link the navigation bar that is found on the home page to redirect you to our prototype type page.


Now that you are at our prototype page, you are now able to read our prototype description and select any scenario that you want to run through.

Select Scenario One in the dropdown menu.


From here, you can view the Scenario Description as well as the Scenario Outcome.

Watch our video to see how the system functions when experiencing what is going on in scenario one.


6 References 1. Desjardins, Charles & Chaib-draa, Brahim. (2012). Cooperative Adaptive Cruise Control:

A Reinforcement Learning Approach. Intelligent Transportation Systems, IEEE https://www.researchgate.net/publication/224241951_Cooperative_Adaptive_Cruise_Control_A_Reinforcement_Learning_Approach.

2. Federal Highway Administration, U.S. Department of Transportation. “Cooperative Adaptive Cruise Control: Human Factors Analysis.” Fhwa.dot.gov, www.fhwa.dot.gov/publications/research/safety/13045/13045.pdf.

3. Shladover, Steven E., et al. “Cooperative Adaptive Cruise Control: Definitions and Operating Concepts - Steven E. Shladover, Christopher Nowakowski, Xiao-Yun Lu, Robert Ferlis, 2015.” SAGE Journals, https://journals.sagepub.com/doi/pdf/10.3141/2489-17.

4. Shladover, Steven E., et al. “Cooperative Adaptive Cruise Control: Definitions and Operating Concepts - Steven E. Shladover, Christopher Nowakowski, Xiao-Yun Lu, Robert Ferlis, 2015.” SAGE Journals, https://journals.sagepub.com/doi/pdf/10.3141/2489-17.

5. L. Xiao, M. Wang, W. Schakel, and B. van Arem, “Unravelling effects of cooperative adaptive cruise control deactivation on traffic flow characteristics at merging bottlenecks,” Transportation Research Part C: Emerging Technologies, 12-Oct-2018. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0968090X1830528X. [Accessed: 15-Nov-2019].

6. “Adaptive cruise control,” Bosch Mobility Solutions. [Online]. Available: https://www.bosch-mobility-solutions.com/en/products-and-services/passenger-cars-and-light-commercial-vehicles/driver-assistance-systems/adaptive-cruise-control/. [Accessed: 15-Nov-2019].

7. Learn About. [Online]. Available: https://my.gmc.com/how-to-support/driving-performance/driving/adaptive-cruise-control. [Accessed: 15-Nov-2019].

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 msu.edu). All materials in this document have

https://www.researchgate.net/publication/224241951_Cooperative_Adaptive_Cruise_Control_A_Reinforcement_Learning_Approach

https://www.researchgate.net/publication/224241951_Cooperative_Adaptive_Cruise_Control_A_Reinforcement_Learning_Approach

http://www.fhwa.dot.gov/publications/research/safety/13045/13045.pdf

https://journals.sagepub.com/doi/pdf/10.3141/2489-17


been sanitized for proprietary data. The students and the instructor gratefully acknowledge the participation of our industrial collaborators.

s oft w a re r e qui re m e nt s s pe c i fi c a t i on

Documents