srs draft v1.docx - michigan state university · web viewtemplate based on ieee std 830-1998 for...

1

Software Requirements Specification (SRS)

Automated Pedestrian Collision Avoidance (APCA1)

Authors: Team STOP (Systematically Tracking Oncoming Pedestrians)

Scott Rucinski, Eric Slenk, David Wigell, Jennifer Manning

Customer: Mr. David Agnew, Continental Automotive Systems

Instructor: Dr. Betty H.C. Cheng, Michigan State University

1 Introduction This Software Requirements Specification (SRS) contains seven subsections that describe the Automated Pedestrian Collision Avoidance (APCA) system. In this SRS, we will provide both high-level and detailed overviews of the system.

This first section will introduce the purpose, scope, and organization of this paper, as well as any definitions, acronyms, and abbreviations used in this SRS. We will present an overall description that outlines the characteristics, constraints, and functionalities of our system. We will also provide a list of the requirements of the system, as well as diagrams to show how our system meets those requirements. This SRS will also explain how to use the prototype of our system, which is available on our website [2].

1.1 PurposeThe purpose of this SRS document is to present our design of the Automated Pedestrian Collision Avoidance system. It is intended to provide information about our system to the customer, Mr. David Agnew of Continental Automotive Systems, as well as any other user of our system.

1.2 ScopeThe purpose of the Automated Pedestrian Collision Avoidance system is to activate the brakes in order to avoid a collision with a pedestrian in the path of the vehicle. It is an automotive system that is embedded within an autonomous vehicle. The system will use a sensor to detect any pedestrians within the path of the vehicle. If a pedestrian is detected, then the system will send a braking request to the vehicle’s braking system to slow the vehicle and avoid a collision. In close proximity, the vehicle will come to a complete stop.

The number one objective of the APCA system is safety. There are to be zero collisions with a pedestrian. The second objective of the system is efficiency. The system should minimize any lost time the vehicle experiences while avoiding a pedestrian [1]. Lost time is defined as the difference in time between when the vehicle will reach a fixed point beyond the pedestrian when the system is on and will slow down, compared to when the system is off and will not slow down.

A sensor will be constantly searching for any pedestrians within the path of the vehicle. When it detects a pedestrian, it will send a packet with the pedestrian information to the APCA system. The system will use this information as well as the vehicle information to determine the likelihood of a collision. If the system determines a collision is possible, then it will send a braking request to the braking system. The braking system will decelerate the vehicle until a collision is no longer possible. After the pedestrian has been avoided the system will send a request to the accelerator system. The accelerator will accelerate the vehicle to the velocity the vehicle was at before the pedestrian was detected.

The system also comes equipped with a fail safe mode. This mode is activated when the braking system of the vehicle is not responding as fast as it should, which is determined by the vehicle and communicated to the APCA system. The fail safe mode will increase the time allotted for the vehicle to reach a requested deceleration from 200 to 900 ms. This means the system will send the braking request to the brakes sooner than when the system is not in fail safe mode. This gives the vehicle more time to slow down before it would collide with a pedestrian.

1.3 Definitions, acronyms, and abbreviations

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

2

For the purposes of this SRS document, this section will define any terms used within this SRS, as well as their acronyms and abbreviations. The terms used are as follows (in alphabetical order):

Accelerator - This subsystem accelerates the vehicle to a speed of 13.9 m/s (50 kph) at a rate of .25 g (.245 m/s^2) when there is no pedestrian in the path of the vehicle [1].

Autonomous - Autonomous is used to denote anything that is self-operating. This means that once it is on, it will run by itself and can not be manipulated or controlled by an outside user. The vehicle is autonomous because it is a self-driving car, and the APCA system is autonomous because it requires no input from a user.

Automated Pedestrian Collision Avoidance (APCA) System - This is the system we are designing. The APCA system will use a sensor to detect pedestrians entering the path of the vehicle and will send signals to the braking system to decelerate the vehicle before a collision occurs.

Brake By Wire (BBW) System - This is the braking subsystem used in our vehicle. It decelerates the vehicle by applying braking torque via electro-mechanical actuators to all four wheels [1].

Fail Safe Mode - When the vehicle detects that the brakes are not working properly, the APCA system enters fail safe mode. While in fail safe mode, the system accounts for a longer response time from the BBW system, and increases the response time from 200 to 900 ms [1].

Packet - This is an electronic data packet contains information about the pedestrian. It contains their location relative to the vehicle and their velocity.

Pedestrian - The pedestrian is the object that is in, or moves into, the path of the vehicle. A pedestrian has both velocity and location relative to the vehicle. In terms of sample scenarios the pedestrian always moves perpendicular to the vehicle.

Pedestrian Collision Avoidance Algorithm (PCA Algo)- The algorithm is a step-by-step procedure that determines the course of action in the system. It takes in information such as the location and movement of the pedestrian and the vehicle. It will then decides what threat level to set the system to in order to avoid a collision.

Pedestrian Motion Scenario - Specific scenarios that will test the designed APCA system. Each scenario has its own pedestrian motion data that determines the movement of the pedestrian over time in relation to the vehicle.

Pedestrian Sensor - This subsystem gathers pedestrian information, that includes pedestrian velocity and location relative to the vehicle. The pedestrian sensor sends that information as a packet to the controller every 100 ms.

Response Time - This is the time it takes for the braking subsystem to reach a certain deceleration. The customer has specified the response time to be 200 ms. In fail safe mode, the response time increases from 200 ms to 900 ms.

Software Requirements Specification (SRS) - This is the document that presents the different aspects and requirements of the Automated Pedestrian Collision Avoidance system in an organized fashion.

Steady State Velocity - The velocity that the system will initially be traveling at for sample scenarios, defined to be 13.9 m/s. This is also the velocity that the vehicle accelerate to after slowing down to perform safety maneuvers.

Stereo Camera - The pedestrian sensor uses a stereo camera to track the pedestrian. The stereo camera uses multiple lenses in order to track distances and speeds more accurately.

Subsystem- A subsystem is any system within the vehicle that contributes to the APCA system.

Threat Level - The threat level refers to the probability that a collision will occur. There are three different threat levels in the system that depend on whether a pedestrian has been detected, and the velocity and location of both the vehicle and the pedestrian. The system will always have one of the three threat levels assigned at any given moment.

Threat Level: collisionImminent - The vehicle is in threat level collisionImminent when the pedestrian sensor detects a pedestrian, and the velocity and location of both the vehicle and pedestrian will result in a collision. This is when the system will send a braking request to the BBW system to decelerate the vehicle and avoid the collision.

Threat Level: noPedestrian - The threat level when no pedestrian is detected. No action will be taken.

Threat Level: safeDistance - The vehicle is in threat level safeDistance when the pedestrian sensor detects a pedestrian, but the velocity and location of both the vehicle and pedestrian will not result in a collision.


3

Time Loss - As defined in the requirements specification provided by the customer, time lost is the “time difference (in seconds) between system on and system off to reach a common point beyond the pedestrian with controlled vehicle back again at steady state velocity [1].” That is to say, time loss is a comparison between the time it takes a vehicle without an APCA system to reach a certain point, compared to how long it takes a vehicle with an APCA system to reach that same point.

Vehicle - The vehicle houses all of the APCA system as well as the different subsystems, such as the brake-by-wire system, the accelerator, and the pedestrian sensor. It has a velocity and location, and in terms of sample scenarios it always travels in a straight line.

1.4 OrganizationThe rest of the document is divided into six different subsections. Each subsection will cover a different aspect of the APCA system. Subsection two contains the overall product description. It includes a general description of the product, as well as descriptions of the product functionalities and user characteristics. Constraints, assumptions, dependencies, and approportioning of requirements are also included in this section. Subsection three contains a list of the specific requirements of the project. The requirements are provided in the form of a hierarchical list. Subsection four provides a high-level overview of the system through the use of diagrams that represent the system. Subsection five provides information about the prototype of the system, including how to run the prototype. Sample scenarios were also run to test the system, and the results are provided. Subsection six provides a list of references for materials used over the course of this project, and subsection seven provides a point of contact to the professor of the course, Dr. Betty Cheng.

2 Overall Description In this section, several topics regarding the APCA system will be addressed. These topics include the product perspective, product functions, user characteristics, constraints, assumptions and dependencies, and approportioning of requirements. The product perspective subsection is a description of the context of the APCA system and its interface constraints. The product functions subsection is a description of the major functionalities of the APCA system. The user characteristics subsection is a description of the APCA system’s expectations of the user. The constraints subsection contains a list of constraints of the APCA system and their respective descriptions. The assumptions and dependencies subsection lists all of the assumptions made about the hardware, software, environment, and user interactions involved with the APCA system. The approportioning of requirements subsection lists all of the requirements that are determined to be beyond the scope of the current APCA system and may be addressed in future versions of the software.

2.1 Product PerspectiveThe APCA system activates upon ignition of the vehicle. Every 100 ms, it receives a packet of pedestrian information including the location of the pedestrian relative to the vehicle, the pedestrian velocity, and the direction that the pedestrian is traveling in relation to the pedestrian sensor system . If a pedestrian collision is imminent at the vehicle’s current velocity, then the APCA system will send a braking request to the BBW system to decelerate the vehicle. After the threat of a collision has passed, the APCA system will send a signal to the accelerator system to accelerate back to the steady state velocity.

Figure 1 displays the APCA system and its interactions with the pedestrian sensor and the BBW system during the collisionImminent threat level. Every block in the figure shows a subsystem of the vehicle and the flow of the data amongst them. The PCA Algo block is nested within the APCA system, because it a part of the system.


4

Figure 1: Data flow of the APCA system provided by Continental Automotive Systems

2.2 Product FunctionsThe primary function of the APCA system is to prevent all pedestrian collisions from occurring, which will be tested in each of the scenarios provided by Continental Automotive Systems. The secondary function of the system is to minimize any time lost due to the safety maneuvers required to prevent collision with the pedestrian. Both of these functions are stated in the Continental Automotive Systems requirements specification.

In order to complete the primary and secondary functions, the APCA system must also perform the following tasks. It must receive pedestrian information from the pedestrian sensor system and interpret that information. Also, it must receive vehicle velocity and acceleration information. The APCA system will then use the interpreted pedestrian information, vehicle velocity, and acceleration to compute a probability of collision with a pedestrian and assign a Threat Level based on that probability. The APCA system must send a deceleration request to the BBW system when a collision is deemed imminent. After a successful safety maneuver, the APCA system must send an acceleration request to the Accelerator system.

Figure 2 displays a generic scenario where a pedestrian is in front of a vehicle moving in a perpendicular direction. As the distance between the vehicle and the pedestrian decreases, the APCA system will re-evaluate the Thread Level. Once collision is imminent, it will activate the BBW system in order to prevent a collision.

Figure 2: Pedestrian moving in front of a vehicle, provided by Continental Automotive Systems

2.3 User CharacteristicsThe user is not expected to possess any background information regarding the APCA system, nor is he expected to have any particular skill level or general expertise with vehicles or other APCA systems. He will not directly interact with the ACPA system, as the system is embedded in an autonomous vehicle.


5

2.4 ConstraintsThe APCA system is constrained by the information provided by the pedestrian sensor. The only information it gathers about the pedestrian will come from this sensor. It is also constrained by the BBW system. The maximum rate that the vehicle can decelerate is 0.7 g (6.867 m/s^2) [1]. The vehicle will not decelerate until it is absolutely necessary in order to avoid a pedestrian. The system is also constrained by the vehicle itself. The vehicle is considered autonomous, which means that the APCA system is not intended to interact with the vehicle operator at any point in time. This would prevent the current system from having any manual override implementation allowed from the user.

2.5 Assumptions and DependenciesSeveral assumptions and dependencies need to be addressed about the APCA system. Those assumptions and dependencies are listed as follows:

● The pedestrian sensor must be in working condition and it must properly collect and send pedestrian information to the APCA system. It must also detect pedestrian location with an accuracy of +/- 0.5 m, pedestrian speed with an accuracy of +/- 0.2 m/s, and pedestrian direction with an accuracy of +/- 5.0 degrees. The APCA system must also successfully receive the pedestrian information every 100 ms.

● The BBW system is assumed to be in working condition and receiving braking requests from the APCA system. The BBW system is assumed to respond to braking requests within 200 ms. The maximum deceleration is assumed to be 0.7 g (6.87 m/s^2). The vehicle is assumed to decelerate at maximum deceleration whenever a deceleration request is sent.

● The APCA will send an acceleration request, after a safety maneuver has been executed, to the accelerator system. The accelerator system is assumed to be in working condition and properly receiving acceleration requests from the APCA system. The Accelerator accelerates at a maximum of 0.25 g (2.45 m/s^2).

● The vehicle is assumed to travel at a steady state velocity of 13.9 m/s (50.0 kph) when it is not avoiding a pedestrian.

● Roads and weather conditions are assumed to have no effect on vehicle traction, acceleration, or deceleration. Weather conditions are assumed to have no effect on the pedestrian sensor.

● The pedestrian is assumed to be moving in a direction perpendicular to the direction of the vehicle. The vehicle travels only in a straight line.

● The vehicle is assumed to engage the APCA system’s fail safe mode during times when the brakes would react slower. This is assumed to include faults in brakes, bad weather conditions, and any other conditions when the brakes will not respond within the defined response time.

2.6 Approportioning of RequirementsBased on negotiations with Continental Automotive Systems, the following requirements are considered to be beyond the scope of the current APCA system. The APCA system will not have to adjust for varying or extreme weather conditions. The system will also not interact with the user. There will be no warning indicators intended to capture the attention of the user because of the autonomous nature of the vehicle. Also, due to the autonomous nature of the vehicle, no APCA override mechanisms will be present. Traction of the vehicle tires and road conditions will not be considered in the APCA threat level calculations. Throttle control, used to decelerate the vehicle to a temporary state speed in order to avoid a pedestrian without applying the brakes, will not be included.

3 System Requirements This section contains enumerated requirements. A numerical hierarchy is used to show the relationship of each requirement.


6

1. Zero collisions allowed under all scenarios given by Continental Automotive System1.1. System must receive packets from the pedestrian sensor every 100 ms1.2. APCA system avoids pedestrians detected by pedestrian sensor

1.2.1. If pedestrian detected, set threat level to either safeDistance or collisionImminent1.2.1.1. Project vehicle location using vehicle velocity and acceleration1.2.1.2. Project pedestrian location using pedestrian velocity and position relative to vehicle

1.2.1.2.1. If the pedestrian is at a safe distance, system will do nothing1.2.1.2.2. If collision imminent:

1.2.1.2.2.1. Override steady state speed1.2.1.2.2.2. Send deceleration signal to BBW system

1.2.2. If no pedestrian is detected, continue at steady state velocity

2. “Lost time” shall be minimized for all scenarios provided by Continental Automotive Systems2.1. Braking signal not sent until APCA system threat level escalates to collisionImminent

2.1.1. Braking signal will not be sent in threat level noPedestrian or safeDistance2.2. When a pedestrian collision is avoided, the vehicle will accelerate to its steady state velocity (13.9 m/s) at a

rate of 0.25 g (2.45 m/s^2)

3. A fail safe mode for the brake system exists3.1. Increases the response time for BBW system 3.2. The PCA algo should adjust to maintain zero collisions in trade for increased lost time

4 Modeling Requirements This section provides diagrams to represent the different aspects of the APCA system.

Figure 3 is a use case diagram of the APCA system. A use case diagram represents the possible ways our system will be used and how it interacts with other actors. In this use case diagram, the APCA system interacts with the pedestrian sensor, the accelerator, the BBW system, and the vehicle. The extends relationship is when one use case extends the functionality of another use case. For example, in figure 3 the Fail Safe Mode Active use case extends the Prevent Collision use case, by providing a new response time to reach the requested deceleration. An includes relationship is used when one use case encompasses another use case. For example, in figure 3 the Prevent Collision use case includes the Set Threat Level use case, because Prevent Collision is determined by the the current threat level of the system.


7

Figure 3: A use case diagram depicting the APCA system

Provided below is an enumeration for each of our use cases. Each use case description provides the name of the use case, which actor performs the use case, a brief description of what the use case does, the relationships the use case has with other use cases, and the requirements the use case fulfills.

Use Case: Send Packet

Actors: Sensor

Description: Pedestrian sensor sends pedestrian information to the APCA system in the form of a packet every 100ms

Type: Primary and essential

Includes: None

Extends: None

Cross-refs: Requirement 1.1, 1.2

Use cases: None


8

Use Case: Set Threat Level

Actors: None

Description: Sets the threat level (probability) of a pedestrian collision using both pedestrian and vehicle information


Includes: None

Extends: None

Cross-refs: Requirement 1.2.1, 1.2.2

Use cases: Prevent Collision

Use Case: Prevent Collision

Actors: None

Description: Determines whether the threat level is significant enough to change the current velocity of the vehicle and maneuvers the vehicle to avoid pedestrians


Includes: Set Threat Level

Extends: None

Cross-refs: Requirement 1.2.1.2.2

Use cases: None

Use Case: Fail Safe Mode Active


9

Actors: Vehicle

Description: Initiates the fail safe operational mode for the APCA system given a request from the vehicle


Includes: None

Extends: Prevent Collision

Cross-refs: Requirement 3

Use cases: None

Use Case: Send Acceleration Signal

Actors: Accelerator

Description: Sends an acceleration signal to the accelerator when the vehicle is below its steady state velocity (13.9 m/s) to speed up to the steady state velocity

Type: Secondary and essential

Includes: None

Extends: None

Cross-refs: Requirement 2.2

Use cases: None

Use Case: Send Braking Signal

Actors: BrakeByWireSystem

Description: Decelerates the vehicle to target velocity


Includes: None

Extends: None

Cross-refs: Requirement 1.2.1.2.2.2, 2.1

Use cases: None

Figure 4 is a class diagram that represents the APCA system and its interaction with other actors. A class diagram provides information on what is included within each aspect of a system, and it represents how these aspects are related to one another. The class diagram provides a template for what is to come in the programming phase of development.


10

At the center of the class diagram in figure 4 is the CollisionAvoidanceSystem class. This class gathers the information from all of the other subsystems, such as the BBW system, Accelerator, Pedestrian and Sensor. These subsystems and the CollisionAvoidanceSystem are all a part of the vehicle class. It then uses this information to set a the system threat level. These threat levels are represented in the enumeration ThreatLevel: noPedestrian, safeDistance, and collisionImminent. The Sensor class is what gathers the information on the pedestrian. It will gather the information and send it a packet to the CollisionAvoidanceSystem class every 100 ms.

It is also important to note the MovingActor class. This class contains attributes and functions that are common to both the Pedestrian and Vehicle classes. In order to eliminate repetition, both the Pedestrian and Vehicle classes inherit the aspects of the MovingActor class. So the Pedestrian and Vehicle classes each contain the attributes and functions listed in the MovingActor

class as well as their respective classes.

Figure 4: A class diagram representing the APCA system and its relationships with other actors

Listed below is a data dictionary entry for each of the classes in the class diagram. Each data dictionary entry contains the name and brief description of each class, as well as a name and brief description for all attributes and operations within that class.

Element Name Description

Accelerator Aspect of the vehicle which controls the acceleration.


11

Attributes

Acceleration :float The acceleration of the vehicle after auto-brakes have been applied constant at .25 g or 2.4525 m/s^2.

Operations

accelerateTo (targetVelocity: float) Given one argument, a target velocity, it will accelerate the vehicle until it reaches that velocity.

Relationships Aggregated from the vehicle class, and has a directional association from the CollisionAvoidanceSystem.


BrakeByWireSystem Aspect of the vehicle which controls the brakes.

Attributes

responseTime: float The constant response time to reach each requested deceleration defined as 200 ms or .002

s.

releaseTime: float The constant time it takes to release the brakes after they have been applied defined as 100 ms or

.001 s.

maxDeceleration: float The maximum deceleration possible by applying the brakes constant at 0.7 g or 6.87 m/s^2.

deceleration: float The current deceleration rate that the brakes are applying.

failSafeResponseTime: float The constant response time to reach each requested deceleration when in fail safe mode

defined as 900 ms or .009 s.

Operations

getResponseTime (): float Gets and returns the attribute responseTime.

getReleaseTime (): float Gets and returns the attribute releaseTime.

getMaxDeceleration (): float Gets and returns the attribute maxDeceleration.


12

getDeceleration (): float Gets and returns the attribute deceleration.

setDeceleration (deceleration: float) Sets the attribute deceleration as the value of the argument.

decelerateTo (targetVelocity: float) Given one argument, a target velocity, it will decelerate the vehicle until it reaches that

velocity.

getFailSafeResponseTime (): float Gets and returns the attribute failSafeResponseTime.

Relationships Aggregated from the vehicle class, and has a directional association from the

CollisionAvoidanceSystem.


CollisionAvoidanceSystem The system used within the vehicle to avoid collision with pedestrians,

calculates the most time efficient speed for the vehicle when pedestrian

detected.

Attributes

failSafe: bool Boolean to see if the system is in fail safe mode.

pedestrianDetected: bool Boolean to see if a pedestrian is detected.

currentPedestrian: Pedestrian The pedestrian currently detected by the Sensor class.

Operations

avoidPedestrian () Takes measures to avoid the pedestrian based on the ThreatLevel.

setThreatLevel () Analyses the situation and sets a threatLevel depending on the severity.

isPedestrianDetected (): bool Gets and returns the attribute pedestrianDetected.

setPedestrianDetected (pedestrianDetected: bool)

Sets the attribute pedestrianDetected as the value of the argument.


13

getCurrentPedestrian (): Pedestrian Gets and returns the attribute currentPedestrian.

setCurrentPedestrian (currentPedestrian: Pedestrian )

Sets the attribute currentPedestrian as the value of the argument.

onStart () Activates the system.

onOff () Deactivates the system.

Relationships Aggregated from the Vehicle class, has a directional association to the CollisionAvoidanceSystem and

BrakeByWireSystem, has a directional association from the Sensor, and

contains an enumeration ThreatLevel.


MovingActor Describes any moving object.

Attributes

xPosition: float A float of the x location of the actor.

yPosition: float A float of the y location of the actor.

Velocity: float The velocity of the actor

Operations

move (time: float) Takes one argument, time, and moves the actor over the specified argument.

getXPosition (): float Gets and returns the attribute xPosition.

getYPosition (): float Gets and returns the attribute yPosition.

getVelocity (): float Gets and returns the attribute deceleration.

setVelocity(velocity: float) Sets the attribute velocity as the value of the argument.

Relationships Inherits the Vehicle and Pedestrian classes.


14


Pedestrian The object the vehicle is trying to avoid hitting by using the CollisionAvoidanceSystem.

Attributes

Diameter: float Constant diameter for pedestrian defined as 0.5m.

Operations

getDiameter (): float Gets and returns the attribute diameter.

Relationships Inherited from the MovingActor class, and has a directional association to the Sensor.


Sensor A Stereo sensor used to detect pedestrians in front of the vehicle.

Attributes

Operations

sendPedestrian () Gathers all of the data about the pedestrian and sends it to the CollisionAvoidanceSystem.

startSendingPackets () Activates the process of sending packets of information regarding the pedestrian,

will set a timer to send updated information every 100ms.

scanForPedestrian () Scans the area for a pedestrian.

Relationships Aggregated from the vehicle class, and has a directional association to the

CollisionAvoidanceSystem, and the Pedestrian.


ThreatLevel Enumeration for the different severities of the situation.


15

Attributes

collisionImminent State when collision with pedestrian is imminent, brakes are fully engaged.

safeDistance State when the pedestrian is a safe distance from the vehicle, the most efficient deceleration

will be calculated and applied.

noPedestrian State when there is no pedestrian detected. No deceleration is applied.

Relationships Associated with the CollisionAvoidanceSystem.


Vehicle The vehicle moving autonomously and avoiding pedestrians.

Attributes

width: float Constant width of the vehicle, defined as 2 m.

steadyStateSpeed : float The speed the vehicle travels at when a pedestrian is not detected, defined as 13.9 m/s.

Operations

getWidth (): float Gets and returns the attribute width.

getSteadyStateSpeed (): float Gets and returns the attribute steadyStateSpeed.

Relationships Inherited from the MovingActor class, and aggregates the Sensor,

CollisionAvoidanceSystem, Accelerator, and BrakeByWireSystem.

Figure 5 is a sequence diagram depicting the detection and avoidance of a pedestrian. Sequence diagrams depict scenarios that capture the interaction between objects. In a sequence diagram, objects are denoted by boxes. Objects are labeled with their instance name and with their class, separated by a colon. Instance names are optional. Objects have lifelines, denoted by dotted vertical lines. As time elapses, we travel down objects’ lifelines. When one object calls a function of a second object, it is denoted by a solid arrow pointing from the first object to the second object labelled with the function’s name. Function calls may also have a guard, which is a condition that must be met for the call to be made. Guards are denoted as some condition between “[“ and “]” above the function name. Responses to function calls are denoted as dotted arrows that point from sending object to receiving object. Text above the response indicates the value of the response.


16

Figure 5 begins with the vehicle starting and sending the onStart() message to the ACPA system. When the APCA system starts, it tells the pedestrian sensor to begin sending it packets. The pedestrian sensor runs sendPedestrian(). In order to get pedestrian information to send, the pedestrian sensor gets the pedestrian’s diameter, velocity, and x and y coordinates from the pedestrian object. The scan ends. The ACPA system then inspects the pedestrian object to determine whether a pedestrian is detected. In this scenario, the pedestrian is detected. The ACPA system responds by getting the vehicle’s information and setting the threat level based on the vehicle and pedestrian information. In this scenario, the threat level is determined to be collisionImminent. The APCA system responds by sending a signal to the BBW system to decelerate to 0 kph. Once the vehicle is stopped, the pedestrian sensor scans again for the pedestrian. The ACPA system inspects the pedestrian object and determines that the pedestrian is no longer detected. The ACPA system sets the threat level to noPedestrian and signals the accelerator to accelerate back to steady state speed, 13.9 m/s.


17

Figure 5: The sequence diagram representing a sample scenario run by the APCA system

Figure 6 is a state diagram of the APCA system. State diagrams depict sets of conditions called states that the system may be configured. States are represented by boxes. All states have a name. States may also have an action that is performed upon entering the state, denoted as “do / ” followed by the action. States are connected by transitions. Transitions are labeled with events that triggers the transition. Transitions may also have a guard, which is a condition that must be met for the transition to occur. Guards are denoted as some condition between “[“ and “]”. Transitions may also have an action that is performed during the transition, denoted as “do / ” followed by the action. The initial state is denoted by a circled black dot.


18

Figure 6 begins with the APCA system being turned on. Once on, the system is in the No Pedestrian state. When the No Pedestrian state is entered, the ACPA system sends a signal to the accelerator to accelerate to the steady state velocity. When the APCA system checks for and finds a pedestrian, it transitions to the Pedestrian Detected state and sets the threat level based on the probability of a collision. The APCA system then transitions to either the Do Nothing state if the computed threat level is safe or the Avoid Pedestrian state when a collision is probable. If the APCA system enters the Avoid Pedestrian state, then the system runs the avoidPedestrian() function, which sends a brake signal to the BBW system. From the Do Nothing and Avoid Pedestrian states we transition to the No Pedestrian state when we no longer detect a pedestrian.

Figure 6: APCA system state diagram.

5 Prototype The prototype is a pedestrian scenario simulator. Users interact with the simulator by selecting one of 10 scenarios and running the scenario. The prototype displays an animation of the collision scenario and a graph that depicts the time lost while avoiding the pedestrian. Selection occurs in two stages. Users first select a Pedestrian Motion Scenario, which may describe the pedestrian as “Moving then stopped,” “Static then moving,” or “Static.” When a Pedestrian Motion Scenario is selected, users are given a table of scenario numbers and their statistics, as well as a second dropdown menu. The second dropdown menu allows users to select a specific scenario from the table. Then users may click the “Run” button to start the simulation.

5.1 How to Run PrototypeThe prototype requires a modern web browser with JavaScript enabled to run. It can be accessed at the following URL: http://cse.msu.edu/~slenkeri/prototype/


19

5.2 Sample ScenariosThe user begins by selecting a Pedestrian Motion Scenario. For our example, the user selects “Moving then Stopped.” This is depicted in Figure 7.

Figure 7: Pedestrian Motion Scenario type selection.

The user then selects a specific scenario from the scenarios table. Figure 8 depicts the user selecting Pedestrian Motion Scenario 2. In this scenario the pedestrian is “Moving then Stopped,” their initial position is at -7 m, their end position is at 0 m, their initial speed is 2.78 m/s, and their final speed is 0 m/s. The vehicle's speed is assumed 13.9 m/s (50.0 kph) for all scenarios.

Figure 8: Specific Pedestrian Motion Scenario selection and the Pedestrian Motion Scenario table for Moving then Stopped scenarios.

The user may optionally activate Failsafe Mode by clicking the appropriate checkbox. When the simulator is run with Failsafe Mode active, the vehicle’s braking response time increases from 200 ms to 900 ms. Figure 9 depicts the activation of Failsafe Mode.

Figure 9: Failsafe Mode is active.

When the user clicks the “Run” button, the simulator runs the scenario using the current PCA algorithm. For this example, the algorithm simply applies the maximum deceleration of 6.87 m/s^2. When the simulation runs, a pane appears on the right side of the interface. Inside the pane is an animation of the pedestrian and vehicle. This pane is depicted on the right side of Figure 10.

Figure 10: The full pedestrian scenario simulator interface.

6 References. 1. D. Agnew, “Functional algorithm for automated pedestrian collision avoidance system,”

Continental Automotive Systems, 2013. http://www.cse.msu.edu/~cse435/Projects/F2013/ProjectDescriptions/APCA-2013.pdf

2. Team STOP, [online] 2013, http://cse.msu.edu/~cse435/Projects/F2013/Groups/APCA1/web/


20

7 Point of ContactFor further information regarding this document and project, please contact Professor Betty H.C. Cheng at Michigan State University (chengb at cse.msu.edu). All materials in this document have been sanitized for proprietary data. The students and the instructor gratefully acknowledge the participation of our industrial collaborators.

Questions for clarification:What cases will cause the fail safe mode to be active?


srs draft v1.docx - michigan state university · web viewtemplate based on ieee std 830-1998 for...

Documents