software requirements specification (srs) lane management

Software Requirements Specification (SRS)

Lane Management System (LMS)

Authors: Sarah Palmer, Caroline Baidoon, Ben Miller, Hithesh Yedlapati

Customer: Mr. Ayush Agrawal

Instructor: Dr. Betty Cheng

1 Introduction

Lane Management System (LMS) is a new system which expands the capabilities of the

car in order to make corrections if the driver is distracted or unintentionally leaving a lane.

Through connections with many subsystems, the LMS can detect when the car is exiting a lane,

determine if it was intentional or unintentional, and adjust the speed and direction of the car to

correct the direction of the car if it was unintentionally exiting a lane. While this does not mean a

driver should rely on this technology to drive for them, this technology should serve as a safety

measure in cars.

This document outlines the LMS and all of LMS’s subsystems and components. Section

one describes the purpose of the system as a whole and provides the acronyms used throughout

the remaining document. The second section provides more detail into how the LMS is

organized with attributes and other functions. Specific requirements for the overall system and

some of the smaller systems are listed and updated after a year. There are many diagrams

provided to demonstrate the connections between these components in the fourth section. The

fifth section covers the information regarding the prototype, so you may try to see the observable

behavior of the system as a whole.

1.1 Purpose The purpose of this document is to provide a high-level outline of the software

requirements for the Lane Management System project. This document intends to highlight the

functionality and product needs for the lane management system. It also aims to help business,

management and development teams reach a consensus on the system’s requirements to deliver

the desired system and prevent accidents that might occur during the development process. The

customer for the Lane Management System project is Mr. Ayush Agrawal, who works in

artificial intelligence and machine learning at General Motors.

1.2 Scope The LMS is designed to prevent or limit unintentional lane changes, potentially

protecting the driver and individuals inside the car from hitting an object or going off the road.

The LMS is an embedded system consisting of many subsystems and hardware components.

While there are some programs focusing on lane detection and alerts and speed consistency,

there are no previous systems this system is adapting. The LMS is not responsible for

Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) 2 have been made by Betty H.C. Cheng, Michigan state University (chengb at msu.edu)

maintaining speed, detecting objects in the vehicle’s blind spot, nor detecting objects in the road

or in the lane the vehicle is traveling to.

The LMS uses cameras or lidar sensors to detect the lane lines on a road. If the sensors

can detect the lane lines, software in the car will calculate the relative position of the vehicle to

the lane lines. If the vehicle has gone too far outside of the lane line, the driver will receive an

audio and visual notification informing them of their position and that the Lane Keeping System

(LKS) will activate. When LKS activates the vehicle will apply torque on the steering wheel to

direct it back to the center of the lane, as well as change the speed of the vehicle if necessary on a

curved road.

1.3 Definitions, acronyms, and abbreviations

Term Definition

LMS Lane Management System. This is

the name of the overall system

being built. The LMS includes a

lane sensing feature which

identifies the lane in which the host

vehicle is in and the position of the

host vehicle within its respective

lane.

LKS Lane Keeping System. This system

takes control of the vehicle away

from the driver to steer and adjust

the position of the vehicle within its

respective lane.

LCS Lane Centering System. The Lane

Centering System is like the LKS.

Its purpose is to ensure the host

vehicle is directly in the center of

its lane. Not leaning too much

towards the right or left of the

center of the lane.

LDWS Lane Departure Warning System.

This system makes use of the lane

sensing features to notify the driver

when the vehicle departs a lane.


GPS Global Positioning System. A

satellite-based radionavigation

system that describes our relative

location on earth.

UI User Interface. The point of human-

computer interaction and

communication in a device.

Camera Sensing Subsystem The subsystem of the LMS that

takes pictures on the sides of the

vehicle and sends the images to a

processing unit for lane marker

detection.

Image Processing Subsystem Processes the images coming from

the camera to identify lane markers.

Vehicle State Estimation

System

A subsystem that contains a set of

sensors which periodically

determine the speed, steering angle,

and road curvature.

Path Prediction Subsystem This software subsystem receives

information from the camera

sensing and image processing

subsystems. It attempts to predict

the vehicle’s path to detect, warn,

and possibly correct any potential

lane violations.

User Interface System This is the system that the driver

and LMS exchange information

through. It is where human-

computer interaction takes place.


Supervisory Control Systems This system has control over all

LMS’s subsystems. It decides when

to enable and disable specific

subsystems.

1.4 Organization

The rest of the SRS will discuss the requirements, constraints, and specific scenarios of

the Lane Management System.

The outline of the SRS document is listed below:

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Definition, Acronyms, and Abbreviations

1.4. Organization

2. Overall Description

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

3. Specific Requirements

4. Modeling Requirements

5. Prototype

5.1. How to Run Prototype

5.2. Sample Scenarios

5.2.1. Stay in Lane

5.2.2. LMS/LKS active

5.2.3. Passive Mode

5.2.4. Camera Obstructed

5.2.5. Turn Signal

5.2.6. Override

5.2.7. System is off

6. References

7. Point of Contact

2 Overall Description

This section will cover the overall big picture of the product. It will start with going over

the perspective and the functions. Then the user characteristics will be specified. Lastly, it will


then cover the constraints of the current product, the assumptions made, and the requirements

outside the scope of this current project.

2.1 Product Perspective

The Lane Management system is designed to assist the driver with lane switching. The

system determines if a lane change is intentional or unintentional, and if unintentional, sends a

warning to the user and takes control of the vehicle until it is back to being centered.

The Lane Management System is also independent and is not a subset of any larger

system; however, the system may work alongside other systems, such as blind spot detection and

adaptive cruise control.

Although it is independent, the Lane Management System contains many subsystems,

including but not limited to the Camera Sensing System, Image Processing System, Lane

Departure Warning System, and Lane Keeping System. All the subsystems need to be

completely functional for the LMS to be active.

The primary constraint to the Lane Management System is being able to detect lanes on

both the left and right side of the vehicle. If the lanes are not present or detected, the lane

management system should turn off. Another constraint is the vehicle needs to be traveling at

least 35 mph for the system to be in active mode.

As for the system’s updates, software fixes can be issued over the air; however, hardware

issues will result in a vehicle recall.

2.2 Product Functions

The LMS is designed to improve safety and provide extra convenience for future drivers

by providing lane departure warnings and corrective control of the steering wheel. The main

features of the LMS include the LKS, LDWS, and LCS. The LKS and LDWS work directly with

each other. The LKS receives notification from the LDWS after the LDWS has detected an

unintentional lane departure. The LKS then steps in and takes control of the steering wheel (and

sometimes driving speed) away from the driver to help the vehicle maintain correct positioning

in its lane. The LCS works similarly to the LKS, but its main function is to take data collected

from the camera sensing subsystem and continuously adjust the position of the steering wheel to

keep the host vehicle directly in the center of the lane.

In addition to the systems described above, the LMS also relies on six different

subsystems to function at full capacity. The Camera Sensing Subsystem uses the camera sensors

located on either side of the host vehicle to detect lane markings. The Image Processing

Subsystem takes pictures taken by the Camera Sensing Subsystem to identify the lane markers.

The Vehicle State Estimation System has its own set of sensors which determine the current

“state” of the host vehicle. “State includes speed, road curvature, and steering angle. The Path

Prediction Subsystem takes in information from the Image Processing and Vehicle State

Estimation Subsystems to predict the path of the vehicle and warn the driver of potential lane

violations. The User Interface Subsystem is the mode of communication between the driver and


the LMS. The sixth and final system is the Supervisory Control System. It has control over all

subsystems, which includes the ability to decide when to enable or disable certain subsystems.

2.3 User Characteristics

The user of the system is referred to as the driver. The driver is expected to be legally

authorized to operate the vehicle they are driving. All manuals and instruction information

regarding the system should be read and understood prior to operating the LMS system. The

driver must be able to read and interact with the notifications and on/off switches on the user

interface. During operation, the driver is ultimately responsible for following all traffic laws and

for the course of their vehicle even when the LKS is active.

2.4 Constraints

The system will have several constraints that will limit the developer’s options in the

designing and building process. There are safety-critical constraints and general constraints.

First we will start with our safety-critical constraints. These are systems whose failure

could result in serious harm and injury. These are:

1. The detection system

2. The image processing system

3. The path prediction system

4. The override function

5. The movement function

The detection system is critical because if a hazard, or another driver is not accurately

detected, the driver will be put in harm's way. The processing system is safety-critical for the

same reason. The path prediction system has to work because if suddenly the system were to

detect a 90 degree turn and 45, the overall system needs to know that is much too fast, and not to

attempt the correction so suddenly. Lastly, the movement system is clearly very critical because

a wrong movement could result in a dangerous crash.

Next is the list of the general properties, that if a failure occurs then the system will not

perform properly. These are:

1. The on-off switch

2. The turn signal check

3. The user interface

4. The hardware

5. The feedback loop

If the on off switch fails, then the system will either be stuck on or off which makes it

completely unusable at worst. The turn signal check makes sure that the driver does not have to

override every lane change, so losing the functionality would cause LMS to kick in on every turn

or lane change. The user interface helps control the system, and is also very important for those


with disabilities, so it needs to be working properly. Lastly the feedback loop should work as it

helps control what is being seen, so without it the LMS will not be able to work properly.

2.5 Assumptions & Dependencies

It can be assumed that the components of the Lane Management System, such as all the

camera sensors, are functional. It is also assumed that the driver has full control and is able to

turn the Lane Management System on and off. The hardware is also assumed to be fully

functional.

There is also a GPS system that contains map information of the lanes from General

Motors.

The Lane Management System is dependent upon proper weather conditions and visible

lane markings. Passive or Active mode is also dependent upon the speed of the vehicle.

2.6 Apportioning of Requirements

There are several requirements that are beyond the scope of this project. These features

may be addressed/implemented in a future version. These requirements are:

● Ability to detect obstacles on the side of the road

● A way to clear/unblock the camera

● Update the user interface to be cleaner, sleaker, and more user friendly

● More accurate data collection

● Work on dirt roads and bidirectional roads

3 Specific Requirements

Need camera sensors to detect white lines (lanes) on road •

● Keep track of car information such as speed

● Account for road signs and GPS information

● Must be able to calculate the relative position of the vehicle

● Steer and Adjust position of vehicle if necessary (LKS)

● Gather information from sensors and images to detect lane violations

● Sensors will alert driver when there are no defined lane markings, or the sensors cannot

detect them with confidence

● There needs to be a supervisory control system that controls all other subsystems, and

will decide when to enable and disable other subsystems

● Include a lane keeping system (LKS)

● Including a lane centering system (LCS)

● Including a lane departure warning system (LDWS)

● The system supervisor will need to change the angle of the steering wheel and the speed

of the vehicle when the lane keeping system notifies it that the driver is not continually in

one lane


● There should be a camera sensing subsystem that takes pictures on the sides of the car

and sends them to the image processing unit for lane marker detection

● The image processing subsystem must process the images it receives from the camera

sensing subsystem to figure out where the lane marker should be

● The vehicle state estimation system will have sensors that periodically calculate the

speed, steering angle, and road curvature

● LKS would allow the system to intervene and try to send commands to steer and adjust

the position of the vehicle

● The path prediction subsystem will receive information from the vehicle path and any

potential lane violations and possibly override the driver

● Lane departure warning system (LDWS) must have a way of warning the driver when

their vehicle is starting to drift out of the lane

● A user interface should be added so the users understand what is going on easily and can

make changes or spot errors easily

For the LMS, there is a wide variety of potential cybersecurity threats that should be takin

into account. Many features common to modern cars can act as a gateway for hackers to take

control over the vehicle and information being provided to the vehicle. Wi-Fi, GPS, Bluetooth,

and possible cellular phone connectivity, just to name a few. If a hacker is to gain control of the

brakes and disable them or use a power lock to force the vehicle to accelerate, this can put the

LMS in jeopardy. The LMS is supposed to shut off when the driver overrides the system as it is

trying to take control. It will need to be made sure that the LMS will also shut off when a hacker

attempts to override the system controls. If someone is to commit a cyber-attack on the GPS in

the vehicle, this can also put the LMS at risk. For example, if a driver is out driving in inclement

weather and the Camera Sensing Subsystem suddenly loses its ability to view what is in the

cameras, the GPS is supposed to step in so that it can tell the LMS where the vehicle is currently

located. If both the GPS and cameras are being compromised, the LMS will need to shut itself

off because it will no longer be able to provide adequate assistance to the driver. Proper testing

and independent verification and validation needs to be carried out to rule out potential bugs and

viruses and ensure the drivers and their vehicles are safe from potential cyber-attacks.

4 Modeling Requirements The figures below represent the requirements listed in Section 3 in a visual way. These

display the use cases, the high-level class diagram, the sequence diagrams, and the state

diagrams for the LMS system. These are written in Unified Modeling Language (UML) notation.

4.1 Use Case Diagrams


Figure 1: Use Case Diagram for LMS

4.2 Domain Model and Data Dictionary This section introduces the domain model for the LMS and the data dictionary for all

elements of the domain model. The domain model describes all components of the system and

how they are connected and can interact with each other. The data dictionary in an in-depth

description of each of these components, including each component’s attributes, operations, and

relationships.

4.2.1 Domain Model Figure 2 shows the domain model for the LMS. The classes, attributes, and relationships

are expressed using UML notation. The boxes represent a class and inside the box it has

attributes which are similar to variables in a class and operations which are the functions

included in that class. The lines connecting the boxes indicate a relationship between two boxes.

Associations are lines with no symbol at either end and indicate a connection. Aggregation

relationships are indicated by a line with a diamond at one end and indicate that one class is “part

of” the other class.


Figure 2: Domain model for LMS System

4.2.2 Data Dictionary The data dictionary in this section is an in-depth description of the class included in the

class domain. It demonstrates what the class purpose is and what it is capable of and the

relationships it has with the other classes.

Name LMS

Description A driver assistance system that can include a

variety of functions starting with the simplest

passive LMS that can detect the lanes and

compute the relative position of the vehicle to

the most complex active LMS, which can take

over the control from the driver to position the

vehicle within a lane.

Relationships Aggregation:

LKS, LCS, LDWS, Path Prediction- The LMS

consists of many subsystems.

Association:

User Interface, Switch- Interacts with the user

interface to send messages to the driver. Also,

the switches can tell the LMS when it is

turned on.

Attributes Mode: int -indicates what state the LMS is in.

0 indicates off, 1 indicates passive, 2 indicates


active.

Operations

Public

Name LKS

Description An enhancement to LDWS, where the system

could intervene and try to send commands to

steer and adjust the position of the vehicle


LMS- One of the subsystems that make up the

LMS. This is specifically an enhancement to

the LMS.

Association:

Switch- The switches can tell the LMS when

it is turned on.

Attributes Torque: bool - indicates if there is being

torque applied to the wheel to adjust the path

of the vehicle

Position: double - indicates the position of the

vehicle within the lane lines.

TurnedOn: bool - indicates if the LKS is being

actively used or if it is turned off.

Operations

Public

Name LCS

Description The Lane Centering System that assists the

LMS in operations.


LMS- One of the subsystems that make up the

LMS.

Attributes

Operations

Public


Name LDWS

Description Makes use of the Lane sensing feature and

issues warnings to the driver when the vehicle

leaves a lane.


LMS, - One of the subsystems that make up

the LMS.

Association:

Warning- Sends warnings to the warning class

that then displays the warning on the user

interface.

Attributes TooLeft: bool - indicated if the car is too far

left of the lane. Used to inform the warning

sent to the driver.

TooRight: bool - indicated if the car is too far

right of the lane. Used to inform the warning

sent to the driver.

Operations

Public

Name Path Prediction

Description A software subsystem receives information

from the image processing subsystem and

vehicle state estimation system and tries to

predict the path of the vehicle in order to

detect, warn and possibly correct any potential

lane violations.


LMS, - One of the subsystems that make up

the LMS.

Association:

Image Processing, Vehicle State Estimation,

GPS- Receives data from these classes that

Path Prediction uses to calculate the relative

position of the car and determine if a warning

should be issued to the driver.

Attributes


Operations

Public

Name Image Processing

Description Processes the raw images coming from the

camera and identifies the lane marker.

Relationships Association:

Camera Sensors, Feedback loop, Path

Prediction- receives data from the camera

sensors that it sends to the feedback loop for

quality assurance. Sends the data calculated to

the Path Prediction class.

Attributes LaneDetected: bool - indicates whether a lane

is clear in the image taken by the camera

ObjectDetected: bool - indicates if an object is

observed in the image taken by the camera

Operations

Public

Name Camera Sensors

Description Captures images on the sides of vehicle and

sends over to the image processing unit for

lane marker detection


Image Processing- Send the graphics the

camera captures to the image processing

object so they can be processed.

Attributes

Operations

Public

Name Feedback Loop

Description An object that processes the graphics received


from the camera to ensure they are quality and

can be used for path prediction and vehicle

state estimation.


Image Processing- Given data from image

processing to analyze the quality of and

returns the status of the graphics

Attributes Valid: bool - indicates if the graphics from the

image processing class were clear enough to

be used for the vehicle estimations.

Operations

Public

Name Vehicle State Estimation System

Description A set of sensors that would periodically

determine the speed, steering angle and road

curvature


Path Prediction: Sends information to the Path

Prediction class so it can be used to calculate

the path of the vehicle.

Attributes Curvature: double - curve of the road

Speed: int - speed of vehicle

VehicleAngle: double - the angle the car is

traveling in

Operations

Public

Name GPS

Description The Global Positioning System incorporated

into the car. Used to locate the vehicle's

position if the camera sensors are not properly

working.


Path Prediction: Sends information to the Path


Prediction class so it can be used to calculate

the path of the vehicle.

Attributes

Operations

Public

Name User Interface

Description The driver and LMS exchange control and

data information through this system.


LMS, Switch, Warnings- Serves as liaison

between the LMS and the driver. The driver

influences the warnings and switches so the

User interface can detect the drivers wishes

through the warnings and switch class.

Attributes

Operations

Public

Name Switch

Description Representation of the driver’s choices

regarding the overall status of the LMS and

LKS.

Relationships Associations:

LMS, LKS, Driver- informs the LMS and

LKS of their overall status that the driver set.

Driver sets the overall status of the system,

unless there is a failure in the system.

Attributes SwitchOn: bool - indicates if the switch is

turned on or off.

Operations

Public


Name Warnings

Description Sends warnings it receives from the LDWS to

the user interface to display them to the

driver.

Relationships Associations:

User Interface, LDWS, Driver- The warning

system communicates updates from the driver

to the user interface. The LDWS sends the

warning system warnings to display to the

driver. The driver can dismiss the warnings.

Attributes WarningMessage: string - indicates what

warning needs to be issued to the driver based

on what has happened in the system and the

location of the vehicle.

Operations

Public

Name Driver

Description The main user of the system. Operates the

vehicle and has control of the overall status of

the LMS and LKS.


Switch, Warnings- Driver interacts with these

two parts of the user interface switches and

warnings to adjust the system. Also, the driver

is notified of changes via the switches and

warning systems.

Attributes

Operations

Public

4.3 Sequence Diagrams These sequence diagrams serve to demonstrate how components of the system interact in

a particular scenario the system will encounter. There are a variety of scenarios to demonstrate

what might occur within the system during normal operations as well in some abnormal or

outlying scenarios. The sequence diagrams use UML notation. Classes are listed at the top with


the dotted vertical lines representing their life line. Messages sent between two classes are

represented with horizontal lines.

4.3.1 Car Stays in Lane In Figure 3, the vehicle is being driven down a straight road at a constant speed of 35

miles per hour or greater. The driver is not drifting in or out of the lane and maintains the

vehicle’s position in the center of the lane. The system is able to continuously collect data from

the camera sensors and GPS to assess potential obstacles and the driver’s performance.


Figure 3: Sequence Diagram when car stay in lane

4.3.2 Car Leaves Lane and LKS is Activated The driver of the vehicle in Figure 4 would be departing from the lane they were

detected to be in on a zero-curvature road. The driver would also be driving at a speed of 35

miles per hour or greater so the lane management system would be working in active mode. The


overall system (the LMS) would detect the relative position of the vehicle in the lane (to the

extreme right, left, etc.). The lane departure warning system would then issue a warning to the

driver through the UI to notify them that they are departing the lane. Then, the lane keeping

system would try to send commands to steer and adjust the position of the vehicle to get it back

into the center of its respective lane.

Figure 4: Sequence Diagram for the car leaving the lane and LKS activating

4.3.3 Active Requirements Lacking In Figure 5, the lane management system would be switching from active to passive

mode after detecting that the requirements needed to be in active mode are not being met. For the

system to be in active mode. The driver needs to be going at a speed of 35 miles per hour or

greater. The vehicle state estimation subsystem would be taking information from the camera

sensors to determine the state of the vehicle. The state includes speed, steering angle, and road


curvature. Once a speed of 34 miles per hour or less is detected, the system will automatically

switch its mode to passive and use the UI to notify the driver that the system is now in passive

mode.

Figure 5: Sequence Diagram for the system staying in Passive mode

4.3.4 Camera Obstructed Figure 6 demonstrates what will happen if there are severe weather conditions

obstructing the cameras' views. The lane management system switches to passive mode until the

cameras are able to detect the lanes again.


Figure 6: Sequence Diagram for when the camera is obstructed

4.3.5 Turn Signal Active Figure 7 demonstrates what will happen if a driver wants to intentionally shift lanes with

their turn signal on. The system should switch to passive mode, allowing the user to switch lanes

without the system issuing warnings and correcting itself.


Figure 7: Sequence Diagram for Turn Signal Scenario

4.3.6 Driver Overrides LKS Figure 8 demonstrates the scenario of the driver overriding the LKS. If the driver wants

to override while the system is trying to apply changes, the driver will be able to apply a certain

amount of torque to the steering wheel to regain primary control of the vehicle.

Figure 8: Sequence Diagram for the Driver Override Scenario


4.4 State Diagrams This section introduces the state diagrams for each component of the LMS. Each state

diagram contains similar information to the sequence diagrams above, but instead of

demonstrating relationships between components, state diagrams focus on the changes of state an

individual object goes through in all of the use cases.

These are also written in UML notation. The black fill circle points at the default state.

Each state is represented by a box and the arrows show a potential transition between states. The

descriptions along the arrow indicate when the transition occurs.

4.4.1 Driver Figure 9 depicts the state diagram for the driver of the system. The driver begins in

primary control of the vehicle. If the driver drifts out of the lane and LKS is activated, the LKS

system becomes the primary control of the vehicle as it adjusts the path and speed of the vehicle.

Primary control of the vehicle is transitioned back to the driver if the driver applies significant

torque to the wheel as the LKS is active or when the adjustment is completed.

Figure 9: State Diagram for Driver

4.4.2 Image Processing Figure 10 depicts the state diagram for the image processing object. The Image

Processing class begins in an idle state because it cannot act until it receives data from the

camera. When it receives that data it will process the data. When it is done analyzing the photos

it will send the data to the path prediction class. After sending the data it will return to the idle

state until it receives data from the camera again.


Figure 10: State Diagram Image Processing

4.4.3 Camera Sensors Figure 11 depicts the state diagram for the camera sensors. The camera sensors start in

an idle state. When the cameras are told the LMS system has turned on they will start detecting

their surroundings and send the graphics to the image processing class. After they send those

graphics, the camera sensors return to an idle state until they are instructed to detect their

surroundings again.


Figure 11: State Diagram Camera Sensors

4.4.4 Switch Figure 12 depicts the state diagram for the switches for the LMS and LKS. There are two

switches connected to the user interface. One controls the LMS and one controls the LKS. They

start in an off state and then the driver can switch them on. If the switch is on, the driver can

switch it off or it can be turned off due to an internal failure or due to the camera inability to

detect their surroundings.

Figure 12: State Diagram for Switch class


4.4.5 LKS Figure 13 depicts the state diagram for the LKS. The LKS system starts in an off state.

When the LKS switch is turned on the LKS enters a passive state. The passive state means that it

is on standby but will not send any commands to the system. If the requirements for the LKS to

send commands is met it will return to active state. If in a passive or active state and there is an

internal failure or the system is turned off, LKS will return to an off state.

Figure 13: State Diagram for the LKS class

4.4.6 LMS Figure 14 depicts the state diagram for the LMS. The LMS system starts in an off state.

When the LMS switch is turned on the LMS enters a passive state. The passive state means that

it is on standby but will not send any commands to the system. If the requirements for the LMS

to send commands is met it will return to active state. If in a passive or active state and there is

an internal failure or the system is turned off, LMS will return to an off state.


Figure 14: State Diagram for LMS class

4.4.7 User Interface Figure 15 depicts the state diagram for the user interface. The user interface begins in an

off state. When the LMS is turned on via a switch the user interface is activated and in an idle

state. If there is a warning that needs to be issued to the driver, the user interface enters a

warning state and will display the message accordingly. Once the message times out or is

dismissed by the driver the user interface will return to the idle state.


Figure 15: State Diagram for User Interface class

4.4.8 Vehicle State Estimation System Figure 16 depicts the state diagram for the vehicle state estimation system. The vehicle

state estimation system will begin in an off state. When the LMS is turned on it will enter an on

and idle state. When the LMS asks the vehicle state estimation system for the state of the vehicle

it will enter a sensor mode, process the data, and send it back to the LMS. After sending the data

the vehicle state estimation system will return to an idle state.


Figure 16: State Diagram for Vehicle State Estimation System class

4.4.9 Path Prediction Figure 17 depicts the state diagram for the path prediction class. The path prediction

object begins in an active but idle state. It waits for data from the image processing subsystem

and vehicle state estimation system, and then it will transition into a calculating state. It will

calculate the possible path of the vehicle. If there is a potential lane violation it will enter a

warning state and send a warning to the LDWS. Otherwise, or after sending that warning signal,

it will return to the active but idle state.


4.4.10 LDWS

Figure 17 depicts the state diagram for the LDWS. The LDWS object begins in an active

but idle state. If there is a potential lane violation the LDWS will receive a message from the

Path Prediction class. It will then enter a warning state and send a message to the warning class

within the user interface and then return to the active-idle state until it receives another message.

Figure 17: State Diagram for Path Prediction class

5 Prototype

The prototype allows the user to visit multiple scenarios. Each scenario contains a top

view visual of the vehicle and a short description. The specific scenarios can be found in Section

5.2.

5.1 How to Run Prototype


To access the prototype, click the prototype tab at the top of the website or click the link

below. Both the 1st and 2nd checkboxes will need to be checked in order to be able to run

through the different scenarios.

To run the prototype, simply check certain conditions to see how the vehicle and system

should react, as shown above.

Link to prototype: http://webdev.cse.msu.edu/~mill2994/lms3/prototype.html

5.2 Sample scenarios:

The following sections describe the 7 different scenarios that the system currently

accounts for. Each scenario has a small description, how to recreate it, and a figure of the

scenario from the prototype, which includes a more detailed description.

5.2.1 Scenario 1: Stay in lane

In this scenario the vehicle is driving normally and centered in the lane, LMS is detecting

but not making adjustments.

To view this scenario:

1. Check “Does the user have LMS on?”

2. Check “Are all requirements met?”


5.2.2 Scenario 2: LMS/LKS is active

In this scenario the vehicle is accidentally leaving the lane causing LMS to go into action

and adjust the care back to the center.




3. Check “Is the car leaving the lane?”

5.2.3 Scenario 3: Passive Mode

In this scenario the system is in passive mode, as either it is not going fast enough,the

lanes are not marked or some other requirement is not met.


1. Check “Does the user have LMS on?“


5.2.4 Scenario 4: Camera obstructed

In this scenario the camera can no longer accurately detect and the system enters passive mode

until the weather or obstruction is gone.




3. Check “Is the camera Obstructed?”

5.2.5 Scenario 5: Turn signal

In this scenario the driver is changing lanes with a turn signal on, so there should be no

action by the system.






4. Check “Is the turn signal on?”

5.2.6 Scenario 6: Override

In this scenario the driver is overriding the system's correction by applying enough torque

to the steering wheel.





4. Check “Is the driver overriding?”


5.2.7 Scenario 7: System is off

In this scenario the system is simply off. No data or action is being taken in this state. The

state can be changed by the user manually turning the system on.


1. Uncheck “Does the user have LMS on?”

6 References 1. Palmer, S., Miller, B., Yedlapati, H., Baidoon, C. (2021). CSE 435 Group Project.

http://webdev.cse.msu.edu/~mill2994/lms3/index.html 2. Agrawal, S. (n.d.). Lane Management System.

https://www.cse.msu.edu/~cse435/Projects/F2021/ProjectDescriptions/2021-GM-Lane_Management_System-Agrawal.pdf

http://webdev.cse.msu.edu/~mill2994/lms3/index.html




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.

software requirements specification (srs) lane management

Documents