45
Software Requirements Specification (SRS) Project Active Park Assist: Team 4 Authors: Elizabeth Stevens, Chris Cardimen, Cody Lowen, Shaheer Hasan Customer: Ms. Eileen Davidson, Ford Motor Company Instructor: Dr. Betty H. C. Cheng, Michigan State University 1 Introduction The Ford Motor Company is an American-based automotive manufacturing company. Each year, new features are developed, tested, and implemented into vehicle manufacturing. As high capability hardware becomes available, additional autonomous features can be developed and integrated. The Active Park Assist feature (APA) is an autonomous feature that autonomously parks a vehicle in either parallel or perpendicular parking spaces. This feature is designed to enable a vehicle to follow a parking procedure using ultrasonic sensors and cameras to detect obstacles and parking lines while guiding the vehicle in a safe and timely manner. The topics outlined include the purpose and scope of the Active Park Assist system. System details such as the product perspective, functionality, user characteristics, and limitations as well as assumptions about the environment and approportioned requirements are included. These requirements are hierarchically structured by priority and modeled based on user cases and respective scenarios. There is also information about an executable prototype version that visually represents different scenarios and system responses of the provided feature. 1.1 Purpose The purpose of the Software Requirements Specification (SRS) document is to outline and model the requirements of the APA system to help inform the customer of the team’s interpretation of the project. Several diagrams and prototypes are provided to describe the system’s functionality in detail for a seamless illustration of the defined requirements and limitations. These thorough and intuitive descriptions of the feature provides guidance for the customer team to pursue further development of this system and in general for users or stakeholders to review.

P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

  • Upload
    others

  • View
    9

  • Download
    0

Embed Size (px)

Citation preview

Page 1: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Software Requirements Specification (SRS)

Project Active Park Assist: Team 4

Authors: Elizabeth Stevens, Chris Cardimen, Cody Lowen, Shaheer HasanCustomer: Ms. Eileen Davidson, Ford Motor CompanyInstructor: Dr. Betty H. C. Cheng, Michigan State University

1 Introduction

The Ford Motor Company is an American-based automotive manufacturingcompany. Each year, new features are developed, tested, and implemented into vehiclemanufacturing. As high capability hardware becomes available, additional autonomousfeatures can be developed and integrated. The Active Park Assist feature (APA) is anautonomous feature that autonomously parks a vehicle in either parallel or perpendicularparking spaces. This feature is designed to enable a vehicle to follow a parking procedureusing ultrasonic sensors and cameras to detect obstacles and parking lines while guidingthe vehicle in a safe and timely manner.

The topics outlined include the purpose and scope of the Active Park Assistsystem. System details such as the product perspective, functionality, user characteristics,and limitations as well as assumptions about the environment and approportionedrequirements are included. These requirements are hierarchically structured by priorityand modeled based on user cases and respective scenarios. There is also informationabout an executable prototype version that visually represents different scenarios andsystem responses of the provided feature.

1.1 Purpose

The purpose of the Software Requirements Specification (SRS) document is tooutline and model the requirements of the APA system to help inform the customer of theteam’s interpretation of the project. Several diagrams and prototypes are provided todescribe the system’s functionality in detail for a seamless illustration of the definedrequirements and limitations. These thorough and intuitive descriptions of the featureprovides guidance for the customer team to pursue further development of this systemand in general for users or stakeholders to review.

Page 2: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

1.2 Scope

The APA feature is a system that is integrated into the operating system of anautomotive vehicle as embedded software. This feature allows the vehicle toautonomously park itself in either a parallel or perpendicular parking space by thediscretion of the driver through either the Human Machine Interface (HMI) or theFordPass App. The objective of this feature is to develop a system that uses built in safetytechnology, enabling a vehicle to autonomously park with minimal driver interactions.The benefits of this system allow parking maneuvers to be completed in an accurate andsafe manner while promoting safer driving by relieving the possibility of driver error.

When the APA feature is enabled, the driver chooses an appropriate parking spotfrom a list of available parking spots nearby and has the choice to either stay or exit thevehicle before the completion of the parking maneuver. During this maneuver, the driveralso has the ability to regain full control of the vehicle again by interacting with thebraking system or steering wheel. If the driver chooses to exit the vehicle, then themaneuver can be monitored through the FordPass App. The FordPass App has the abilityto manipulate vehicle speed remotely. The system will use the vehicle’s hardware safetyequipment such as ultrasonic sensors and cameras that reach up to six feet to monitorsurroundings while directing the vehicle into the desired spot. In the case that the safetyequipment experiences failure or an obstruction was encountered during the maneuver,the system will stop the vehicle until the driver presses the brake and is again given fullcontrol of the vehicle. If the parking maneuver is completed successfully the vehicle isplaced into parking gear and the feature is then disabled. The system is designed tosupport autonomous functionality of the vehicle in regards to directional movement,acceleration/deceleration, security, and safety precautions.

1.3 Definitions, acronyms, and abbreviations

Prototype-User : Person who is using the prototype.User : Anyone who is operating the vehicle system with the autonomous parking feature.Driver : The human who is physically operating the movement and manipulation of thevehicle.Active Park Assist : The defined name of the autonomous parking feature.HMI : Acronym for the Human Machine Interface which is a touch screen available inthe vehicle used for the Active Park Assist feature activation and interaction as well ashardware interfaces .Ford Pass Application : The mobile device application that can be synchronized with avehicle for use of the Active Park Assist feature remotely.Ultrasonic Sensor : Safety equipment built on to the vehicle for detecting objects in thevehicle’s surroundings. Can reach up to six feet beyond the bounds of the vehicle.APA: Active Park Assist.

2

Page 3: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Park Control Subsystem : Controls the Active Park Assist Feature as well as issuescommands to other subsystems based on input from the HMI.Powertrain Management Subsystem : Subsystem that controls vehicle gear position andacceleration.Brake Control Subsystem : Controls components connected to the vehicle’s mechanicalbraking system.Steering Control Subsystem : Controls components connected to the vehicle’s mechanicalsteering system.Vehicle Position Subsystem : Interprets input from the vehicle’s safety hardwarecomponents such as the cameras/ultrasonic sensors.

1.4 Organization

The following document outlines seven sections that outline the capabilities andlimitations as well as the functionality of the Active Park Assist System. The purpose,scope, terminology and organization was defined in Section 1 of this document. Section 2provides an overall description of the product such as the system’s functionality, usercharacteristics, limitations and stated assumptions. Section 3 provides a hierarchicalstructure of enumerated requirements in accordance with the customer’s priority as wesee are modeled in specific use cases and scenarios in Section 4. Section 5 is adescription of two prototype versions to illustrate the product’s respective scenarios. Alist of references and a point of contact is also provided at the end of this document inSection 6 and Section 7.

2 Overall Description

The following subsections describe the product in terms of functionality, typicalusers, constraints, and assumptions. A data flow diagram is used to describe theinteraction between system interfaces and its constraints. This will give a betterunderstanding of how a user interacts with the system and all of its relative subsystems. Afull description of the product’s functionality in a typical environment and how thevehicle components respond is provided. This section also includes defined requirementsfor a user and constraints of the system so that assumptions can be made about an idealuser-system interaction within a controlled environment.

2.1 Product Perspective

The APA system is a compilation of physical and software components that willassist the user by parking the vehicle autonomously. The user of this system can activatethe APA via the HMI or the FordPass app. This system makes use of subsystems withvehicle components such as the braking, powertrain, camera, ultrasonic sensors, throttle

3

Page 4: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

control, and steering systems. Subsystems interpret input and send messages through acomprehensive network of connections between the APA system and its subsystems. Thesystem utilizes the communication between subsystems to control the vehicle in order toperform an autonomous parking maneuver accurately. Figure 2.1 shows a data flowdiagram that illustrates the typical input/output interactions between these subsystems.

Figure 2.1: Data Flow Diagram

The system has the following interface constraints:

System Interfaces: The system interface includes the main functional operatingsystem as well as all hardware systems of the vehicle. If any system required forthe APA to operate fails or malfunctions then the system will be non-functional.

User Interfaces: Only the user can initiate and interact with the APA system.This can be done in two ways with either the HMI or the FordPass App. The userinteracts with the HMI by enabling the activation of the APA feature byinteracting with the dash screen as well as the two main user interactivesubsystems, the braking subsystem and steering subsystem. These two subsystemsare used to decelerate the vehicle during the parking maneuver and for thedeactivation of the APA feature upon wheel torque or vehicle halting due to brakeactivation. These two subsystems are also included in the FordPass App as a wayfor the user to control these subsystems remotely.

Hardware Interfaces: The hardware components the system utilizes as hardwareinterfaces for the APA feature include the user’s cell phone, dash screen,ultrasonic sensors, cameras, throttle, steering, brake, transmission and the

4

Page 5: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

vehicle's on-board computer. A user cell phone must support local detectiontechnology. The cameras and ultrasonic sensors are used to detect objects andobstacles in the surroundings and must be installed to be configured for a six footperipheral detection beyond the bounds of the vehicle. The hardware interfaces,each connected to a specific subsystem, send and receive input with theirrespective subsystems in order to communicate with other components within thesystem. Any failures to the hardware components of the vehicle specific to thefunctional dependency of the APA feature and the system becomesnon-functional.

Software Interfaces: There are two software interfaces that allow the user toactivate the APA feature and control specific subsystems. The vehicle dash screenis the first software interface that the user will have initial access to in order toactivate the APA feature. When the feature is active, the dash screen provides theuser a series of prompts and system notifications at major state transitions thatinvolve user interaction. Otherwise at the selection to exit the vehicle, thesoftware interface transitions to the FordPass App where the user can also receivea series of prompts and system notifications as well as access to control thesubsystems that a user would typically interact with when present inside thevehicle. The software interfaces also have connection to remote servers forFordPass App authentication as well as local detection between the HMI and theFordPass App. Any failures within the software interfaces and the systembecomes non-functional.

2.2 Product Functions

The APA system has several functions. A user will be able to activate and interactwith the APA feature within the vehicle or upon exit from the vehicle through theFordPass App. Upon entry to an environment where parking is available, the user willengage with the brake to bring the vehicle to a complete stop. Once the vehicle has cometo a complete stop the APA feature becomes available and the user will interact with thedash screen to activate the feature. Next, a dialog notification will appear on the screen toindicate if a parking spot is available. The system detects available spots by usingultrasonic sensors and cameras that reach up to six feet beyond the bounds of the car. Ifparking spots are available, the user will have the option to decide whether the car shouldpark parallel or perpendicular by responding to the prompts presented on either the dashscreen within the vehicle or the FordPass App. Depending on the situation, there mightonly be one type of parking option; but if applicable, both parallel and perpendicularoptions should appear. If there is at least one parking spot available for the selectedoption it will appear on the screen to indicate that the spot is available. The user will thenbe able to click the parking spot to begin the parking maneuver.

During the parking maneuver, the vehicle will have a maximum speed of 5 mph inwhich the user has the ability to control the speed of the car through the braking system.

5

Page 6: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

The multiple different cameras and ultrasonic sensors that monitor the vehicle’s positionand surroundings during this maneuver communicate with the system to determine wheelposition and brake tension. The driver may stop the parking at their convenience by eitherpressing the foot brake with enough tension to halt the vehicle or by applying torque tothe steering wheel. When this happens, the vehicle enters a state in which the speed isreduced to 0 mph and the system waits for the driver to again press the brake todeactivate the APA feature and give back full control of the vehicle to the driver. Otherfunctions of the system including authentication with cloud communication and cellphone locality detection are critical for system updates and communication between theFordPass App and the APA system within the vehicle.

2.3 User Characteristics

A typical user of the APA system must have valid government issueddocumentation such as a driver's license in order to legally operate a vehicle. The usermust be familiar with the operation of an automotive vehicle and is knowledgeable abouthow to operate using generalized equipment that can be found in every vehicle such asthe transmission, brake, and steering wheel. It is expected that a typical user also has asufficient background in driver education and can manually perform parallel andperpendicular parking. The user should have general expertise and common knowledgeabout safety precautions and state laws and can actively acknowledge safety concerns asthey arise during the operation of a vehicle. Users are expected to navigate a touchscreenand must be familiar with interpreting prompts when interacting with touchscreentechnology.

2.4 Constraints

The following lists all of the constraints and limitations of the APA system. Thisincludes constraints that are critical beyond the functionality of the APA system.

1) Regulatory policies: The government has forced restrictions on some activitieswith the APA system that may not be permitted in some states.

2) Hardware limitations: Many hardware safety features are incorporated with theAPA system. Cameras and ultrasonic sensors have a limited peripheral of six feetbeyond the bounds of the vehicle and can only be applicable during optimalweather conditions. Cameras and ultrasonic sensors will be up to date with thelatest vehicle models. Some hardware safety features may not be compatible witholder vehicle versions at Ford Motor Company.

3) Interfaces to other applications:a) Park Control Subsystem: Masters the APA feature. It accepts the customer

input from the HMI subsystem, calculates the vehicle trajectory based oninformation from the Vehicle Position Subsystem, and issues commands tothe other subsystems.

6

Page 7: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

b) Powertrain Management Subsystem: Accepts inputs from the Park ControlSubsystem to accelerate the vehicle and select the gear lever position inorder to meet the required trajectory. The maximum speed allowed for aparking maneuver when the APA system is active is 5 mph. The gear leverposition is only to be repositioned when a successful maneuver has beencompleted.

c) HMI Subsystem: Accepts customer inputs, displays camera information,and handles telltales / warnings.

d) Brake Control Subsystem: Accepts inputs from the Park ControlSubsystem to brake the vehicle in order to meet the required trajectory.The Brake Control Subsystem is crucial for the controlled acceleration ofthe vehicle as well as the deactivation of the APA feature.

e) Steering Control Subsystem: Accepts inputs from the Park ControlSubsystem to steer the vehicle in order to meet the required trajectory. Theuser will not be able to control the direction of the vehicle during theparking maneuver through the Steering Control Subsystem but can applytorque to notify the APA system to halt the vehicle and deactivate thefeature.

f) Vehicle Position Subsystem: Processes data from the vehicle’s cameras /radar in order to identify parking spots and verify vehicle positionthroughout the duration of a parking event. Can only process given that allhardware safety features are adequately functional.

g) Customer Cell phone: Allows the customer to control the parkingmaneuver remotely. Can only communicate with the vehicle and mustcommunicate with the cloud for user authentication.

4) Criticality of the application: In case of an emergency, dial 911 or your localemergency number immediately.

5) Safety and security considerations: Although the APA system is built to park avehicle, its top priority is to ensure the safety of the passengers inside the vehicleand pedestrians around the vehicle. This includes firewall protocols that do notallow exploitation of the system to ensure that only the authorized driver has fullcontrol of the APA system.

2.5 Assumptions and Dependencies

The following lists the assumptions and dependencies surrounding the usage ofthe APA system.❖ The driver will have the ability to interact with the APA system via the HMI and

or the FordPass application at all times during the parking procedure and must bein close proximity to the vehicle when using the FordPass application.

❖ All hardware necessary to implement the APA system as defined will be selectedand implemented in the vehicle design by Ford Motor Company.

❖ Hardware chosen by Ford Motor Company must possess the ability to send andreceive data in a timely manner to assure safety.

7

Page 8: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

❖ Ford Motor Company will encrypt all updates sent to both the APA system andany other systems within the vehicle to ensure security of the APA system.

❖ Ford Motor Company will only use electronic steering racks and steering controlsystems in vehicles which implement APA.

❖ The system will operate in any weather condition as long as ultrasonic sensorsand cameras are not obstructed or malfunctioning.

❖ If the parking spot is perpendicular the spot only exists as perfectly perpendicularto the immediate road. Similarly a parallel parking spot exists perfectly parallel tothe immediate road.

❖ The vehicle will not have any hitch attachments for the APA system to beoperational.

❖ The vehicle's APA system will have the ability to adapt to vehicle modificationssuch as increase or decrease in tire size.

❖ The APA system will not be capable of parallel or perpendicular parking on theopposing side of an identifiable street with double yellow lines.

❖ All hardware required by the APA system must be operational for the APA systemto be activated and continue to operate.

❖ The vehicle has systems in place to detect the presence of the driver and theirpassengers in the vehicle, and whether or not their seat belt is on. If APA isactivated via the HMI both the driver and passengers must have their seat belts onif local, state or federal law dictates they are required for vehicle operation. In thecase of the APA being activated via the FordPass app the vehicle must detect thatthere is neither driver nor passengers in the vehicle.

❖ The vehicle has an automatic transmission.

2.6 Approportioned Requirements

Based on negotiations with the customer, it was determined that there arerequirements beyond the scope of the current project and may be addressed in futureversions. Some of these requirements include but are not limited to:❖ Independent features outside of driving such as the hands-free bluetooth system to

be disabled when the Active Park Assist feature is enabled.❖ Allowing the user to choose the direction of vehicle entry into a parking spot.

8

Page 9: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

3 Specific Requirements

The section describes a hierarchical list of requirements for the Active ParkAssist. Each requirement is identified in one of the following sections: Global Invariants,System, and Security. The system requirements are further split into functional andnonfunctional requirements.

1. Global Invariants Requirements1.1. The system must ensure the user’s safety as its first priority.1.2. Vehicle must be able to avoid or maneuver around any obstacles that

appear during parking.1.3. Driver, if in the vehicle, must be able to stop the vehicle at any time using

the brake pedal or via a physical switch.1.4. Vehicle must use automatic or semi-automatic transmission.1.5. Vehicle can use forward, acceleration/break, and steering for getting to

parking locations.1.6. A parking spot must be identified for the maneuver to continue.1.7. Vehicle has a maximum speed in which speed and position must be

monitored throughout the entire maneuver.1.8. Driver will interact with the system only with the HMI or authorized Ford

mobile app.

1.9. The vehicle must not exceed a maximum speed of 5 mph.1.10. A reasonable amount of time must be allotted for the system to complete

the parking process.

2. System Requirements2.1. Functional requirements

2.1.1. Vehicle must be able to automatically park itself.2.1.2. Vehicle can only park in parallel or perpendicular parking spots.2.1.3. Sensors must be able to accurately determine parking spots, and

whether or not the chosen spot is large enough.2.1.4. Requires pressure and seat buckle in drivers’ seat to activate and

operate if using in-vehicle HMI.2.1.5. Vehicle uses Lidar and Sonar for parallel and redundant distance

detection.2.1.6. If sensors are failing due to coverage such as snow or other factors,

the system should disable and warn the driver. Redundant systemsthat are nonfunctional may be ignored (until they becomenecessary, if need be).

2.1.7. Vehicle can adjust steering to a specified location if parked on ahill (Should roll into the curb if the parking brake fails).

2.1.8. Vehicle must use power steering to maneuver into the parking spot.

9

Page 10: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

2.1.9. System will place the vehicle into parking gear and the featurebecomes inactive when the maneuver has completed.

2.1.10. System must notify the user through HMI when no maneuvers arepossible.

2.1.11. Vehicle can detect if a trailer or other towable is attached anddisable the self parking feature.

2.2. Non Functional requirements2.2.1. Interaction with the vehicle can only happen through the HMI or

authorized Ford mobile app.2.2.2. Vehicle must be proven to be the user’s through verification by

Ford.2.2.3. Direction of entry must be chosen for the vehicle prior to park

maneuver.2.2.4. The user must be able to use the brake pedal to slow or stop the

vehicle.2.2.5. The user must be able to control the vehicle’s speed and position

using the app.2.2.6. The app must also be able to communicate with the vehicle.2.2.7. System must identify and notify the user during active parking

maneuvers when new obstacles have been presented.2.2.8. System will indicate to the user when the maneuver begins and

ends.

3. Security Requirements3.1. System could be exploited as it is software driven, so a security system

must be in place. Any third parties or malicious software must be detectedonce recognized.

3.2. Security system must be able to detect whether any unauthorized softwarechanges have been made.

3.3. The system must be able to verify all credentials for the Active ParkAssist.

3.4. In the case of a breach from an alternative external source, the systemmust produce an emergency response to stop the system, send anotification on the FordPass App, and give control to the user.

3.5. The system must monitor all software and hardware to ensure properfunctionality. If any component malfunctions, the system must notify theuser.

3.6. All data from the FordPass App must be encrypted to protect against cyberattacks.

10

Page 11: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4 Modeling Requirements

This section describes the many models that will be used for the Active ParkAssist. These models include Use Cases Diagrams, Class Diagrams, Sequence Diagrams,and State Diagrams. All figures are explained in detail with their respective diagrams.

4.1 Use Cases

Figure 4.1 below represents all of the use cases that are demonstrated within thesystem. This diagram is used to show all of the functions as the whole system. Outside ofthe blue box are the actors, which are represented as stick figures. The actors play a rolewithin the system to provide use cases with other actors. In this case, the blue ovals withblack outlines represent the use cases. These use cases are connected to the actors with ablack line. Additionally, each use case has another line that is labelled as “include” or“extend”. Include means that the use case is being used in another use case as well.Extend denotes that the use case is an extension of another use case. Below the diagramis an explanation of each use case that is portrayed in the diagram.

Figure 4.1: Use Case Diagram

11

Page 12: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Active Park Assist

Actors: User

Type: Primary (essential)

Description: The driver will activate the active park assist through the FordPassApp. After all requirements are selected, the car will follow throughon the parking process. This will include the control of moving andbraking the car.

Includes: FordPass App

Extends:

Cross-refs: Requirements 1.1, 1.5, 1.9, 1.10, 2.1.1, 2.1.4, 2.2.7, 2.2.8, 2.1.10,3.1, 3.2, 3.3, 3.4, 3.5, 3.6

Use cases: FordPass App

Use Case: FordPass App

Actors: Customer Cell Phone, System (Initiator)

Type: Secondary, Essential

Description: The user arrives at a parking lot with their vehicle and appdownloaded. The user exits the vehicle and opens the app. Theparking selections will then be chosen by the user. After finishingthe available spots and option of parallel or perpendicularparking, the vehicle will park itself. Upon completion, anindication of completion will be received through the app.

Includes: Authenticate User, Select Parking, User Control, View CameraAngle

Extends:

Cross-refs: Requirements 1.3, 1.6, 1.7, 1.8, 2.1.10, 2.2.1, 2.2.3, 2.2.4, 2.2.5,2.2.6, 3.4, 3.6

Use cases: Authenticate User, Select Parking, User Control, View CameraAngle

12

Page 13: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Authenticate User

Actors: System (Initiator)

Type: Secondary, Essential

Description: The user will need to provide information that confirms theiridentity as well as the vehicle in use for the active park assist. Thisverification will be done through the FordPass App. Oncompletion, the user will be able to activate the active park assistfeasibly.

Includes:

Extends:

Cross-refs: Requirement 2.2.2, 3.3

Use cases:

Use Case: Select Parking

Actors: System (Initiator)

Type: Secondary, Essential

Description: The user will be able to choose from the available parking spotsthat are within the app. There will be one or more options tochoose from. If no parking spots are available, the user will benotified. If the user clicks a parking spot then later decides tochoose another spot, they will be able to do so as well.

Includes:

Extends: Parallel, Perpendicular

Cross-refs: Requirement 2.1.2

Use cases: Parallel, Perpendicular

13

Page 14: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Parallel

Actors: System (Initiator)

Type: Secondary, Essential

Description: This option is selected by the user if they would like to park the carin parallel. There will be one or more parking spots available tochoose from. If no parking spots are available, the user will benotified.

Includes:

Extends:

Cross-refs: Requirement 2.1.2

Use cases:

Use Case: Perpendicular

Actors: System (Initiator)

Type: Secondary, Essential

Description: This option is selected by the user if they would like to park the carperpendicularly. There will be one or more parking spots availableto choose from. If no parking spots are available, the user will benotified.

Includes:

Extends:

Cross-refs: Requirement 2.1.2

Use cases:

14

Page 15: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: User Control

Actors: System (Initiator)

Type: Secondary, Essential

Description: This is the option where a user has control of the vehicle if they feelthe need to change something during the parking process. Thisincludes braking and decelerating the vehicle

Includes: Brake

Extends:

Cross-refs: Requirements 1.3, 1.6, 2.1.2, 2.2.3, 2.2.4, 2.2.5

Use cases: Brake

Use Case: Brake

Actors: System (Initiator), Brake Control Subsystem

Type: Secondary, Essential

Description: The user will be able to click the brake button within the FordPassApp to brake the car when they feel it is necessary. They areallowed to do this as many times as possible until the process iscompleted.

Includes:

Extends: Halt, Decelerate

Cross-refs: Requirements 1.1, 1.3, 1.5, 2.2.4,

Use cases: Halt, Decelerate

15

Page 16: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Halt

Actors: System (Initiator)

Type: Secondary, Essential

Description: The user will be able to completely stop the parking process byclicking the halt button. This will allow the system to quit and forcestoppage.

Includes:

Extends:

Cross-refs: Requirements 1.1, 2.1.11, 3.1, 3.2

Use cases:

Use Case: Decelerate

Actors: System (Initiator)

Type: Secondary, Essential

Description: The user will be able to adjust the speed of the vehicle while it isparking. If the user feels the need to slow the car down, they canadjust it through the app.

Includes:

Extends:

Cross-refs: Requirements 1.7, 2.2.4, 2.2.5

Use cases:

16

Page 17: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Automatic Transmission

Actors: Vehicle

Type: Primary (essential)

Description: While the Active Park Assist is running, the Ford vehicle willenable the automatic transmission and begin the parkingprocedure.

Includes:

Extends:

Cross-refs: Requirements 1.4, 1.5, 1.7, 1.9, 2.1.1, 2.1.5

Use cases:

Use Case: Find Valid Parking

Actors: Camera, Vehicle Position Subsystem

Type: Primary (essential)

Description: The camera will be able to identify the available parking spots thatwill be placed on the FordPass App for the user to see.

Includes:

Extends: Find Obstacle

Cross-refs: Requirements 1.6, 2.1.3, 2.1.5, 2.2.3

Use cases: Find Obstacle

17

Page 18: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Find Obstacle

Actors: Sensor

Type: Primary (essential)

Description: The objective of this use case is to identify any obstacles that maydisturb the vehicle when parking. This could include shoppingcarts, people, other vehicles, etc. The vehicle will avoid thesituation and possibly change parking spots. On completion, thevehicle will have avoided the obstacle and completed the parking,if possible.

Includes: Halt

Extends:

Cross-refs: Requirements 1.2, 2.1.3, 2.1.6, 2.1.11, 2.2.7

Use cases: Halt

Use Case: Steer Vehicle

Actors: Steering Control Subsystem

Type: Primary (essential)

Description: This subsystem takes into account the steering of the vehicle. Thiswill handle the movement that is occurring during the parkingprocess.

Includes:

Extends:

Cross-refs: Requirements 1.5, 2.1.7, 2.1.8

Use cases:

18

Page 19: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Accelerate

Actors: Powertrain Management Subsystem

Type: Primary (essential)

Description: This use case will speed up the vehicle when it is necessary for theparking procedure. Whenever the user decides to speed up the car,this subsystem will be initiated.

Includes:

Extends:

Cross-refs: Requirements 1.5, 1.9

Use cases:

Use Case: Select Gear Lever Position

Actors: Powertrain Management Subsystem

Type: Primary (essential)

Description: This use case involves the gear lever position which will beenabled through the powertrain management subsystem. It willallow changes in gear when needed.

Includes:

Extends:

Cross-refs: Requirements 2.1.9

Use cases:

19

Page 20: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Parks Vehicle

Actors: Park Control Subsystem

Type: Primary (essential)

Description: This is the basic parking subsystem. Everything will be run throughthis subsystem in order to securely park the car.

Includes:

Extends:

Cross-refs: Requirements 1.1, 1.6, 1.9, 1.10, 2.2.8

Use cases:

Use Case: Handles Warnings

Actors: HMI Subsystem

Type: Primary (essential)

Description: If any problem occurs during the process, this subsystem will takeinto account fixing the problem. This includes stopping the systemcompletely.

Includes: Halt

Extends:

Cross-refs: Requirements 2.1.6, 2.2.6, 3.1, 3.2

Use cases: Halt

20

Page 21: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Use Case: Customer Input

Actors: HMI Subsystem

Type: Primary (essential)

Description: The HMI Subsystem will take into account everything the user hasput into the app. This will allow the changes to go through withinthe HMI.

Includes: User Control

Extends:

Cross-refs: Requirements 1.3, 1.6, 2.1.2, 2.2.3, 2.2.4, 2.2.5

Use cases: User Control

Use Case: Display Camera Information

Actors: HMI Subsystem

Type: Primary (essential)

Description: All the information that is stored within the system that has arelation with the camera will be done in this subsystem.

Includes: Find Valid Parking

Extends:

Cross-refs: Requirements 2.1.3, 2.2.6

Use cases: Find Valid Parking

21

Page 22: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.2 Class Diagram:

The class diagram depicted in Figure 4.2 provides a description of classesrequired for the APA system to operate. The class diagram uses dotted lined arrows torepresent classes within the behavior processing package. The behavior processingpackage is a collection of classes used by the APASystem class to accomplish variousfunctional requirements.

Figure 4.2: Class Diagram

22

Page 23: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Element Name DescriptionHMI Subsystem Class representing the verification of the

parking process.Attributes N/A N/AOperations parkVehicle() Vehicle will park itself after all

necessary requirements are fulfilled.displayNotification() Any information that needs to be

prompted will be shown on the HMI.Relationships Has a one-or-many-to-one relationship with the Vehicle.UMLExtensions

Vehicle

Element Name DescriptionVehicle Class which represents an overview of

the vehicle in which the active parkingassist system is being utilized.

Attributes carModel : string Model of the car.manufactureDate : int Date that the car was manufactured.wheelDiameter : float Diameter of the currently attached

wheels.Operations parkVehicle() Vehicle will park itself after all

necessary requirements are fulfilled.displayNotification() Any information that needs to be

prompted will be shown on the HMI.Relationships Has a one-or-many-to-one-or-many relationship with the HMI

Subsystem.Has a zero-or-one-to-zero-or-one relationship with the FordPass App.Has a one-to-one relationship with the APA System.

UMLExtensions

HMISubsystem, FordPassApp, APASystem

23

Page 24: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Element Name DescriptionFordPassApp Class that represents the FordPass

Application.Attributes user : User The user that is associated with the

FordPass application.parkingType : string Variable that indicates the type of

parking spot: parallel or perpendicular.maxSpeed : int Integer variable that indicates the

maximum speed that the vehicle canattain.

transferControl : boolean Boolean that indicates whether thecontrol has been transferred from theHMI to the FordPass App.

credentialsVerified Boolean that represents if the credentialswithin the FordPass App has beenverified.

Operations logIn() Operation that allows login for aspecific User.

logOut() Operation that allows logout for aspecific User.

parkVehicle() Operation to indicate to the Vehicle thatit can begin parking.

displayNotification() Displays any information that is beingsent from the system to the app.

Relationships Has to zero-or-one-to-zero-or-one relationship with VehicleHas a one-to-one relationship with User

UMLExtensions

Vehicle, User

Element Name DescriptionUser Class which represents the person using

the FordPass app.Attributes userName : encrypted string Account name associated with the user

password : encrypted string Secret word or phrase used to gainadmission to app per user

Operations N/A N/ARelationships Has a one-to-one relationship with FordPassApp. One user will have one

app downloaded.UMLExtensions

FordPassApp

24

Page 25: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Element Name DescriptionAPASystem Class representing the Active Park

Assist Feature System.Attributes timeToFinishPark : int Integer indicating the amount of seconds

it takes for a Vehicle to completeparking.

parkingComplete : boolean Boolean to represent if the parkingprocess has been completed or not.

Operations verifyCredentials() Operation used to verify that credentialshave been authorized from the FordPassApp with this System.

enableParkAssist() Operation to enable the Active ParkAssist.

pauseParking() Operation to pause parking for avehicle.

resumeParking() Operation to resume parking for avehicle.

endParking() Operation to end parking for a vehicle.

disableAPA() Stop the APA if warnings trigger.

initiateParking() Operation to initiate parking for avehicle.

checkForObstructions() Checks to see if any obstructions arepresent in the area.

checkParkingComplete() Checks if the parking process has beencompleted.

notifyParkingComplete() Sends notification to the app about thecompletion of the parking process.

Relationships Has a one-to-one relationship with VehicleHas a one-to-one relationship with ParkControlSubsubsystem

UMLExtensions

Vehicle, ParkControlSubsubsystem

25

Page 26: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Element Name DescriptionParkControlSubsystem Class that represents the Active Park

Assist feature that issues commands toother subsystems.

Attributes N/A N/AOperations calculateTrajectory() Calculates all trajectory that is present.

allEquipmentOperational() Operation to make sure all equipment isoperational.

Relationships Has a one-to-one relationship with APASystemHas a one-to-one relationship with VehiclePositionSubsystemHas a one-to-one relationship with SteeringSubsystemHas a one-to-one relationship with BrakeSystemHas a one-to-one relationship with PowertrainManagementSubsystem

UMLExtensions

APASystem, VehiclePositionSubsystem, SteeringSubsystem,BrakeSystem, PowertrainManagementSubsystem

Element Name DescriptionVehiclePositionSubsystem Class that processes the vehicle’s

camera.Attributes cameraSteamAvailable : boolean Boolean that represents if the

camera stream is on or off.Operations turnCameraOn() Turn the camera on.

turnCameraOff() Turn the camera off.ultrasonicFailureDetection() Detects if a problem occurs with the

ultrasonic sensor.detectObstacle() Detects if any obstacle is present

during the parking process.Relationships Has a one-to-one relationship with ParkControlSubsystem.UMLExtensions

ParkControlSubsystem

Element Name DescriptionSteeringSubsystem Class that accepts information from

the Park Control Subsystem to steerthe vehicle.

Attributes N/A N/AOperations getSteeringPosition() Returns the current steering

position.setSteeringPosition() Sets the current steering position.

Relationships Has a one-to-one relationship with ParkControlSubsystem.

26

Page 27: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

UMLExtensions

ParkControlSubsystem

Element Name DescriptionBrakeSubsystem Class that accepts information from

the Park Control Subsystem to brakethe vehicle.

Attributes N/A N/AOperations setBrakeActuator() Sets the current state of brake

activity.getBrakeActuator() Returns the current state of the

brake activity.Relationships Has a one-to-one relationship with ParkControlSubsystem.UMLExtensions

ParkControlSubsystem

Element Name DescriptionPowertrainManagementSubsystem Class that accepts information from

the Park Control Subsystem toaccelerate the vehicle and selects thegear lever position.

Attributes N/A N/AOperations setVelocity() Sets the velocity of the vehicle.

setTransmissionGear() Sets the transmission gear of thevehicle.

Relationships Has a one-to-one relationship with ParkControlSubsystem.UMLExtensions

ParkControlSubsystem

27

Page 28: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.3 Sequence Diagram(s):

Sequence diagrams represent the transitional flow of operations for any givenscenario. The scenarios covered are a successful parallel parking operation in section4.3.1, a failed camera sensor in section 4.3.2, and an attempted connection to the APAsystem by a hacker in scenario 4.3.3.

4.3.1 Successful Parallel Parking Via FordPass App Scenario 1:

Figure 4.3.1 Sequence Diagram for Scenario 1

In this scenario the user activates the APA system via the FordPass applicationand then chooses to find parallel parking spaces. The system then looks for parallelparking spots available. Once available parallel parking spots are found the APA systemnotifies the FordPass app to display parking locations found by the vehicle and promptthe user to select a parking location. In this scenario, the system only detects parallelparking spots available. Once the user has selected a parallel parking location the vehicledetermines that the spot is 1.2 times the length of the vehicle, then the vehicle begins itsparking maneuver at a speed that does not exceed 5 mph. The vehicle throughout thismaneuver will look for obstructions and pause (stop the vehicle) if an obstruction isfound. In this scenario, no obstruction was found during the maneuver and the vehiclecontinues its parking procedure. Once the vehicle has reached the bounds of the parkingspot the APA system is notified to apply full pressure to the brake to bring the vehicle toa stop and switch the transmission into the parking gear. At this point the APA system is

28

Page 29: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

disabled and then notifies the FordPass app to display a notification to the user that theparking is complete. Full control is again regained by the user. Figure 4.3 depicts thesequence diagram for scenario 1.

4.3.2 Camera Equipment Fault Scenario 2:

Figure 4.3.2 Sequence Diagram for Scenario 2

The user again activates the APA system via the FordPass application. In thisscenario the user has selected a parking space and initiates parking through the FordPassapp. However when the parking maneuver is in motion, the system detects a failure fromone of the detection cameras located on the outside of the vehicle. The system thenreverts to a fail safe state by pausing the parking maneuver and applying full brakepressure to halt the vehicle. The APA system then notifies the FordPass app to display tothe user that a system error was detected. The APA system is deactivated while the brakewill continue to have full tension until the user once again applies pressure to the brakeand regains control of the vehicle.

29

Page 30: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.3.3 APA System Hack Scenario 3:

Figure 4.3.3 Sequence Diagram for Scenario 3

In this scenario the user activates the APA system via the FordPass application.The APA system then verifies that the FordPass app connection is authorized for thisvehicle. The connection is authorized and the user continues to select a parking spot andinitiates parking through the FordPass app. However when the parking maneuver is inmotion, another external connection attempts to activate the APA system. The APAsystem again verifies that this external connection is authorized. The external connectionis determined to not be authorized and the APA system responds by putting the vehicleinto its fail safe state. Parking is paused and brake tension is fully applied. The APAsystem notifies the FordPass App that the system has been breached and the app displaysa corresponding notification to the user. The APA system is deactivated while the brakewill continue to have full tension until the user once again applies pressure to the brakeand regains control of the vehicle.

4.4 State Diagrams:

The state diagram describes the behavior of the system’s classes and how theyrespond to input by both the driver and the APA systems command-response structure.The entity diagram uses blue round rectangles to represent specific states of the system.The arrows in diagrams represent the transition from one state to another state and any

30

Page 31: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

parameter or result leading up to the transition. Blue diamonds represent decisionstructures. Results from one state feed into the decision structure, then a state transition ismade based on the conditions of the decision structure. Black circles represent entry intospecific systems via request or state transition.

4.4.1 Complete System State Diagram:

The Complete Systems State diagram in figure 4.4.1 represents the overall APAsystem behavior and includes all individual subsystems. This diagram serves to representthe behavioral flow from the moment APA is activated to the end of its operation.

Figure 4.4.1 State Diagram

31

Page 32: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Idle: When the vehicle is not using the APA system.

Active Park Assist Activated: the APA system has been activated by either the HMI orthe FordPass app. This state also performs necessary security checks as described in theSecurityVerification class in the class diagram.

Check Equipment for Errors: Equipment required by the APA system is checked forerrors. This state occurs once when the system is first enabled, and multiple timesthroughout the parking procedure state loop.

Find Available Parking Spaces: The APAsystem looks for a parking space. If noparking space is available then control is returned to the driver and the APA system isdisabled.

Select From Available Parking Spaces: If a parking space is found in the previous stepthe user has the option to select the parking space from the available spaces. If the usercancels the action then the control is returned to the driver.

Look For Obstructions: Once a parking space is selected and the second error checkoccurs the APA system will look for obstructions in the path of the vehicle. Ifobstructions are found it will circle back and restart this process until either theobstruction is cleared or the APA system times out.

Park Vehicle Maneuver: If there are no obstructions for a given parking maneuver(small movement or maneuver required for complete parking procedure) then the parkingmaneuver will execute and the vehicle will complete the maneuver.

Check Brake Activated: If the brake has been activated after a very small movementgenerated in the Park Vehicle Maneuver then control will be returned to the driver. If not,the state proceeds to Check Parking Complete.

Check Parking Complete: Vehicle checks to see if it has secured its desired location inthe selected parking spot. If not then the loop begins again by checking for equipmenterrors.

Control Returned to Driver: Control of the vehicle is returned to the driver, APAsystem is disabled immediately after.

Active Park Assist Disabled: APA system is disabled and the vehicle's APA system goesinto an idle state.

32

Page 33: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.4.2 HMI

The HMI system diagram in figure 4.4.2 describes how the HMI system'sbehavior results in user input.

Figure 4.4.2 HMI State Diagram

33

Page 34: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.4.3 FordPass App

The FordPass App system diagram in figure 4.4.3 describes how the FordPass appsystem's behavior results in user input.

Figure 4.4.3 FordPass App State Diagram

4.4.4 Steering

The Steering state diagram in figure 4.4.4 represents how the steering systemreacts to input

Figure 4.4.4 Steering State Diagram

34

Page 35: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.4.5 Transmission

The Transmission system state diagram in figure 4.0.4 represents thetransmissions behavior in response to gear change requests

Figure 4.4.5 Transmission State Diagram

35

Page 36: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.4.6 Error Check

The Error Check state diagram in figure 4.4.6 represents the system's behaviorwhen an error occurs. This state diagram's behavioral processing takes place throughoutthe entire time the APA system is activated to ensure the system is always fullyoperational.

Figure 4.4.6 Error Check State Diagram

36

Page 37: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.4.7 Spot Selection

The Spot Selection state diagram in figure 4.4.7 represents the APA system'sbehavior when trying to find and select a spot to park the vehicle in.

Figure 4.4.7 Spot SelectionState Diagram

4.4.9 Braking

The Braking system state diagram in figure 4.4.9 represents the behavior of thebraking system in response to a braking tension setpoint requested by the vehicle and orAPA system.

Figure 4.4.9 Braking State Diagram

37

Page 38: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.4.10 Obstruction Detection

The Obstruction Detection system state diagram in figure 4.4.10 represents thebehavior of the APA systems detection of objects in the space surrounding the vehicle.This system is active throughout the entire time the APA system is active.

Figure 4.4.10 Obstruction Detection State Diagram

4.4.11 Camera(s)

The Camera system state diagram in figure 4.4.11 represents the behavior of thecamera system in response to a request to receive an image.

Figure 4.4.11 Camera State Diagram

38

Page 39: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

4.4.12 Ultrasonic Sensors

The Ultrasonic Sensors system state diagram in figure 4.4.12 represents thebehavior of the camera system in response to a request to receive distance.

Figure 4.4.12 Ultrasonic Sensor State Diagram

5 Prototype

Our prototype will show a variety of general use scenarios that a driver couldencounter when using the APA functionality. It demonstrates a user’s ability to controlvehicle speed, brakes, and the decision on where to park. Additionally, multiple cameraangles are included for the user so that they can obtain a better understanding of not justthe vehicle, but how its surroundings are being used to calculate the autonomous parkingcapabilities.

Our prototype is built upon the Unity engine, rendered in three-dimensionalgraphics, allowing for representation of how the active parking assist system wouldfunction in real-life situations. The prototype controls are embedded within a mobilephone application user interface, which represents an implementation of the Ford passmobile application, and how the system would integrate into its existing capabilities.However, the same controls would also be embedded inside the actual vehicle - allowingfor our prototype to demonstrate both use cases: a driver controlling the system frominside and outside the vehicle.

39

Page 40: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

5.1 How to Run the Prototype

There are two possible ways to run the prototype: in-browser, under the“Deliverables” section of our team’s webpage, or through a Windows OS executable file.Unless otherwise specified, assume that no additional plugins, constraints, or otherconditions are required.

Web-browser:1. Go to the Active Parking Assist Team 4 Website2. Navigate to the “Deliverables” section and enter the username/password

a. Username: apa4b. Password: apa4

3. The simulation will start automatically

Executable file:1. Download the executable by either clicking here, to directly download the

executable, or by visiting the CSE435 APA4 Website and clicking on thePrototype hyperlink found in the Links and resources section.

2. Unzip the downloaded file3. Open the unzipped folder4. Navigate to the folder labeled “Windows” and open it5. You will see files that look like this:

6. Double click the Application file named CSE435 APA4Note: You may be prompted by Windows that this is an unverified/unknown file.There’s nothing dangerous contained in it, navigate through the windows promptto show more information & run the application.

40

Page 41: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Startup screen:As displayed in Figure 1, upon running the prototype, the startup screen will be

displayed. From here, the prototype-user can elect to either begin the simulation byclicking the Start button, or exit the program by clicking the Exit button. Both buttonscan be found in the bottom-left portion of the screen.

Figure 1: Prototype Startup Screen

Simulation interface:Once the simulation has been started, the prototype-user will be introduced to the

scenario through a beginning sequence of an automobile approaching a parking lot, asdisplayed in Figure 2. At this point in the simulation, no user-input is required. Thisscene simply serves to introduce the prototype-user to the world in which the simulationis occurring and the interface controls.

Figure 2: Introduction to the Simulation

41

Page 42: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

Once the automobile has come to a stop, the prototype-user’s attention should bedirected toward the mobile phone interface, illustrated in Figure 3, which has changed.For the purposes of this simulation, this interface will serve as the HMI. However, in areal-world scenario, drivers and users of the active parking assistance system wouldeither use the mobile app while remaining outside the vehicle or an in-vehicle HMI whileremaining physically present inside of the vehicle.

Figure 3: Mobile Phone Interface

Now, the prototype-user’s input is required.The user-interface is broken into two distinct parts: the top half, shown in Figure

4,which houses the controls for scenario selection, and the bottom half, in Figure 5,which has viewing, speed, braking, and scenario controls.

Figure 4: Top Controls Figure 5: Bottom Controls Figure 6: Maneuver Selection

Usage of the bottom controls is illustrated below. Please note, these controls areinaccessible if the system is turned off, and will become greyed-out to represent this.❖ Braking: To enable the brakes on the vehicle, click and hold the red button labeled

“Brake”. This will lower the speed of the vehicle, eventually bringing it to a stop -the change in speed will be represented by the speed slider, so that theprototype-user can view everything in real-time. If the vehicle comes to a fullstop, the system will be shut down.

42

Page 43: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

❖ Speed: The speed of the automobile can be controlled by clicking and draggingthe speed slider to the desired speed.

❖ Camera: Four different cameras are available to monitor the simulation. Clickingany of the buttons (“1” through “4”) will bring up the corresponding camera.➢ 1: Bird’s eye view➢ 2: Top of automobile view➢ 3: Front/perspective view➢ 4: Back/rear view

❖ Restart: To restart the simulation from the beginning, click the “Restart” button.❖ Quit: By clicking the “Quit” button, the simulation will end.

To use the top controls, the prototype-user will first be greeted with the option toselect a scenario. Then, depending on the scenario selected, types of parking maneuvers,either perpendicular or parallel parking, will be shown, as illustrated in Figure 6.Clicking on either of these buttons will bring up available options for the correspondingmaneuver, with real-time rendered images of the available spot - both of these arereferenced in Figures 7-8.

Figure 7: Perpendicular Spots Figure 8: Parallel Spots

After selecting a type of maneuver, the user can either opt to select a parking spotfrom the list of available spots, or choose to go back to the maneuver selection menu tochoose a different maneuver to bring up different spots.❖ Spot selection: Click on one of the buttons labeled “Spot x”, where x is the

corresponding numerical value to the spot.❖ Back button: Click on the button labeled “Back” to return to the maneuver

selection menu.

Figure 9: Obstacle Detection

43

Page 44: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

After selecting a spot, the vehicle will autonomously park itself. No user input isrequired, however, the user does still have the ability to control the brakes, speed, andcameras, as long as the vehicle is not currently encountering an obstacle. If the vehicleencounters an obstacle, it stops and waits until the obstacle has passed, then returnscontrol to the user, as illustrated in Figure 9.

Once the obstacle, if present, has passed, and the vehicle has come to a stop in itsselected parking spot, the simulated scenario is over, and the active parking assist systemwill turn itself off. At this point, the prototype-user can elect to either restart thesimulation, to choose a different scenario or replay the current scenario, or exit theprogram.

5.2 Sample Scenarios

There are a variety of scenarios presented in this simulation:1. Regular parking scenarios

3 Regular perpendicular parking scenarios:1. A parking spot found on the left, including an obstacle.2. A parking spot found directly in front of the vehicle.3. A parking spot found on the right, including an obstacle.

2 Regular parallel parking scenarios:1. A parallel parking spot found on the right of the vehicle around a corner.2. A parallel parking spot found on the left of the vehicle around a corner.

2. System failure scenario in which a camera fails.3. Security breach scenario in which a hacker gains access to the vehicle software.

44

Page 45: P roje c t Ac ti ve P ar k As s i s t: Te am 4 S oftware

6 References

[1] C. Cardimen, S. Hasan, C. Lowen, and E. Stevens, “APA4 Project Website,”Active Parking Assist Team 4, Nov-2021. [Online]. Available:http://cse.msu.edu/~cardime2/index.html. [Accessed: 16-Nov-2021].

[2] B. H. C. Cheng, “Project Description.” Michigan State University, EastLansing, Nov-2021.

[3] E. Davidson, “Active Park Assist.” Michigan State University, East Lansing,Nov-2021.

[4] P. Greenberg, “Legislation Related to Artificial Intelligence,” Legislationrelated to Artificial Intelligence, 15-Sep-2021. [Online]. Available:https://www.ncsl.org/research/telecommunications-and-information-technology/2020-legislation-related-to-artificial-intelligence.aspx. [Accessed: 16-Nov-2021].

[5] D. Thakore and S. Biswas, “Routing with Persistent Link Modeling inIntermittently Connected Wireless Networks,” Proceedings of IEEE MilitaryCommunication, Atlantic City, October 2005.

7 Point of ContactFor further information regarding this document and project, please contact Prof.

Betty H.C. Cheng at Michigan State University (chengb at msu.edu). All materials inthis document have been sanitized for proprietary data. The students and the instructorgratefully acknowledge the participation of our industrial collaborators.

45