Software Requirements Specification (SRS)

Project Cooperative Adaptive Cruise Control++ (CACC) 2

Authors: Brendan Carpio, Jacob DeNell, Colin Heinemann, Joseph Stafford, Yuheng Zhang

Customer: Mr. William Milam, Ford Motor Company

Instructor: Dr. Betty Cheng

1 Introduction The Software Requirements Specification (SRS) document will outline every

requirement of the Cooperative Adaptive Cruise Control System (CACC) in 7 sections. Section 1 will describe the CACC system as a whole and all of its objectives. It will also cover any major terms that need to be reviewed to help understand the CACC system. Section 2 will cover the context of the system and go into further detail on how the system should behave in certain situations and specify what assumptions need to be made for the system to accomplish the desired functionality. Section 3 will go over every requirement of the system and show how it should behave in all situations. Section 4 is all of the modeling requirements of CACC. It will show diagrams of the system and how all of the classes interact with each other. Section 5 will give ample scenarios and step by step instructions on using our prototype. Section 6 is all references needed throughout the SRS document. Section 7 provides a further point of contact for our project, Professor Betty H.C. Cheng.

1.1 Purpose The purpose of the SRS document is to provide all requirements and

specifications to the team that will be working on the CACC system. The SRS will use diagrams and definitions about CACC to help everyone further understand every aspect of it. The intended audience is everyone that is involved in the process of building the system in any way.

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 msu.edu)t msu.edu)

1.2 Scope The system being produced will be called “Cooperative Adaptive Cruise Control”, abbreviated as CACC. CACC is an embedded system for automotive vehicles that automates cruise control in groups of vehicles called “platoons”. The goal of CACC is to make traveling on highways safer and more efficient by creating platoons of vehicles that all travel at the same speed at a close distance to each other. Each vehicle in a platoon will share GPS data with the other vehicles to allow every vehicle to know the correct speed to travel at. If any vehicle in the platoon slows down, all of the trailing vehicles will slow down and if any vehicle speeds up, all of the trailing vehicles will also speed up (to a certain point). CACC will automatically detect platoons and add vehicles to them. If a driver wants to leave the platoon at any time they can simply turn out of the lane that the platoon is using or hit the brakes on the vehicle.

1.3 Definitions, acronyms, and abbreviations ● CACC: Cooperative Adaptive Cruise Control. ● CACC vehicle: Vehicle capable of running the CACC system and currently has it

engaged. It is able to take part in a platoon, but may or may not be actively in one. ● Platoon: A group of CACC-enabled vehicles sharing GPS data which are all

traveling at the same speed in close proximity to each other. ● Head vehicle: The vehicle at the front of a platoon. ● Lead vehicle: See “Head vehicle”. ● Tail vehicle: The vehicle at the back of a platoon.

1.4 Organization Section 2.1 - Product Perspective

● The overall context of CACC and all of its constraints. Section 2.2 - Product Functions

● The major functions that the software will perform. Section 2.3 - User characteristics

● Expectations about the user (e.g., background, skill level, general expertise). Section 2.4 - Constraints

● Definitions of the constraints of the system. ● Descriptions of safety-critical features. ● Descriptions of properties which if violated will cause the system to not work

properly. Section 2.5 - Assumptions and Dependencies

● Assumptions about the environment and user interactions. Section 2.6 - Approportioning of Requirements

● Requirements which are beyond the scope of this current version of the project which may be addressed in future versions/releases.

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 msu.edu)

Section 3 - Specific Requirements ● An enumerated list of the requirements of the system.

Section 4 - Modeling Requirements ● Specifies bridge between application domain and machine domain. ● Diagrams that show expected behavior of the system and their descriptions.

Section 5.1 - How To Run Prototype ● Instructions on how to properly use the prototype of the system.

Section 5.2 - Sample Scenarios ● Pictures and their descriptions of how CACC will react to certain scenarios.

Section 6 - References ● All referenced documents which were used in the SRS.

Section 7 - Point of Contact ● Provides a further point of contact for our project (Professor Betty H.C. Cheng).

2 Overall Description This section will describe how CACC will work. Section 2.1 will give an

overview of what CACC is and its applications. Section 2.2 will describe the functionality of the system and use a diagram to provide a hierarchical view. Section 2.3 will describe what users should expect when using this system. Section 2.4 will list constraints of the system as well as crucial properties of the system. Section 2.5 describes assumptions that team CACC-2 has made during development, and section 2.6 will address requirements that are not feasible at the given time.

2.1 Product Perspective

Cooperative Adaptive Cruise Control++ (CACC) is a complete system that will replace the cruise control functionality that already exists in vehicles. It is a standalone program that encompasses and implements all of its requirements.

CACC requires several hardware components to be installed on the vehicle. A radar, camera, GPS system and radio will provide information to the system. The Vehicle controller will be the logical processing unit that takes in the data from the aforementioned components and use it to direct the brake by wire and electronic throttle control systems. The latter two systems are in charge of manipulating the vehicles movement.

Drivers will communicate with CACC much in the same was as existing cruise control systems. A toggle button will activate and deactivate the system. The brake pedal will provide an additional method for deactivation. Finally, drivers can indicate their desire to leave a platoon without disengaging CACC by using the turning indicators.

The software will communicate internally to different components by adding wiring between all the components. Wireless communication will take place between CACC vehicles so they may share their states, speed, and location information.

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 msu.edu)

2.2 Product Functions CACC works as an adaptive cruise control system. The goal of the system is to

have a vehicle match the speed of the vehicle in front of it thus maximizing efficiency and safety. In order to do this, CACC forms vehicle platoons. Platoons are essentially groups of vehicles following each other in the same lane. With platoon logic, CACC is able to maximize speed at a safe distance by taking into account the acceleration and deceleration capability of the platoon as a whole.

With CACC enabled, vehicles will automatically create and join platoons with nearby vehicles also equipped with CACC. Like normal cruise control, the driver will be able to deactivate the system by braking. A turn signal will be used to leave a platoon in the current lane or to join a platoon in an adjacent lane. CACC software will handle various vehicles joining and leaving platoons and will calculate vehicle speeds accordingly.

The overall goals of the software are to provide convenience to the driver and to improve the safety of the vehicle by controlling the vehicle’s speed. A diagram is provided to show how this is broken down into the system’s functionality.

2.3 User Characteristics Users operating a CACC enabled vehicle must have knowledge in driving that

vehicle as well as basic knowledge in using CACC. Namely, drivers will need to know what controls to manipulate as well as the system’s behavior during joining and exiting a platoon.

Operating a vehicle with CACC will be very similar to operating a vehicle with standard cruise control where only speed adjustments are made. Since CACC will not steer the vehicle, the user will always be driving. CACC will control the speed and the driver must be prepared to brake at any point. The major difference between operating a CACC vehicle will be the turn signal functionality. The driver must be aware of how using the turn signal and changing lanes will affect CACC. If they leave a platoon by

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 msu.edu)

changing lanes, the driver must be prepared to use the gas pedal to accelerate or maintain speed. Also, the driver must be aware that they may join a platoon by changing lanes, which would automatically enact speed control.

2.4 Constraints ● All vehicle components such as brakes, throttle, and sensors are operational. ● Vehicles are properly networked together

2.5 Assumptions and Dependencies We’ve assumed that platoons are formed in a decentralized nature by having each

vehicle represent itself as well as all platooning vehicles behind it. If there are only two vehicles, the leading vehicle will send its action information (is it accelerating or decelerating) to the vehicle in the back. The vehicle in the back will calculate its appropriate actions based on its weight and performance capabilities. Conversely, the trailing vehicle will send information about its weight and performance forwards. Thus, the leading vehicle is aware of the capabilities of itself and followers. This allows the leading vehicle to adjust its actions so that it may begin braking earlier or have a greater trailing distance.

2.6 Approportioning of Requirements The premise of this project is to implement an advanced version of cruise control.

It should have similar ways of controlling it from the perspective of the driver, but it should take advantage of the platooning, the process of vehicles driving close together to reduce fuel costs. Thus, the driver still has to manage steering and keep the vehicle going in the right direction.

Further development in platooning vehicles would likely involve taking over steering control from the driver. However, this would be out of scope for the current project and increase the level of automation [1]. To implement those features, a new program should be designed with those requirements known from the beginning. Referring to CACC could be beneficial as it would provide guidance on implementation and provide requirements based on events experienced in the wild.

3 Specific Requirements 1. Vehicles must coordinate with each other to achieve and maintain a platoon. 2. Vehicles must be able to leave the platoon at any time. 3. If a vehicle leaves the platoon, the car immediately following it will take its place

or start second platoon.

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 msu.edu)

4. In the case of an emergency stop, vehicles in the platoon will communicate to ensure all cars can safely slow or stop.

5. Platoons should maintain a distance close enough to reduce the chance of being intersected by another vehicle.

6. Platoon will move in a way to ensure that non-CACC capable vehicles can safely navigate the freeway.

7. Vehicles in the platoon will communicate to coordinate accelerations and decelerations simultaneously, regardless of differences in sizes or class of vehicle.

8. In the event of a mechanical failure, the platoon will split in the location of the malfunctioning vehicle.

9. The platoon will attempt to not exert more than 2Gs of force on the driver. 10. Vehicles initiating CACC will attempt to find nearby platoons before starting a

new one. 11. CACC will negotiate with other automatic systems in the car to ensure the safety

of the driver and passengers. 12. Vehicles should be equally capable of performing leadership duties as a form of

redundant backup. 13. Platoons should be able to be comprised of vehicles of various brands and

companies without major changes of configuration, safety or overall experience. 14. Vehicles must have enough bandwidth to support continuous video streaming and

data exchange 15. The system and the data being exchanged must be designed in a way that it's

backwards compatible should new features be added. 16. Platoons should take advantage of high occupancy vehicle (HOV) lanes and other

infrastructure that would reduce their traffic and need to change speeds. 17. Platoon vehicles should put prioritize the safety of other vehicles. 18. Should take road conditions into account for stopping distance. 19. The system should take road conditions into account when performing

accelerations / decelerations to promote the safety of vehicles. 20. If a vehicle catches up the platoon it will join and slow to the platoon's speed. 21. If a vehicle’s system determines that a collision is imminent it and all following

vehicles in the platoon will brake up to a point where 2Gs of force is applied to each driver.

22. Vehicles will follow at a gap that CACC determines is far enough to provide safe operation, but close enough to provide drag reduction.

23. The CACC internal system must have adequate security, meaning that no one can easily hack into a computer and tamper with information.

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 msu.edu)

24. CACC should use economic driving under low fuel driving. For example, using electronic fuel when the vehicle is almost out of gas.

25. CACC will be prepared to operate with limited functionality if there is a loss of sensor/actuator

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 msu.edu)

4 Modeling Requirements

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 msu.edu)

Use Case Descriptions Use Case: Create Platoon

Actors: Driver

Description: When there is no platoon available to join in a 100 meter distance, when cruise

control is engaged the vehicle will create a new platoon with itself as the lead (primary) vehicle.

This will allow other nearby vehicles to join behind. As the lead vehicle, it will decide how fast

the platoon will travel.

Type: Primary

Includes: None

Extends: None

Cross-Refs: 1, 7, 10, 11, 12, 13, 17, 22, 25, 26

Use Cases: Turn On System, Activate Sensors

Use Case: Join Platoon

Actors: Driver

Description: Having found an already existing platoon of vehicles within 100 meters, the vehicle

will accelerate to catch up and join it.

Type: Primary

Includes: None

Extends: None

Cross-Refs: 1, 5, 7, 10, 11, 13, 16, 18, 20, 22

Use Cases: Turn On System, Activate Sensors

Use Case: Leave Platoon

Actors: Driver

Description: The vehicle will leave the platoon it is currently in by notifying other vehicles in the

platoon. Depending on the scenario, this may result in a vehicle following a new vehicle and

adjusting its speed to match. Finally, the vehicle will deactivate its sensors.

Type: Primary

Includes: Send Message

Extends: None

Cross-Refs: 1, 2, 3, 8

Use Cases: Turn Off System, Deactivate Sensors

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 msu.edu)

Use Case: Send Message

Actors: Driver, Leading Driver, Following Vehicle

Description: When the vehicle is in a platoon it must be continuously sending information to

other members of the platoon. Information should include vehicle ID, weight, speed, braking

ability, acceleration ability, and what actions are being performed (accelerating, braking).

Type: Secondary

Includes: None

Extends: None

Cross-Refs: 7, 14, 15

Use Cases: Leave Platoon

Use Case: Turn On System

Actors: Driver

Description: The system would turn on when the driver has pressed a toggle switch. Turning the

system on would activate the sensors and start a diagnostic test to ensure that all components

are working. Additionally, the system will begin searching for a platoon to join. If it cannot find a

platoon, it will create one for itself.

Type: Primary

Includes: Join Platoon, Create Platoon, Activate Sensors, Receive Message

Extends: None

Cross-Refs: None

Use Cases: Every use case besides Turn Off System, and Leave Platoon.

Use Case: Turn Off System

Actors: Driver

Description: The driver can turn the CACC system off by pressing on the brake pedal or pressing

the toggle button. Turning off the system will have the vehicle leave its platoon, and will disable

its sensors since they are no longer in use. The vehicle would now be a non-CACC vehicle and

will be treated as such by the system.

Type: Primary

Includes: Deactivate Sensors, Leave Platoon.

Extends: None

Cross-Refs: None

Use Cases: Leave Platoon, Deactivate Sensors.

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 msu.edu)

Use Case: Activate Sensors

Actors: Driver

Description: When the system is turned on, the sensors will be activated to detect obstacles

and other vehicles.

Type: Primary

Includes: Detect obstacle, Detect failure

Extends: None

Cross-Refs: 4, 6, 7, 9, 18, 19, 22, 23, 24

Use Cases: Detect Obstacle, Detect Failure

Use Case: Deactivate Sensors

Actors: Driver

Description: When the system turned off, the sensors will deactivate. The vehicle will no longer

be able to detect obstacles or other vehicles.

Type: Primary

Includes: None

Extends: None

Cross-Refs: 2, 10, 25

Use Cases: None

Use Case: Detect Obstacles

Actors: Driver

Description: When the radar turned on, the vehicle can detect obstacles that may cause

collisions. Additionally, the radar can detect the distance to another vehicle.

Type: Primary

Includes: None

Extends: None

Cross-Refs: 17, 21, 22, 25

Use Cases: None

Use Case: Adjust Speed

Actors: Driver

Description: The system will adjust the vehicle’s speed to follow the vehicle in front of it at a

safe distance. This change in speed will give adequate time for and vehicles behind to adjust and

will not irritate the driver by being too fast.

Type: Primary

Includes: None

Extends: None

Cross-Refs: 5, 6, 7, 9, 19, 21, 23

Use Cases: None

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 msu.edu)

Use Case: Receive Message

Actors: Driver

Description: The system will receive messages from other vehicles in the same platoon. These

messages should include vehicle ID, weight, speed, braking ability, acceleration ability, and what

actions are being performed (accelerating, braking).

Type: Primary

Includes: Adjust Speed

Extends: None

Cross-Refs: 1, 7, 14

Use Cases: Adjust Speed

Use Case: Detect Failure

Actors: Driver

Description: The system must be able to recognize when it is malfunctioning in order to act

accordingly. If there is a failure in sensors or actuators, CACC will detect the failure and disable

the system to allow the platoon to respond.

Type: Primary

Includes: Turn Off System

Extends: None

Cross-Refs: 4, 8, 26

Use Cases: Turn Off System

Use Case: Split Platoon

Actors: Driver

Description: This occurs if a non-CACC vehicle gets in between two platooning CACC vehicles,

there is an obstruction the slows a following CACC vehicle, or a Platooning vehicle in between

platooning vehicles leaves the platoon.The vehicle in front of the split will become the tail end of

the platoon in front. The vehicle behind the split will become the new leader of the platoon

created in the back. This new leader will set the speed of it’s platoon allowing it to match the

speed of a slow moving car that cut-in or completely stopping if there is an obstruction.

Type: Primary

Includes: Create Platoon, Leave Platoon

Extends: Detect Obstacle

Cross-Refs: 1, 2, 6, 7

Use Cases: Create Platoon, Leave Platoon, Detect Obstacle

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 msu.edu)

Domain Model

Element Name Description

BrakeByWire Braking system used to slow the vehicle.

Attributes Operations setDegree(x: Integer): void Sets the value of the degree to “x”.

Specifically, sets how much braking power is being applied

getDegree(): Integer Gets the value of the degree -- braking power -- being applied.

getType: String Returns the value of the Type. Relationships BrakeByWire will inherit attributes and operations from

ControlSurface UML Extensions

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 msu.edu)

Element Name Description

Cooperative Adaptive Cruise Control++ (CACC)

Root object of the diagram. Represents the whole system.

Attributes Operations Relationships CACC is made up of Platoon objects since the system as a whole

manages different platoons. UML Extensions

Element Name Description ControlSurface Abstract class for actuators that

control the vehicle’s movement such as Electronic Throttle Control and Brake by Wire

Attributes Degree: Integer

Determines if the Control surface is active and how much of the capability is being used. Integers represent range of 0% to 100%. 0% means the surface is off or not being applied. 100% means the surface is being applied to the fullest extent of its capability. Other values mean that the Control Surface is active to a but only outputting a fraction of the available performance.

Type: Enum[“Brake”, “Throttle”]

Used to identify what type of control surface this is so that it can be used appropriately. Brakes would be used to slow down the vehicle while throttles would speed up the vehicle.

Operations setDegree(x:Integer): Void Set the value of Degree to “x”. getDegree(): Integer Return the value of Degree. getType(): String Return the value of the Type. Relationships Inherited by BrakeByWire and ElectronicThrottleControl. Contains

functions that are called by VehicleController to coordinate child objects.

UML Extensions

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 msu.edu)

Element Name Description ElectronicThrottleControl Throttle system used to accelerate the

vehicle Attributes Operations setDegree(x: Integer): void Sets the value of the degree to “x”.

Specifically, sets how much throttle is being applied to propel the vehicle.

getDegree(): Integer Gets the value of the degree -- throttle -- being applied

getType: String Returns the value of the Type. Relationships ElectronicThrottleControl will inherit attributes and operations

from ControlSurface UML Extensions

Element Name Description ForwardLookingCamera Type of sensor that is able to visually

detect target vehicle, estimate distance, and relative speed.

Attributes Operations Enable(): void Activates the sensor so it generates

data based on light. Disable(): void Deactivates the sensor so it is no

longer generating data based on light. GetReading(): String Retrieves the reading from the sensor

describing vehicles it has identified, estimated distance from the object in front and an estimated speed.

Relationships ForwardLookingCamera will inherit attributes and operations from Sensor

UML Extensions

Element Name Description GPSSystem Type of sensor that is able to get

vehicle position, speed, and direction

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 msu.edu)

information. Aids in differentiating vehicle targets and distancing.

Attributes Operations Enable(): void Activates the sensor so it generates

data based on what satellites transmit Disable(): void Deactivates the sensor so it is no

longer generating data. GetReading(): String Retrieves the reading from the sensor

describing vehicle position, speed, and direction information.

Relationships GPSSystem will inherit attributes and operations from Sensor UML Extensions

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 msu.edu)

Element Name Description Message Data being sent between the platoon

vehicles to be used for adjusting speed.

Attributes Sender: VehicleController Which vehicle sent the message Recipient: VehicleController Which vehicle should receive the

message State: Enum[“accelerating”,

“deaccelerating”, “maintaining speed”]

What the current state of the sender is. Made to represent what actions are currently being taken by the ControlSurfaces

Location: Pair[Double] A pair of doubles made to represent Latitude and Longitude

Operations GetSender() Retrieves the sender of the message. GetRecipient() Retrieves who should be the recipient

of the message GetState() Retrieves the state of the sender from

the message GetLocation() Retrieves the location of the sender

from the message Relationships Messages will be created and managed by Radios on the vehicle. UML Extensions

Element Name Description Radio Component to transmit and receive

messages to and from other vehicles as well as infrastructure.

Attributes Operations SendMessage(): void Gets information from the Vehicle

controller and packages it into a Message packet then transmits it.

ReceiveMessage(): Message Receives a message Relationships Radio will create and retrieve messages so that they may be

processed by the VehicleController. UML Extensions

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 msu.edu)

Element Name Description Radar Type of sensor that is able to detect,

id, and track target vehicles Attributes Operations Enable(): void Activates the sensor so it generates

data based physical waves Disable(): void Deactivates the sensor so it is no

longer generating data based physical waves.

GetReading(): String Retrieves the reading from the sensor describing vehicles it has identified and tracks their relative position.

Relationships Radar will inherit attributes and operations from Sensor UML Extensions

Element Name Description Sensor Abstract class that provides a

common interface for all types of sensors used in this system.

Attributes Type: string The name of the sensor type, for

example “radar” Reading: String The current output of a sensor

depicting all the parameters that it could return.

Operations Enable(): void Activates the sensor so it may begin

generating data. Disable(): void Deactivates the sensor so it is no

longer generating data. GetReading(): String Retrieves the reading from the sensor Relationships ForwardLookingCamera, Radar, and GPSSystem all inherit from this

class. UML Extensions

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 msu.edu)

Element Name Description VehicleController Primary Module of the vehicle that

maintains overall information and coordinates the other components such as Sensors and Control Surfaces.

Attributes Speed: Int Speed of the vehicle in miles per hour Weight: Double Weight of the vehicle in tons Latitude: Double Latitude of the vehicle. This

information is updated by the GPS system

Longitude: Double Longitude of the vehicle. This information is updated by the GPS system.

Operations RunSystemTest(): Boolean Check all components to see if they

are working. Return false if any components aren’t working properly.

ObstacleFound(): Boolean Getting the data from the sensors, checking the distance from the obstacles inorder to adjust speed

AdjustSpeed(int speed): Void

Calculate the distance from the vehicle to the obstacles and get the result of how much speed should adjust

CreatePlatoon(int ID): Void Creates a platoon if one does not already exist

JoinPlatoon(int ID): Boolean Joins a platoon if one is available nearby

LeavePlatoon(): Void Leaves a platoon which the vehicle belongs to

Activate(): Void Turn on the vehicle’s CACC system Deactivate(): Void Turn off the vehicle’s CACC system Relationships VehicleController coordinates the Radio, ControlSurfaces, and

Sensors. It is the representation of the vehicle and is a part of the CACC system

UML Extensions

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 msu.edu)

Sequence Diagram Description

Scenario1: The driver is the actor that will initiate the sequence. The three messages that the driver will send are pressing buttons, pressing braking pedal and using the steering wheel. The button can toggle the system on and off, braking will halt the system entirely, and steering/signaling will leave the platoon. Scenario2: After the driver performs the action, the system needs to react appropriately. After getting the command from the driver, the system will send a message to the sensors to either activate or deactivate based on how the sensor relates to the CACC system. When the system turns on, the sensors activate and vice versa. Scenario3: When the sensors activate they will send two messages, which enable detection of both obstacles and failures. When the system turns off, the sensors should be deactivated which will, in turn, disable obstacle and failure detection. Scenario4: Detect Obstacles will use radar sensing and a forward-looking camera to do the distance measurement from the obstacles to the vehicles. It will send a message to adjust the speed when finding obstacles that require the vehicles to accelerate or decelerate. If detect obstacles gets a message from the sensors needing to disable, it will then reply to the sensors a message that the function is already disabled. Scenario5:

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 msu.edu)

Detect Failure checks that the GPS system, radio communication, radar sensing, and forward-looking camera are working normally. It will send a message back to the system when finding a failure and will shut down. After this, if detect failure gets a message from the sensors that it needs to disable, it will then reply that it already is disabled. Scenario6: If Detected Obstacles needs to change speed in order to avoid the obstacles, it will send a message to Speed Adjust and will adjust the speed accordingly. Scenario7: Join Platoon and Create Platoon capabilities turn on after the vehicle activates the CACC system. The vehicles then have the ability to use radio to connect with each other. If there is a platoon that already exists, the system will allow the vehicle to join the platoon. If there isn’t a platoon, the vehicle will create a platoon and be the leading car. Scenario8: If the CACC system turns off the vehicle should leave the platoon and send messages to notify other cars in the platoon. Scenario9: Leave Platoon, Join Platoon and Create Platoon will all lead to notifying all vehicles in the platoon. The notification will be sent to the following vehicle, and the following vehicle will continue to pass it back. Scenario10: Non-CACC vehicle driver is another actor that participates in the sequence. Non-CACC vehicle is able to cut inside the platoon, causing the platoon to split in half.

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 msu.edu)

Scenario11: When a Non-CACC vehicle cuts off a platoon, the following vehicle will use the detect obstacle functionality to split the platoon, creating a new platoon for the following vehicles.

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 msu.edu)

Sequence Diagram

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 msu.edu)

State Diagram Description Drivers will drive their vehicles onto the highway and get their vehicles up to speed, roughly that of traffic. From there they can decide if they want to keep driving or give control over to Cooperative Adaptive Cruise Control++ (CACC or the “system”). The system is initially turned off until the driver has pressed the toggle button. The driver may disengage the system at any time by pressing the toggle button again or pressing the brake pedal. Once the system is on, it begins by activating the sensors and running a diagnostic scan to ensure the system’s components are working and able to satisfy their duties reliably. Should the system decide that it cannot operate correctly it will shut itself down returning full control to the driver. When successful, the system will begin passively scanning the area around the vehicle looking for obstacles. During the time where CACC is engaged, sensors are constantly generating data and sending it to a processing unit. This unit will interpret sensor data and determine if changes to the vehicle's speed, braking amount, or throttle amount should be made. If no actions are required, it will simply go idle until it receives new data to process. Otherwise, actions to be taken will be sent to the throttle and brakes (Control Surfaces). CACC will by default set the control surfaces to maintain their speed. When the Control Surfaces receive a command to adjust their speed, they’ll adjust their degrees of activity. During acceleration, the brakes shouldn’t be active and thus will be set to a degree of 0%, but the throttle would be set to a degree that would give gentle acceleration. Once the vehicle at the desired speed, the logic processor will send another signal of the desired speed, so that control surfaces will hold their standing. Likewise, during deceleration the throttle would be set to 0% and the brake degree would be calculated to give gentle acceleration while still meeting the requirements of ensuring no collision. Communications between vehicles in a platoon will be initially gathered with the communications unit. Upon receiving a new message it will send that message to the logic processing unit which will decide what to do with the information. Additionally, the logic processing unit will send its decision back to the communications so that it can be sent out.

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 msu.edu)

State 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 msu.edu)

5 Prototype

The prototype displays an overhead view of a highway. On this model are various vehicles, shown as rectangles, which the system will interact with. The car we are following is the one colored red. A green car is one that is currently using CACC capabilities. When our red car activates CACC, it will be wrapped in a green rectangle. Blue cars are the ones that do not have CACC capabilities or are not currently using them. The buttons on the side correlate to possible actions that can be taken by the driver. When a button is clicked, the appropriate action will be taken on-screen by our vehicle and others around it.

5.1 How to Run Prototype The prototype is based on the canvas API that is supported in all modern

browsers as part of the HTML5 specification (IE 9+, Edge, Firefox 3.6+, Chrome 4+, Safari 4+, Opera 10+). It requires Javascript to be enabled on the web page and can be accessed from our team’s website. After the entire page has been loaded it should no longer require an internet connection to function

The simulation will be available on our website (https://cse.msu.edu/~denellja/simulation)[2].

5.2 Sample Scenarios Scenario 1:

This scenario begins with our car driving along the highway.

The driver activates CACC. The system starts searching for an already created platoon. Having found none, our car becomes the lead vehicle in a new platoon.

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 msu.edu)

Soon after, the car behind decides to also activate CACC and it finds our platoon. The car moves forward and attempts to join.

After driving for a while, the rear vehicle disengages CACC and leaves the platoon.

This leaves our vehicle as the leader of its own platoon.

Scenario 2:

This scenario begins with an already formed platoon like that described in Scenario 1.

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 msu.edu)

This time, the non-CACC vehicle attempts to enter the left lane, separating the platoon.

When this occurs, the system will detect the incoming obstacle and split the platoon.

The cars ahead of the obstacle will then continue on as normal. The cars behind the obstacle will then form a new platoon and take any evasive actions if necessary. Once the system is sure the obstacle is no longer a problem, the rear platoon will continue normally, with a new vehicle at the head.

6 References

[1] “J3016B: Taxonomy And Definitions For Terms Related To Driving Automation Systems For On-Road Motor Vehicles - SAE International,” SAE International,

28 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 msu.edu)

15-Jun-2018. [Online]. Available: https://www.sae.org/standards/content/j3016_201806/. [Accessed: 21-Nov-2019].

[2] J. DeNell, B. Carpio, C. Heinemann, J. Stafford, and Y. Zhang, “Cooperative Adaptive Cruise Control (CACC).” [Online]. Available: https://cse.msu.edu/~denellja/. [Accessed: 22-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 been sanitized for proprietary data. The students and the instructor gratefully acknowledge the participation of our industrial collaborators.

29 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 msu.edu)