Software Requirements Specification (SRS)

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 Fords new Lincoln lines. The purpose, constraints, requirements, and prototyping will all be covered in this document, along with models for the systems 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 paper it will present 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. 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 replacing the entirety of the parking process. By maneuvering the vehicle by use of 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.

1.3 Definitions, acronyms, and abbreviations

Term Definition Active Park Assist The name of the system. APA Active Park Assist; see definition above. Client Ford Motor Company Customer See client. Person operating the vehicle equipped with the Driver system. Assumes a line running from the front of the vehicle Parallel to the rear, and refers to a line, spot or object in parallel to that line. Perpendicular Assumes a line running from the front of the vehicle to the rear, and refers to a line, spot or object in parallel to that line. Human Machine Interface between the system and the driver. Interface

HMI Human Machine Interface; see definition above. User See driver.

1.4 Organization

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

The third chapter 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 chapter 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 fifth and final chapter provides 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. Chapters one, two, and five are directed towards both the client as well as the developers, whereas chapters three through five are specifically directed towards the developers.

2 Overall Description

The intent of this section is to give an overview of the system and how it works relative to the bigger system it is a part of. This overview will include 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. Product Perspective

This system will be in place to help orchestrate several other subsystems within the vehicle to perform its functions. The system will be comprised of the HMI, park control, power management, brake control, steering control, and vehicle position subsystems. The vehicle position system will include a network of peripheral cameras and sensors that will aid in system function as well.

The HMI will accept input from the user, provide visuals for any system warnings, and display 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.

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 scan for, parallel or perpendicular. To aid the user finding a spot, the system will scan for and present potential parking spaces to users through visuals on HMI. The user will then interact with the HMI 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 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 sequence 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.

Figure 2. High level diagram of the system’s functional goals

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 for the system 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 in a reasonable amount of time. 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 itself will be constrained to vehicles with shift by wire transmissions only 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 present themselves 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 account for failures, it is expected that hardware components of the subsystems have their 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

General 1. Sensors a. The vehicle must have ultrasonic sensors on both sides b. The vehicle must also have cameras in the rear c. The system must be able to use the ultrasonic sensors to calculate the distance between two objects 2. System activation a. The vehicle must be stopped in order to engage the system b. Once engaged, the customer must then drive forward slowly (around 2.5 mph) until a spot has been detected c. In order to activate a parking maneuver, the customer must first apply the brakes, and then shift into neutral 3. The parking process must be carried out within 75 seconds, or else the system will abort 4. The system must shift the vehicle into neutral when the process successfully completes 5. The system must deactivate, returning control to the customer, when the process successfully completes 6. The system will be unavailable if a trailer is attached to the vehicle HMI 1. The customer must be able to select between parallel and perpendicular parking 2. The customer must activate the Active Park Assist Feature through the HMI 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 at 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 5. The HMI must display any warnings associated with system failure or collisions

Active Park Assist System 1. The system must be able to take full control of the vehicles 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 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 if it was recently aborted Safety 1. The vehicle must be stopped in order to activate the system 2. The system should have a speed cap of 5 mph, and ignore when the customer presses the accelerator 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, the system must shift the car back to neutral e. If one of the vehicle doors is opened, the system should pause and continue once the door has been closed again 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, the system will apply the brakes until the customer either aborts or chooses to continue c. Any collision will abort the system 5. The system must verify that the customer initiated the request 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. Obstructing objects only interact indirectly with the system in that, once they are detected, the system notifies the driver of the obstacle and halt the maneuver as noted in Section 3 under safety requirements.

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 under HMI requirements. At any time, the driver may choose to deactivate the system. Figure 1. Use case diagram displaying how the various subsystems of the Active Park Assist system interact given user input Figure 1 also 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 Automatic Park Assist 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 Automatic Park Assist system, and requires ultrasonic sensors and cameras. Figure 2. Conceptual domain model depicting interactions between key elements of the system

Figure 2 explains the relationships between the subsystems as well. When the Automatic Park Assist 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 3. 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 driver decides to press the brake halfway through the maneuver. The system aborts, and control is returned to the driver. This scenario is displayed in Figure 4. Figure 4. Sequence diagram of the second example scenario, depicting what happens if the driver aborts the system by pressing the brake.

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 5. 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 active park assist 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 break and the system timing out.

5.1 How to Run Prototype

To run the prototype, the user would need to have access to the internet and be able to access the webpage, http://www.cse.msu.edu/~cse435/Projects/F2014/Groups/APA2/web/Prot otypeV1/ProtoV1.html. The prototype is entirely web based and provides the series of events that the HMI would progress through while the active park assist feature was operating. The prototype will start the user at the main screen of the HMI. The only button selection on the main screen that will a 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 the option is selected, the prototype will show that the system is scanning for a parking spot. Below the HMI screen are options for the user operating the prototype to select, such as having the user apply the brake or a parking spot being located. Once 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. Again the user is offered options outside of the HMI to cause events affecting the system, such as an obstacle moving in the path of the vehicle. If the user selects the obstacle event, the HMI will display that the system has paused, resuming after the obstacle has moved or timing out if the time limit for the parking processes is exceeded. At any time if the user selects the external option of having the user push 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 A female driver wishes to park perpendicularly in a parking spot located in a parking lot.

As she approaches her destination, she activates the parking functionality by pressing the “P” located in middle of the bottom row of the main screen as shown in figure 1.

Figure 1. HMI main screen

After she invokes the parking system, she will be given the option to select which type of parking feature to execute as can be seen in figure 2. She will choose “Perpendicular Parking”.

Figure 2. Parking feature selection After perpendicular parking has been selected, APA will now enter a scanning mode that can be seen in figure 3. She is traveling at 5 miles per hour, which is adequate for system to execute. When she approaches an available parking space the HMI will display what is shown in figure 4. This informs her that an available perpendicular parking spot has been found and gives her the option to accept or reject what the system has found. She will accept the spot; this will change the HMI to a live display of what is behind the vehicle as the maneuver is completed (seen in figure 5). Figure 3. HMI while scanning for a perpendicular parking spot

Figure 4. HMI indicating an available spot has been found

Figure 5. HMI live camera as vehicle is reversing

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

Figure 6. 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.