Software Requirements Specification (SRS)

Project Active Park Assist 2

Authors: Joseph Reeder, Ethan Ettema, Ryan Boyce, Kenneth Massie,

Stephanie Brown

Customer: Ford Motor Company

Instructor: Dr. Betty Cheng

Introduction

This SRS will cover the Active Park Assist feature that will be in Ford’s new
Lincoln lines. The purpose, constraints, requirements, and prototyping will
all be covered in this document, along with models for the system’s
operation.

1.1 Purpose

This document’s purpose is to provide a detailed description of the Active

Park Assist system for Ford Motor Company. Throughout the document, the
purpose and features of the system, the user-interface of the system, how the
system will respond to various scenarios, the system constraints, the design
assumptions and dependencies, and finally the system requirements will all
be presented. This document is intended for both Ford Motor Company and
the system developers, and will be proposed to Ford Motor Company for
their approval.
1.2 Scope

The software system proposed is an active park assist system for Ford Motor
Company. This system will be designed to assist drivers of Ford vehicles in
parking the vehicle by allowing the driver to choose a parking spot, and
automating nearly all of the parking process. By maneuvering the vehicle
using various sensors, the braking system, the acceleration system, and the
steering system, the active park assist system aims to reduce collisions that
might otherwise occur from manual parking, while relieving stress of the
driver.

More specifically, this system will present the driver with the option to park
in a spot either parallel or perpendicular to the vehicle, and will also search
for an available spot. Once an available spot is detected, the system will
require the driver to confirm the spot. Once confirmed, the system will take
complete control over parking the vehicle, notifying the driver once the
parking process has been successfully completed (or aborted) and will
disengage from controlling the various vehicle subsystems.

1.3 Definitions, Acronyms, and Abbreviations

In the table below, various acronyms, abbreviations, and phrases that are
used throughout this document are defined.

Term Definition
Acceleration System Vehicle system which controls the acceleration of
the vehicle vis the vehicle’s engine
Active Park Assist The name of the system
(APA)
Vehicle subsystem which controls the deceleration
Braking Subsystem
of the vehicle via the vehicle’s brakes
Client Ford Motor Company
Customer See client
Person operating the vehicle equipped with the APA
Driver
system
Human Machine
Interface between the system and the driver
Interface (HMI)

MPH Miles per hour

 Parking in a spot parallel to a line from the front to
Parallel Parking
the rear of the vehicle

Subsystem of the vehicle which controls the

Park Control Subsystem
automated parking process of the vehicle

Perpendicular Parking Parking in a spot perpendicular to a line running

from the front to the rear of the vehicle

Ultrasonic sensors on all sides of the vehicle, and

Sensors visual sensors (cameras) on the front and rear of the
vehicle
Steering Control Subsystem of the vehicle which controls the steering
Subsystem of the front wheels
User See driver
Subsystem of the vehicle which utilizes sensors to
Vehicle Position recognize objects surrounding the vehicle, available
Subsystem space between said objects, and threat of collision
with them.

1.4 Organization

The next section is the Overall Description section, which gives an overview
of the product functionality. It describes the system perspective, its
functions, characteristics, and finally constraints. It finishes by discussing
the assumptions made during design, the dependencies that the system was
designed upon, and a proportioning of the requirements.

The third section is the Requirements Specification section, and is written

primarily for the developers. It describes the details of the functionality of
the product from a technical perspective.

The fourth section is the Modeling Specification section that presents both a
Use-Case diagram of the system, as well as a Conceptual Domain Model of
the system.

The final section describes a prototype of the system demonstrating the user-
interface for the system.
All sections of the document describe the same software system, but are
intended for different audiences and thus use different language. Sections
one, two, and five are directed towards both the client as well as the
developers, whereas sections three through five are specifically directed
towards the developers.

2 Overall Description

The intent of this section is to give an overview of the APA system. This
overview will include the functionality of the system as well as the
expectations of those who use it. Constraints, assumptions, and
dependencies for the system will be explained, followed by requirements of
the system that are deemed to be beyond the scope of this project.

2.1 Product Perspective

This system will be in place to help coordinate several other subsystems

within the vehicle to perform its functions. As showen in Figure 1 below, the
APA system will include the HMI subsystem and will interact with the park
control, brake, steering, and vehicle position subsystems. The vehicle
position system will include a network of peripheral cameras and sensors
that will aid in the system’s function as well.

The HMI will accept input from the user, provide visuals for any system
warnings, and display live video it receives from peripheral cameras. The
park control system will then use input acquired from HMI along with
information from the vehicle position system to calculate vehicle trajectory
and issue commands to the other subsystems.

The steering control, brake control, and power management systems will
receive input from the park control system necessary to perform the parking
trajectories calculated. The power management system will work to shift
gears and accelerate the vehicle while the brake system will be used to
decelerate the vehicle. Finally, the steering control system will be used to
maneuver the vehicle.
 APA System

Cameras / Sensors HMI

Feedback User Input System Feedback

Queries
Vehicle Position Park Control
Data

Key

Data Flow
Commands Feedback
Subsystem

Powertrain
Steering Control Brake Control
Management

Figure 1. Data Flow Diagram: Representing the flow of information throughout the APA
system

2.2 Product Functions

The primary function of the APA system is to assist the user with parking
safely and accurately. Upon activation, the user will be prompted for which
type of spot they wish to find, either parallel or perpendicular. To aid the
user in finding a spot for a given type of parking, the system will scan for
and present potential parking spaces to users through visuals on HMI while
the user is driving. The user will then interact with the HMI’s touchscreen to
select a desired spot.

Once a spot is verified, the system will calculate the optimal path to the spot
and activate the parking maneuver. Several subsystems will then work
together to shift gears, accelerate / decelerate, and steer the vehicle to follow
the calculated path. All throughout this process, sensors and cameras will be
active on the vehicle to help detect potential obstacles and to relay feedback
to the APA system.

The feedback that the APA system receives will constantly be monitored so
that the system can continue to make adjustments as necessary as the
maneuver continues. If an obstacle is detected, the system will stop the
vehicle to avoid collisions. Once the path is clear of obstacles, the user can
reactivate the parking process through the HMI and the system will complete
the parking maneuver and shift the car into park for the user. Upon
completion, the HMI will confirm to the user that the maneuver has been
successfully completed.

2.3 User Characteristics

The system is intended for use by the operator of the vehicle, therefore a
user of the system must be legally allowed to operate a vehicle according to
the laws applicable where they live. The simple touchscreen process of the
HMI will allow for users of varying backgrounds and skill levels to activate
and provide the inputs for system operation.

2.4 Constraints

For proper operation, the HMI software must be able to communicate with
the embedded systems of the subsystems involved. If the system is active for
an extended period, operations will be aborted and the user will have to
reinitiate the sequence. This causes the constraint that APA maneuvers be
performed within 75 seconds. To aid in preventing malicious use, the
systems will be using a seed and key system in which one module will
provide a question that another module must answer correctly to
communicate safely.
The system will be constrained to vehicles with shift by wire transmissions,
as it is a requirement of the system to shift gears for operation. As a safety
constraint, if any hardware component of any of the subsystems fails, the
user will not be able to activate the APA system. Another safety constraint is
that the system must avoid collision with obstacles that are detected via
sensors during parking maneuvers.

2.5 Assumptions and Dependencies

One assumption of a user is that they will be familiar with touchscreen

devices and interacting with them. It is also expected that the user be legally
allowed to drive (proper vision, age, etc.). Although the system has been
optimized to handle as many situations as possible, the ability to override the
system exists and therefore assumes the user to have the ability to practice
proper judgment given unique scenarios.

As the system is comprised of a number of subsystems, it will be assumed

that all of the subsystems perform their functionality as expected. Although
this system will detect failures and subsequently prevent itself from
operating, it is expected that hardware components of the subsystems have
their own failsafe procedures in place as well.

2.6 Approportioning of Requirements

Based on negotiations and time constraints, we are to assume the proper

functioning of subsystem components for the project at hand. These
considerations may be included in future releases time permitting.

3 Specific Requirements

This section describes the requirements of the system, and is divided into
four subsections. General requirements are requirements that must be met in
order for the system to operate. HMI requirements refer to specific features
that the HMI must have. APA requirements refer to requirements that must
be met by other subsystems. Safety requirements are overall requirements
that must be adhered to in order for the system to operate in a safe manner.

3.1 General

3.1.1. Sensors
 a. The vehicle must have ultrasonic sensors on both sides
b. The vehicle must also have cameras in the rear and front
c. The system must be able to use the ultrasonic sensors to
calculate the distance between two objects
3.1.2. System activation
a. The vehicle must be stopped in order to engage the system
b. Once engaged, the driver must then drive forward slowly
(around 2.5 mph) until a spot has been detected
c. Once detected, the driver must confirm via the HMI that the
detected spot is where they would like to park
d. In order to activate a parking maneuver, the driver must first
apply the brakes, and then shift into the neutral gear
3.1.3. The parking process must be carried out within 75 seconds, or else
the system will abort
3.1.4. The system must shift the vehicle into the neutral gear when the
process successfully completes
3.1.5. The system must deactivate, returning control to the customer,
when the process successfully completes
3.1.6. The system will be unavailable if a trailer is attached to the
vehicle

3.2 HMI

3.2.1. The customer must activate the Active Park Assist Feature
through the HMI
3.2.2. The customer must be able to select between parallel and
perpendicular parking
3.2.3. Parking selection
a. The HMI must display available parking spots
b. The customer must be able to verify which spot they would like to
choose to park in
3.2.4. The HMI must indicate to the customer the current state of the
parking process
a. The HMI will display the current trajectory and progress along it
b. The HMI must indicate if the process was completed successfully
c. The HMI must indicate if the process was aborted
3.2.5. The HMI must display any warnings associated with system
failure or collisions
3.3 Active Park Assist System

3.3.1. The system must be able to take full control of the vehicle driving
capabilities
a. The system must be able to accelerate the vehicle
b. The system must not accelerate the vehicle to a speed greater than
or equal to 5mph
c. The system must be able to brake the vehicle
d. The system must be able to steer the vehicle
e. The vehicle must be able to shift the vehicle into reverse, forward
and neutral
3.3.2. Parking detection
a. While parallel parking, the system must be able to identify a
parking spot if it is 1.2 times the length of the vehicle
b. The system will remember previously detected parking spots and
trajectory if it was recently aborted so that it can resume if
required

3.4 Safety

3.4.1. The vehicle must be stopped in order to activate the system

3.4.2. The system should have a speed cap of 5 mph, and ignore when
the customer presses the accelerator
3.4.3. The system must have the ability to pause and abort
a. The customer must be able to abort the parking process by
applying the brake pedal
b. The customer may abort by turning the steering wheel
c. The customer may also abort by shifting the vehicle into park
d. If the customer aborts the process, then the system must shift the
car back to neutral
e. If one of the vehicle doors is opened, then the system should
pause and continue once the door has been closed again
3.4.4. The system must detect obstacles in the path of the vehicle
a. The system must be able to prevent the vehicle from hitting any
obstacles while in the parking process
b. If there is an object in its path, then the system will apply the
brakes until the customer either aborts or chooses to continue
c. Any collision will abort the system
3.4.5. The system must verify that the customer initiated the request
3.4.6. The system must detect faults in the system
 a. The system must be able to detect a single point failure of any
sensor
b. If a sensor is obstructed, the customer should be notified via the
HMI that the system cannot perform its job

4 Modeling Requirements

A use case diagram for the Active Park Assist system is shown in Figure 1.
In this diagram, the only actors who interact with the system are the driver of
the vehicle and any object that may obstruct the path of the vehicle. An
obstructing object only interact indirectly with the system in that, once they
are detected, the system notifies the driver of the obstacle and halts the
maneuver as noted in Section 3.4.4.

Apart from aborting the system via the steering wheel, brakes, or
accelerator, the driver can only interact with the system via the HMI. The
driver's options include activating the system and choosing the type of
parking maneuver, either perpendicular or parallel. The driver can then
verify a parking space, which is displayed on the HMI, as noted in Section
3.2.3. At any time, the driver may choose to deactivate the system.
Figure 2. Use case diagram displaying how the various subsystems of the Active Park Assist system interact given user
input

Figure 1 displays the various interactions between the subsystems once user
input has been given. This is also shown in Figure 2 to a greater extent.
Figure 2 depicts that the APA system is composed of six subsystems:
steering control, brake control, powertrain management, the HMI, and
vehicle positioning. The figure also shows that each vehicle may have an
APA system, and requires ultrasonic sensors and cameras. The table
immediately below Figure 2 further describes all of the elements within the
APA system.
Figure 3. Conceptual domain model depicting interactions between key elements of the system

Data Dictionary
Class
Name Driver
Description The person that gives the system commands via the HMI

Driver Relationships
Class Description
HMI The driver gives commands to the HMI.

Class
Name HMI
The main interface. It tells the park control subsystem which
Description operation to perform, and also displays information to the
driver.

HMI Operations
Name of Operation Description
turnOn() Activates the system.
turnOff() Deactivates the system.
verify(userInput : The driver must either confirm or deny and action
Boolean) with the system.
parallelPark() The driver has chosen to parallel park.
perpendicularPark() The driver has chosen to perpendicular park.
displayTrajectory() The HMI displays the current path of the vehicle.
displayWarning() Displays a message when an error occurs.
displaySuccess() Displays a message when a maneuver is completed.

HMI Relationships
Class Name Description
Driver Driver gives commands to the HMI.
The HMI gives commands to the Park Control
Park Control subsystem. It also receives commands from this
subsystem.
The HMI displays imaging data from the Vehicle
Vehicle Position
Position subsystem.

Class
Name Park Control
The main subsystem. It calculates vehicle trajectory and
Description
commands many of the other subsystems.

Park Control Operations

Name of Operation Description
The system attempts to perform a parallel park
parallelPark()
maneuver.
The system attempts to perform a perpendicular park
perpendicularPark()
maneuver.
Using information from the vehicle position
calculateTrajectory() subsystem, calculates the best path into the parking
spot.
obstacleDetected() Stops the vehicle when an obstacle has been detected.

Park Control Relationships

Class Name Description
The Park Control subsystem receives commands from
HMI
the HMI. It also gives commands to the HMI.
Requests positioning data from the Vehicle Position
Vehicle Position
subsystem and calculates the trajectory based upon it.
 Gives commands to the Powertrain Management
Powertrain
subsystem. This includes shifting gears, accelerating,
Management
and decelerating.
Gives commands to the Brake Control subsystem.
Brake Control
This includes depressing and releasing the brakes.
Gives commands to the steering control, turning the
Steering Control
steering wheel.

Class
Name Vehicle Position
Takes in data from the cameras and ultrasonic sensors, then
Description
sends it to the Park Control subsystem.

Vehicle Position Operations

Name of Operation Description
Attempts to identify a space large enough for the
identifySpace()
vehicle to park in.
Confirms the position of the vehicle to the Park
verifyPosition()
Control subsystem.

Vehicle Position Relationships

Class Name Description
Supplies positioning information to the Park Control
Park Control
subsystem.
HMI Gives imaging data to the HMI.
Camera Receives environmental data from cameras.
Ultrasonic Sensor Receives environmental data from sensors.

Class
Name Powertrain Management
Description Controls the acceleration of the vehicle as well as gear shifts.

Powertrain Management Operations

Name of Operation Description
shiftGear() Shifts the gear into either reverse or neutral.
accelerate() Accelerates the vehicle.
decelerate() Decelerates the vehicle.
Powertrain Management Relationships
Class Name Description
Park Control Accepts commands from the Park Control subsystem.

Class
Name Brake Control
Description Controls the vehicle's brakes.

Brake Control Operations

Name of Operation Description
depressBrake() Brakes the vehicle.
releaseBrake() Releases the vehicle's brakes so it can move.

Brake Control Relationships

Class Name Description
Park Control Accepts commands from the Park Control subsystem.

Class
Name Steering Control
Description Controls the vehicle's steering.

Steering Attributes
Name of Attribute Description
An integer value that keeps track of the current
degreesRotation
rotation of the steering wheel.

Steering Operations
Name of Operation Description
turn(degrees : Integer) Turns the steering wheel the specified amount.

Steering Relationships
Class Name Description
Park Control Accepts commands from the Park Control subsystem.

Class
Name Camera
Description Takes in visual data from the vehicle's surroundings.
Camera Relationships
Class Name Description
Supplies environmental data to the Vehicle Position
Vehicle Position
subsystem.

Class
Name Ultrasonic Sensor
Description Takes in data from the vehicle's surroundings.

Ultrasonic Sensor Relationships

Class Name Description
Supplies environmental data to the Vehicle Position
Vehicle Position
subsystem.

In addition, Figure 2 explains the relationships between the subsystems as

well. When the APA system has been activated via the HMI, its various
subsystems are also activated. The vehicle position subsystem is supplied
with data from the ultrasonic sensors and cameras, and calculates the vehicle
trajectory for the park control subsystem. The park control subsystem
controls the steering, brake, and powertrain management subsystems in
order to maneuver the vehicle. It also takes input from the HMI in order to
determine which parking maneuver it should be performing. The HMI
displays visual data from the camera combined with the vehicle trajectory
when a maneuver is in progress.

In an example scenario, the driver activates the system and chooses to

parallel park via the HMI. The HMI then identifies to the driver an available
parking spot, and the driver would verify it. At this point, the park control
subsystem takes over steering, acceleration, and brakes, maneuvering the
vehicle into the correct position. Assuming the maneuver was completed
successfully, control of the vehicle is returned to the driver. This scenario is
displayed in Figure 3.
Figure 4. Sequence diagram of first example scenario where a parallel park maneuver is successfully completed by the
system.

Another example scenario starts out much the same, except the system
encounters an obstacle during the maneuver. The system stops the vehicle
and notifies the driver. The driver then verifies that the system should not
continue. This scenario is displayed in Figure 4.
Figure 5. Sequence diagram of the second example scenario, depicting what happens if the system detects an obstacle
while it is maneuvering into a parking spot.

Figure 5 shows the overall behavior of the HMI and the APA system that the
user will use for initiating the feature. Starting at the home page of the HMI,
the user can select the parking type desired and the system will begin
searching for a viable parking spot. Upon locating a valid parking spot, the
user can choose to reject the spot and have the system continue searching for
a new spot, or can accept the parking spot. If accepted, the system will begin
the active park assist process, pausing if an object moves into the path of the
vehicle or aborting the process if the brake is applied or a timeout occurs.
Upon completion, the HMI will display a completed screen and will return
the user back to the HMI homepage.
Figure 6. A state diagram of the systems that showing the behavior of the system, capturing the system’s overall
operation and state.

5 Prototype

This prototype shows the events that would occur throughout the process of
the APA feature. The prototype provides the interface that the user would
interact with, as well as allows the user of the prototype to provide other
external factors such as the event where the user pushes the brake and the
system timing out.

5.1 How to Run Prototype

To run the prototype, the user needs to have access to the internet and be
able to access the webpage,
http://www.cse.msu.edu/~cse435/Projects/F2014/Groups/APA2/web/Pro
totypeV1/ProtoV1.html. The prototype is entirely web-based and provides
the series of events that the HMI would progress through while the APA
feature is operating. The prototype will start the user at the main screen of
the HMI. The only button selection on the main screen that will function is
the APA button, or the button with the “P” for its text. The user will then
have the option to select either parallel parking assistance or perpendicular
parking assistance. Once an option is selected, the prototype will show that
the system is scanning for a parking spot. After a parking spot is located, the
user will then have the option to either accept the parking spot or reject the
parking spot. If the user rejects the parking spot, the system will begin the
scanning process again. If the user accepts the parking spot, then the
prototype will show that the system is in the process of parking the vehicle.
At any time if the user selects the external option of pushing the brake, the
system will abort and the process will conclude. Similarly, if the process
timeout option is selected, indicating that the process has not completed in
the given amount of time, the process will abort and conclude. Upon a
successful parking process, the HMI will display that the process was carried
out successfully and the parking process will return full control back to the
user (indicated by returning to the HMI home page of the prototype).

5.2 Sample Scenarios

The driver wishes to park perpendicularly in a parking spot located in a
parking lot.

As the driver approaches their destination, the driver activates the parking
functionality by pressing the “P” located in middle of the bottom row of the
main screen as shown in Figure 7.
 Figure 7. HMI main screen

After the driver invokes the parking system, the driver will be given the
option to select which type of parking feature to execute as can be seen in
Figure 8. The driver chooses “Perpendicular Parking”.

Figure 8. Parking feature selection

After perpendicular parking has been selected, APA will now enter a
scanning mode that can be seen in Figure 9. The vehicle is traveling at 5
miles per hour, which is adequate for the system to execute. When the
driver approaches an available parking space, the HMI will display what is
shown in Figure 10. This screen informs the driver that an available
perpendicular parking spot has been found and gives the driver the option to
accept or reject what the system has found. The driver accepts the spot and
as a result the HMI screen changes to a live display of what is behind the
vehicle as the maneuver is completed (seen in Figure 11).

Figure 9. HMI while scanning for a perpendicular parking spot

Figure 10. HMI indicating an available spot has been found

Figure 11. HMI live camera as vehicle is reversing

After the process is completed, the HMI will now display a screen (figure
12) confirming the process has completed. The vehicle will now be in park.

Figure 12. HMI informing use the process is completed

6 References

[1] Land Rover USA. “2014 Range rover Evoque Park Assist | Land Rover USA.”
YouTube. YouTube, 17 June 2014. Web. 14 October 2014.

[2] G. Spencer (2010, March 11). Intelligent Parking Assist for Toyota Prius [Online]. Available:
http://www.cnet.com/news/intelligent-parking-assist-for-toyota-prius/

[3] G. Straton. (2012, October 16). 2012 Toyota Prius V – Cutting it close [Online]. Available:
http://www.chicagonow.com/drive-he-said/2012/10/2012-toyota-prius-v-cutting-it-close-
aka-guided-parallel-parking-video/

Project Website:
http://www.cse.msu.edu/~cse435/Projects/F2014/Groups/APA2/web

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.