Active Park Assist - MSU CSE

Software Requirements Specification (SRS)
Active Park Assist
Authors: David Kircos, Neha Gupta, Derrick Dunville, Anthony Laurain,
Shane McCloskey
Customer: Eileen Davidson, Ford Motor Company
Instructor: Dr. Betty Cheng
1 Introduction
This is the Software Requirements Specification for the Ford Active Park Assist
system that will be used in Fords luxury brand Lincoln. This document provides a
detailed description of what the system’s requirements are, what the system’s functions
are and what characteristics the system has. The Active Park Assist system is further
described by a series of diagrams: a Domain, Use Case, State, and Sequence Diagram.
Sample scenarios are outlined to visualize the system behavior during use.
1.1
Purpose
The purpose of this document is to define a consensus for the Active Park Assist
system between Ford and the engineers that will be building the system. This is to ensure
the system is built to the proper set of requirements.
1.2
Scope
The scope of this document is the Active Park Assist system itself and how this
system interacts with the other systems in the vehicle. The system proposed in this
document will park the vehicle with as little user interaction as possible. The system will
be able to actively park the vehicle in either a parallel or perpendicular parking
arrangement. This will help reduce the user’s trouble maneuvering the vehicle while
parking, especially for users who have trouble parallel parking on their own.
To use the Active Park Assist system the user must activate the system then select
if they want to park in parallel or perpendicular. Once the drive confirms the spot they
want to park in the software system will control the vehicle’s acceleration, breaking,
transmission, and steering only while in the Active Park Assist state. To monitor the
surroundings of the vehicle, the system will make use of ultrasonic and visual light
sensors, which continually feed data to the system. The user can interrupt the parking
sequence by tapping the break or torqueing the steering wheel. If the parking maneuver is
successfully completed, the user will be notified and the vehicle will be put in park.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
1.3
Definitions, acronyms, and abbreviations
APA
HMI
Customer
User
Parking Space
PCS
PMS
BCS
SCS
VPS
1.4
Active Park Assist. The System that controls the parking
maneuver.
Human Machine Interface. The touch screen interface
located in the vehicle that the user uses to interact with the
APA.
The Ford Motor Company.
The user of the vehicle.
An available parking space that is 1.2 times the length of
the vehicle.
Park Control Subsystem. Masters the Active Park Assist
feature. It accepts the customer input from the HMI
subsystem, calculates the vehicle trajectory based on
information from the Vehicle Position Subsystem, and
issues commands to the other subsystems.
Powertrain Management Subsystem. Accepts inputs from
the PCS to accelerate the vehicle.
Brake Control Subsystem. Accepts inputs from the PCS to
brake the vehicle in order to meet the required trajectory.
Steering Control Subsystem. Accepts inputs from the PCS
to steer the vehicle in order to meet the required trajectory.
Vehicle Position Subsystem. Processes data from the
vehicle’s cameras / radar in order to identify parking space
and verify vehicle position throughout the duration of a
parking event.
Organization
This document has seven sections: (1) An introduction that lays out the purpose
and scope of the APA system. (2) An overall description of the system. (3) The specific
requirements of the system. (4) Models of the system. (5) A demonstration prototype of
the system. (6) References to information included from other sources. (7) Point of
contact.
2 Overall Description
This section includes six subsections: (1) A description of the APA system that
provides a product perspective. (2) An outline of the major functions of the system. (3) A
characterization of a user of the system. (4) A description of all system constraints. (5) A
discussion of assumptions and dependencies regarding the system. (6) Commentary on
requirements that are outside the scope of this project.
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.1
Product Perspective
The APA system is an autonomous driving feature. Activated by the user of the
vehicle, to facilitate the process of maneuvering a vehicle into a parallel or perpendicular
parking space. Parking vehicle can be a stressful and difficult task for any. By taking
advantage of technology already available on the vehicle to support other safety features,
this additional feature can implemented allowing the user to automatically park with
minimal interaction. The APA system is specifically designed to eliminate this stress as
well as significantly reducing the risk of vehicle collision during a parking maneuver.
The APA system is built on top of numerous pre-existing subsystems already in
the vehicle. The APA system will utilize the HMI, PCS, VPS, BCS, PMS, SCS, and onboard cameras and radar sensors. The APA system does not require any additional
hardware to be installed in the vehicle. It only requires additional software be installed in
order to implement the functionality of the desired system.
Figure 1 is a data flow diagram that shows how the systems functional data flows
through the various subsystem processes to achieve the desired system behavior.
Figure 1.
APA data flow diagram. Shows how functional data flows through processes
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)
User inputs are selected using the HMI. These user inputs are forwarded to the
PCS, which then returns feedback data to the HMI to update the user about the state of
the system. The VPS processes incoming data from the camera and radar sensors. This
processed sensor data is gathered by the PCS and is used to calculate the optimal vehicle
path for executing a parking maneuver. The PCS uses the calculated path data in order to
determine the command data sent to the PMS, SCS, and BCS. The PMS, SCS, and BCS
process the incoming command data, execute the desired subsystem commands and
return feedback to the PCS. The feedback data from the PMS, SCS, and PCS is then
again processes by the PCS and used to again update the user about the state of the
system.
2.2
Product Functions
The APA system will provide the following functionality, as requested in the
initial customer specification document.









The user shall activate the system through the HMI.
The system shall prompt the user to choose a parking orientation using the HMI.
The system shall find available spaces using ultrasonic sensors and cameras.
The system shall display available parking space to the user via the HMI.
The system shall prompt the user to select a desired parking space using the HMI.
The system shall maneuver the vehicle into the selected parking space.
During a parking maneuver, the system shall halt if an obstacle is detected.
The system shall abort if the user engages the brakes or turns the steering wheel.
The system shall notify the user when the parking maneuver is completed.
A high-level goals diagram is provided in figure 2 that shows how these
functional goals of the system are related to each other.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 2.
High-level Goals Diagram. Looks at the APA system’s goals.
Safely and efficiently parking the vehicle is obtained primarily through the use of
cameras and ultrasonic sensors on the exterior of the vehicle. The use of cameras and
ultrasonic sensors allows the system to identify available parking spaces. When available
spaces are identified they are displayed to the user via the HMI, which prompts the user
to select a desired space. Once selected, the vehicle will maneuver itself into the desired
space while identifying obstructions that appear in the calculated maneuver path as well
as indentifying the occurrence of a user abort action. Should an obstruction become
present in the maneuver path or a user abort action occurs the system will abort the
maneuver and display an alert message using the HMI for the user to interpret.
2.3
User Characteristics
The user has to do very little to operate this system, general expertise in dealing
with similar systems is not needed. The user simply has to select the proper option to
activate the system and verify selection that the system presents to the user. Basic
driving skills as well as basic parking skills are required to use this feature.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
2.4
Constraints
Systems used during the parking maneuver that are outside the APA system are
required to be functional in order for the APA system to be activated by the user. These
include the PCS, the PMS, the HMI Subsystem, the BCS, the SCS and the VPS. The
APA system detects failures from all sensor inputs. For example, cameras and ultrasonic
sensors have fault detection, and APA cannot operate if there are faults in those sensors.
If a tire were to blow out, then the system would abort due to warnings from the tire
pressure sensors. Since the system must shift gears to be able to operate, the system is
constrained to existing in vehicles with shift by wire transmissions only. Additionally, the
system will not operate on vehicles with a trailer or other heavy load attached in the back.
This would be detected before the user can activate it by an algorithm dependent on
weight. The system will not be useable on grades greater then 3% and is not available on
manual transmissions.
2.5
Assumptions and Dependencies
We assume that the software can detect and filter all selections on the HMI that
are inputted by the user, and will ensure that they are not a fault of the HMI system, or a
malicious third party.
We assume that the hardware for the sensor inputs can detect failures because of
causes discussed in 2.4. If any of the sensor inputs detect a failure, then the APA system
cannot operate as well.
The system will only operate if the user does select options when prompted to
after activating the APA system. If the user doesn't select parallel or perpendicular
parking, the user will not be able to get the next screen, so they will be unable to use the
system. He must make a mode selection. Also, until the user approves a parking space
option provided to them, the system will not begin the parking maneuver. It would
indefinitely continue to search for a spot if they do not select a parking space.
2.6
Approportioning of Requirements
All originally specified requirements have been determined to be within scope of
this version of the project at this time.
3 Specific Requirements
The following requirements are determined as specifications that are going to be
implemented in this version of the project.
3.1
Start APA system based on user selection on HMI.
3.1.1 Ask a user to specify parallel or perpendicular parking.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Use ultrasonic sensors and cameras to search for available parking
spaces while a user drives at a speed less than 5 miles per hour.
3.2 Identify parking space(s).
3.2.1 Find available spaces using ultrasonic sensors.
3.2.2 Identify spots that are 1.2 times the size of the vehicle as feasible
parking locations.
3.2.3 Ask customer to verify selection of spot on HMI and put vehicle in
neutral and ask user to keep foot on brake.
3.3 Maneuver the vehicle into the parking space.
3.3.1 Choose forward or reverse depending on parallel or perpendicular
parking.
3.3.2 Accelerate/brake/steer vehicle into spot.
3.3.3 HMI display shows diagram of the current course the vehicle has been
traveling in.
3.3.4 System aborts when user steps on the brake, jerks the wheel, or collides
with anything.
3.3.5 Stop and notify user that APA has been aborted through HMI.
3.3.5.1 The system shifts the gear back into neutral when an object is
detected, and full control of the vehicle is returned to the user.
3.3.5.2 The user is asked via the HMI if they want to resume
operation.
3.3.5.3 If a system is accidentally aborted and reactivated, the system
will resume operation and try to reinitiate park when
reactivated and given approval.
3.3.5.4 Assume stopping time is eight inches from the time the brake
is applied by the user of the vehicle.
3.3.6 If an obstacle moves into the path of the vehicle, then the system will
detect this using the ultrasonic sensors and cameras.
3.3.6.1 It would not abort, but would pause movement using the
Brake Control Subsystem. It would resume once the obstacle
moves from its path.
3.3.6.2 It will pause and resume once per parking maneuver. If
another obstacle is detected, the system will abort as described
in 3.3.4.
3.3.6.3 If a child or dog jumps out of vehicle open window during
process, system should detect new objects in the path of the
vehicle as an obstacle and either pause and resume, or abort,
depending on whether it is the first obstacle during the
maneuver.
3.3.7 Complete parking within time frame of seventy five seconds. If
maneuver is taking too long, the system will abort and return control to
user.
3.3 At completion of parking, notify user that APA has been completed.
3.4.1 Shift the transmission to park.
3.4.2 Return full control of vehicle to user.
3.4.3 User selects done to exit the APA system.
3.1.2
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
4 Modeling Requirements
This next section is dedicated to explaining to the bridge between the application
domain and the machine domain of the APA system. There will be multiple figures
modeling the APA system including a use case diagram, domain model diagram,
sequence diagram, and the state diagram.
Figure 3 below is the use case diagram key. It describes the different notation used
in the use case diagram of the APA system.
Figure 3.
Use Case Diagram Key. Displays the notation used in a use case diagram.
Figure 4 below is the use case diagram for the APA system. This diagram
describes the different interactions between the user and the system and the resulting
effects that they have on each other.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
// the APA actor needs to be outside the domain
Figure 4.
Use case diagram. Displays the high level behavior of the APA system.
This diagram is meant to provide information about the different uses cases that
will arise when using the APA system. In this system the only actor that will interact with
the APA is the user of the vehicle. The user is the one who must activate the system,
choose a parking orientation and verify the parking space. All of these interactions and
information are shown through the vehicle’s HMI. The user also maintains the ability to
disable the APA at any time during the process. Below are the corresponding use cases
for figure 4.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Use Case:
Select Spot Type
Actors:
User (initiator), Vehicle
Description:
After turning on the APA system, the user must select what type of
parking space the system should search for (parallel or perpendicular).
Type:
Primary and essential
Includes:
N/A
Extends:
N/A
Cross-refs:
Requirement 3.1.2
Use cases:
N/A
Use Case:
Disable APA
Actors:
User (initiator), vehicle
Description:
The user aborts the park assist while it is in progress by pressing on the
brake or gas, or by moving the steering wheel.
Type:
Primary and essential
Includes:
HMI notifies user
Extends:
N/A
Cross-refs:
Requirement 3.3.4
Use cases:
N/A
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Use Case:
Verify Spot
Actors:
Vehicle (initiator), User
Description:
The system scans for an adequate parking space and displays said space to
the user through the HMI. The user must then verify that they wish to park
there, or have the system find a new spot.
Type:
Primary and essential
Includes:
N/A
Extends:
N/A
Cross-refs:
Requirement 3.2.3
Use cases:
N/A
Use Case:
HMI Notifies User
Actors:
Vehicle (initiator), User
Description:
APA notifies the user of any change or verification needed through the
HMI.
Type:
Primary and essential
Includes:
N/A
Extends:
N/A
Cross-refs:
Requirements 3.1.4, 3.3.4 and 3.4.1
Use cases:
Disable APA and Parking Done.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Use Case:
Parking Done
Actors:
Vehicle (initiator)
Description:
The parking process is completed and APA notifies the user.
Type:
Primary
Includes:
HMI Notifies User
Extends:
N/A
Cross-refs:
Requirements 3.1.4
Use cases:
N/A
Use Case:
Locate Spot
Actors:
Vehicle (initiator)
Description:
APA uses the onboard sensors and cameras to locate an available spot that
is at least 1.2 times the size of the vehicle.
Type:
Primary and essential
Includes:
Monitor Location
Extends:
N/A
Cross-refs:
Requirement 3.2.1 and 3.2.2
Use cases:
N/A
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Use Case:
Monitor Location
Actors:
Vehicle (initiator)
Description:
APA uses the onboard sensors and cameras to constantly monitor its
location and the state of the objects around it. It does this to make sure that
nothing will interfere with the parking procedure before and during the
parking operation.
Type:
Primary and essential
Includes:
N/A
Extends:
N/A
Cross-refs:
Requirement 3.3.4, 3.4.1 and 3.5.1
Use cases:
Locate Spot and Detect Interfering Objects
Use Case:
Detect Interfering Objects
Actors:
Vehicle (initiator)
Description:
APA uses the onboard sensors and cameras to determine if any objects
move in the path of the vehicle that will interfere with the parking
maneuver once it is in process.
Type:
Primary and essential
Includes:
Monitor Location
Extends:
N/A
Cross-refs:
Requirement 3.3.4 and 3.4.1
Use cases:
N/A
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 5 below is the domain model key. It describes the different notation used
in the domain model of the APA system.
Figure 5.
Domain Model Key. Describes notation for domain model.
Figure 6 displays the domain model of the APA system. Its purpose is to model
the various classes with their attributes, operations, roles, and relationships.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 6.
Domain model of the APA system. Models objects, operations and relationships.
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)
As shown in figure 6, the APA system is headed by the PCS class; this class
accepts input from the HMI and then issues commands to its subsystems including the
PMS, BCS, and SCS classes based on the information the VPS sent to the PCS class.
The Subsystem class is an abstract class that is only responsible for accepting an input.
PMS, BCS, STS, and HMI classes are all derived from this class. The PMS class is
responsible for selecting the proper gear position and accelerating the vehicle to the
proper speed. The BCS class is in charge of braking the vehicle and the SCS is in charge
of steering respectively.
The HMI class accepts input from the User class that has the ability to active
APA, select the parking space orientation, verify the space selection as well as abort the
maneuver. Throughout the APA maneuver, the HMI interface displays the process to the
user as well as alerts the user with warnings if necessary. The HMI also displays
information from the vehicle’s cameras throughout the maneuver. The VPS gathers
information from the cameras and ultrasonic sensors to identify a parking space as well as
identify foreign objects during the maneuver. This information is then sent to the master
PCS class to calculate the trajectory of the vehicle to complete the APA process.
Each of the classes and their functions are described below in the Domain Model
Data Dictionary.
Domain Model Data Dictionary
Element Name
Description
Brake Control
Accept input from the PCS to make
sure vehicle meets the required
trajectory.
Operations
BrakeVehicle()
A void function to properly brake the
vehicle when needed as well as brake
when an obstacle is detected.
Relationships This class accepts input form the PCS and responds accordingly.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Element Name
Description
Camera
A class representing a single camera
mounted on the vehicle, used to identify a
parking space.
Attributes
maxRange: Float = 70.0
The maximum range of each camera is
70 meters.
ScanForSpace()
A void function that scans for a space and
surveys the sounding area.
Operations
Relationshi
ps
This class sends its gathered information to the VPS to identify a parking
space as well as identify a foreign object. This class also sends information
to the HMI to display the process of APA. There are front and rear camera
class instances derived from this class.
Element Name
Description
HMI
The HMI is what the user interacts with,
the HMI displays information to the user
throughout the APA process.
Operations
DisplayProcess()
A void function that displays the APA
process to the user, which includes the
user activating the APA functionality,
selecting the spot, and displaying
information from the cameras as the
APA maneuver is in progress.
AlertDriver()
A void function that alerts that user if
the APA process has been aborted.
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)
ActivateAPA()
A void function in which the user
actives the APA functionality through
the HMI.
VerifySpace()
A void function that has the user verify
the space that the APA system has
identified.
SelectSpaceType()
A void function in which the user selects
either parallel or perpendicular parking.
SelectDone()
A void function in which the user
verifies that they recognize the parking
sequence as having been successfully
completed
Relationships This class accepts input from the user class as well as displaying camera
information.
Element Name
Description
Park Control System
This class masters the APA process, it
accepts input from the HMI, calculates
the vehicle trajectory based on
information from the VPS, and issues
commands to other subsystems.
Attributes
vehicleSize: Float
This size of the vehicle
maxGrade: Float = 3.0
The max grade the vehicle can
maneuver on during the APA process.
GetInput()
A void function that gets an input from
a subsystem and processes that
information.
Operations
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)
CalculateTrajectory()
A void function that uses the
information from the VPS to properly
maneuver the vehicle into the desired
parking space.
IssueCommand()
A void function that sends a command
down to a subsystem of the APA system.
Abort()
A void function that aborts the APA
process if there is a foreign object in the
vehicle trajectory or if the user manually
aborts.
DetectFault():
returnBool
A check on all of the other subsystems in
the vehicle to makes sure everything is
working properly, returns true if there a
fault in the system.
ProcessComplete():
returnBool
A check with the VPS that the vehicle is
successfully within the selected space.
Returns true if completed parking, false
if not.
Pause()
When an obstacle is detected, the system
pauses until the obstacle moves or until
the user selects to continue parking.
BeginParking()
A void function that signals to the VPS
to begin parking the vehicle, which
occurs after the parking space is selected
on the HMI.
Relationships This is the main class of this system so it gathers information from all
classes, in particular it communicates with the VPS as well as the
Subsystem class that has the PMS, BCS, SCS and the HMI classes
derived from it.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Element Name
Description
Powertrain Management
This class accepts input from the PCS to
accelerate the vehicle as well as select
the proper gear setting.
Operations
SelectGearPosition()
A void function that selects the proper
gear position for the APA maneuver.
AccelerateVehicle()
A void function that accelerates the
vehicle properly to complete the APA
maneuver.
Relationships This class accepts an input so it is derived from the Subsystem class that
communicates with the overall PCS class.
Element Name
Description
Radar
The ultrasonic sensor class is used to
measure the available spaces between
vehicles.
Attributes
maxSpaceSize: Float = 1.2 *
vehicleSize
The max space size the vehicle can fit
into is 1.2 times the size of the vehicle.
maxRange: Float = 6.0
The range the sensors can cover.
MeasureAvailableSpace()
A void function that measures
available space between vehicles, this
information is sent up to the VPS class.
Operations
Relationships This class sends the information it gathers up to the VPS for processing.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Element Name
Description
Steering Control
This class accepts input from the PCS
and handles steering the vehicle properly
to meet the required trajectory.
Operations
SteerVehicle()
A void function that steers the vehicle
properly to meet the required trajectory.
Relationships This class accepts an input so it is derived from the Subsystem class that
communicates with the overall PCS class.
Element Name
Description
Subsystem
An abstract class that is only
responsible for accepting input.
Operations
AcceptInput(int inputType)
A void function that takes in an input
type, either PCS input or User input.
Relationships This is the base class that accepts an input from either the PCS or the
User. This class also communicates with the PCS.
Element Name
Description
User
A class that represents the user of the
APA system.
Operations
Abort()
The APA maneuver will abort if the user
engages the brake, engages the steering
wheel, or manually selects abort on the
HMI. This is a void function.
Relationships This class controls the HMI class.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Element Name
Description
Vehicle Position Subsystem
This subsystem handles the processing
of the information from the cameras and
ultrasonic sensors to get the vehicles
position as well as identifying parking
space and foreign objects.
Operations
ProcessCameraRadarData()
A void function that process the data
from the cameras and radars.
IdentifyParkingSpot()
Uses the data processed from the
cameras and radars to identify a
parking space.
IdentifyObject()
Uses the data processed from cameras
and radars to detect a foreign object that
will obstruct the APA maneuver.
Relationships This class gathers information from the Camera and Radar classes,
processes it and then sends that information to the main PCS class.
Sequence diagrams are used to show the sequencing of interactions between the objects
used in the Domain Model. Moving from top to bottom, the links between the objects are
in order of occurrence. The following scenario, Figure 7, depicts a flawless, uninterrupted
parking procedure using APA.
Sequence Diagram Key
A message issued between two objects
An object, corresponding to the objects in the Domain
Model
A return message passed back to an object that issued a
message
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 7.
Sequence Diagram: Normal Operation.
The procedure for a normal parking sequence, with no issues or interrupts, begins with
the user activating the APA. After they are prompted to select a space type and select
one, then the HMI displays parking spots identified by the VPS, and prompts the user to
verify spaces. After the user verifies a space, the HMI prompts the PCS to being parking
and displays the process on the HMI. Once the process is complete, as determined by the
PCS, the HMI informs the user, and the user can verify that it is complete by touching the
screen.
However, the parking would not be guaranteed to operate smoothly from start to finish.
One situation where the normal sequence would be interrupted is when the user interrupts
the process. This could occur by the user pressing the brakes during the parking or
moving the wheel. This scenario is depicted in Figure 8.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 8.
Sequence Diagram: User Interrupt.
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)
A second situation where the parking would not operate as normal from start to finish is
when the system interrupts the process, which would occur because it detects an obstacle
in the path of the maneuver. This situation is depicted in Figure 9.
Figure 9.
Sequence Diagram: System Interrupt.
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)
Step 1, the user activating the APA, to step 2.1.1.1, when the HMI triggers the parking
sequence, occur as they do in Figure 7. However, when the VPS detects an obstacle, it
pauses and sends a Pause message to the HMI. The HMI alerts the driver. The driver can
select to continue, or the system would continue itself when it detects that the obstacle
has moved. Then, the process would continue parking again through the BeginParking
method and the parking sequence would complete when the user selects Done on the
HMI as normal.
A state diagram also depicts a series of messages and the behavior of a system. However,
the state diagram depicts the behavior of the objects ,and the events and actions occurring
for the objects.
State Diagram
A state, which is one stage of the object’s
existence. The name of the state is above
the horizontal line and the activities done in
that state are indicated below the horizontal
line.
A transition. The name of the event causing
the transition is on the label for the arrow,
and if an action is performed during the
transition, it is on the label following a ‘/’
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 10.
State Machine Diagram.
When the vehicle is turned on, then the APA is idle. When the user selects the APA
selection menu, then it remains on the menu and cannot begin finding parking spaces
until the user has selected a parking space type. Then, the APA moves into the state of
finding an available space, where they are searching for a space while processing camera
radar data and sending this location to the HMI display. When the user selects a space,
the APA stops finding an available space and moves into the parking state. During the
parking state, the VPS, Cameras and Radars, and PCS, park the vehicle. When the
process is complete and the user selects done, then the system reaches its final state.
Alternatively, the user could interrupt and this would abort the system and exit. If the
system is paused because an obstacle is detected, then it moves into the paused state.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
5 Prototype
This section dedicated to the prototype, this includes describing the prototype and
its functionality, explaining how to run it, as well as laying out sample scenarios.
The APA prototype will start at the HMI home screen that displays the Active
Park Assist option. Once the user selects it, they will then be prompted to select a parking
orientation that is either parallel or perpendicular. From there, the HMI will prompt the
user to verify the selected space. Then information from the cameras will be used to
display an overhead view of the APA process. Information will also be displayed on
screen to tell the user to not touch the gas, brake, or steering wheel. If the user does any
of those three things, the APA process will abort and the abort screen will display on the
HMI, the user will be able to reinitiate the APA process from said screen. Once the APA
maneuver has completed, the HMI will display a success message, from there the HMI
will return to its original home screen.
Figure 11.
5.1
Prototype Screenshot
How to Run Prototype
All that is needed to run the prototype is a web browser with HTML5 Canvas
support as well as an Internet connection.
5.2
Sample Scenarios
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
5.2.1 Normal Sequence. This is a sequence that involves no system
interruptions and simply parks the vehicle.
Figure 12.
State Machine Diagram APA procedure starts at the MyFord Touch home screen. The
user selects “Active Park Assist”
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 12.1
User selects the type of parking orientation desired. APA system shows a different
interface depending on the user selection.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 12.2
The user will pull forward and when the front of the vehicle passes an available parking
space the system will allow the user to select the space for active parking.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 12.3
HMI shows the parking progress on screen. The user can halt the process by tapping the
break or by torqueing the steering wheel.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 12.4
Once the parking sequence is completed the user is notified and can return to the HMI
main menu.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
5.2.2. User Interrupt or Obstacle Interrupt.
Figure 13.
While the APA system has control of the vehicle there are two reasons that the system
will stop. First, if the user attempts to take control of the vehicle the APA system will
abort. Second, if an obstacle is detected the system will pause. If the object moves out of
the way within 75 seconds from the start of parking sequence the system will resume on
its own.
6 References
1.
D. Thakore and S. Biswas, “Routing with Persistent Link Modeling in Intermittently
Connected Wireless Networks,” Proceedings of IEEE Military Communication, Atlantic
City, October 2005.
2.
http://www.cse.msu.edu/~cse435/Projects/F2014/ProjectDescriptions/Ford-APA.pdf
7 Point of Contact
For further information regarding this document and project, please contact Prof. Betty
H.C. Cheng at Michigan State University (chengb at cse.msu.edu). All materials in this
document have been sanitized for proprietary data. The students and the instructor
gratefully acknowledge the participation of our industrial collaborators.
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)