Team Omni L2 Requirements Revised

Project RIDES
L2 SRS
Team Omni
January 21, 2015
The system requirements detailed within this document are in reference to Project RIDES,
currently in development by Team Omni. All items contained within this document are the
intellectual property of Embry-Riddle Aeronautical University.

L2 System Requirements Speciﬁcation, Rev. 1.3 Revision History
Revision History
Version Date
0.8 November 24, 2014
1.0 November 25, 2014
1.1 December 4, 2014
1.2 January 13, 2015
1.3 January 20, 2015
Project RIDES 1

L2 System Requirements Specification, Rev. 1.3 Contents
Contents
Revision History 1
1 Introduction 6
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Mission Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Team Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Stakeholders 7
2.1 Team Omni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Dr. Garfield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Dr. Barott, Dr. Seker, and Richard Tubbesing . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 ERAU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 High-Level Description 8
3.1 Arena Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Vehicle Operation and Coordinate System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Requirements Considerations 12
4.1 Project Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Operator Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Functional Decomposition of System 14
5.1 Operations Computer Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Vehicle Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6 User Interface Subsystem 16
6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1 Screen Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4 User Interface Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.4.1 Use Case: Start Ride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.4.2 Use Case: Ride Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4.3 Use Case: Resume from Ride Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.4 Use Case: Emergency Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.6 User Interface Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.7 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7 Scheduling Subsystem 29
7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2.1 Real-time Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.3.1 User Interface Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3.2 Static Arena Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3.3 Vehicle Identification Voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.4 Scheduling Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Project RIDES 2

7.4.1 Use Case: Update Vehicle Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4.2 Primary Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4.3 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4.4 Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4.5 Postconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4.6 Main Success Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4.7 Frequency of Occurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.6 Scheduling Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8 Operations Computer I/O Subsystem 36
8.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2.1 Parallel Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.3.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3.3 Vehicle Pathing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.4 Operations Computer I/O Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.4.1 Use Case: Block Section Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.4.2 Use Case: Sensor Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.6 Operations Computer I/O Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . 42
9 Wireless Communications Subsystem 44
9.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.2.1 Module Synchronicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.3.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.4 Wireless Communications Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.4.1 Use Case: Emergency Stop Signalled . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.6 Wireless Communications Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . 48
10 Vehicle Motion Subsystem 50
10.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.2.1 Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.3 Vehicle Motion Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.3.1 Use Case: Motor Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.5 Vehicle Motion Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11 Vehicle Power Subsystem 55
11.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.1 Vehicle Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.2 Electrical Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Project RIDES 3

11.3.1 Batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.4 Vehicle Power Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.4.1 Use Case: Vehicle Power Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.4.2 Use Case: Emergency Stop Power Down . . . . . . . . . . . . . . . . . . . . . . . . . . 58
11.6 Vehicle Power Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12 Vehicle Pathfinding Subsystem 63
12.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
12.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
12.2.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
12.3.1 Magnetic Field Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
12.4 Vehicle Pathfinding Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
12.4.1 Use Case: Path Finding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
12.6 Vehicle Pathfinding Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13 Vehicle Identification Subsystem 70
13.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.2.1 Vehicle Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.3.1 Arena Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.3.2 Arena Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.4 Vehicle Identification Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
13.4.1 Use Case: Changing Block Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
13.6 Vehicle Identification Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 75
14 Obstacle Detection Subsystem 77
14.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
14.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
14.3 Obstacle Detection Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
14.3.1 Use Case: Obstacle Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
14.5 Obstacle Detection Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
15 Project RIDES Requirements 82
15.1 Operations Computer Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 82
15.2 Operations Computer Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 83
15.3 Vehicle Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
15.4 Vehicle Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
15.5 Arena Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
16 Glossary 87
17 Acronyms 89
Project RIDES 4

A Appendix 91
A.1 Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.2 L1 SRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Project RIDES 5

L2 System Requirements Specification, Rev. 1.3 1 Introduction
1 Introduction
1.1 Purpose
The purpose of this document is to define the system requirements for Project Ride Integrating Dynamic
Electronic System (RIDES). These requirements include the functional and non-functional requirements that
the vehicles, Operations Computer, and arena must fulfill upon completion of the project at the end of the
academic year. This document is intended for the consumer, development team, and all other parties involved
with the design, construction, or maintenance of Project RIDES.
1.2 Mission Statement
Project RIDES will have multiple autonomous vehicles that are directed along converging and diverging
pathways without colliding. Ride operations will be controlled by an automated Operations Computer rather
than a human operator.
The autonomous system envisioned is a scale mock-up of an amusement park ride that includes multiple
vehicles, an Operations Computer, and an arena. Project RIDES will have multiple pathways, dynamic speed
control, and sensors that detect obstructions in the vehicles path.
1.3 Scope
This document is a complete list of the requirements to be met by the product of Project RIDES and
does not delve into the technical details of Project RIDES’ design and implementation. An overview of the
system and each subsystem therein is provided. This document expands on the requirements enumerated in
the L1 SRS (included in the appendix) as requirements were written for each subsystem.
1.4 Team Information
The following lists the members of the Project RIDES development team and their roles.
Name Role
Jordan Maziarka Scrum Master, Developer
Alex Spradlin Developer
Andrew Daws Developer
Branden Martin Developer
David Timmons Developer
1.5 Overview
This document is organized into sections to effectively communicate the intended functionalities of
Project RIDES and the project s high-level description to the stakeholders of Project RIDES.
Section 1 of this document serves to introduce the reader to Project RIDES, describing the scope
of the project and the roles of the development team. Section 2 lists the major stakeholders involved
in the development of Project RIDES and their impact on its development. Section 3 provides a high-
level description of the project, including the the arena configuration, vehicle operation, and coordinates
system. Section 4 contains the functional decomposition of the Project RIDES system. This section is
broken into an Operations Computer decomposition, wireless communications decomposition, and the vehicle
decomposition.
Sections 5 through 14 each focus on a different subsystem of the project. Each section includes a de-
scription of the subsystem, the constraints, dependencies, use cases, sequence diagrams, and the requirements
and traceability matrix for the subsystem. Section 15 defines the functional and non-functional requirements
for the vehicles, Operations Computer, and the arena. Section 16 includes a glossary that contains detailed
definitions of industry terms and terms exclusive to this document. Section 17 is a table of all acronyms
used within this document to be used as a quick reference guide to dispel ambiguity.
Project RIDES 6

L2 System Requirements Specification, Rev. 1.3 2 Stakeholders
2 Stakeholders
The following are the individuals and groups that are involved in or have an interest in the development
and completion of Project RIDES.
2.1 Team Omni
Team Omni will be involved in every aspect of the project s development. As the developers of Project
RIDES, the team shall be graded based on the rigor and difficulty of the project as well as its progress
over the year and ultimately, the project s completion. The team will apply knowledge of course content
gained throughout their academic careers attending Embry-Riddle Aeronautical University (ERAU). The
team members will be funding the project and are thus interested in completing it on time and under budget.
2.2 Dr. Garfield
As the project s customer and technical advisor, Dr. Garfield is interested in the completion of Project
RIDES. He will be consulted on a weekly basis and will influence all major design decisions.
2.3 Dr. Barott, Dr. Seker, and Richard Tubbesing
As the overseers of the capstone program, Dr. Barott, Dr. Seker, and Richard Tubbesing shall be
following the team s progress and providing guidance throughout the academic year. They will grade the
team based on their demonstration of the course requirements outlined in the course syllabus [1]. They will
continue to help the team define the scope of the project and will oversee the development process.
2.4 ERAU
ERAU administrators have an interest in student projects because their level of success reflects on
the institution. To ensure the safety of everyone on campus, ERAU requires that project s adhere to the
standards defined in the 2014-2015 Student Handbook [2]. The Student Handbook states that disciplinary
action will ensue when damage is done to public or private property [2:54]. Disciplinary action will also be
given if Team Omni is found in possession of items considered dangerous, including incendiary devices and
tools such as chain saws [2:53].
Project RIDES 7

L2 System Requirements Specification, Rev. 1.3 3 High-Level Description
3 High-Level Description
This section introduces Project RIDES. It provides the reader with an explanation of the terms used
further in this document and context the reader needs to understand the requirements and subsystems
detailed in proceeding sections.
3.1 Arena Configuration
The arena will consist of multiple block sections separated into several main areas and connected to
one another by three switches. The first of the main areas is the station area that houses multiple station
platforms. Station platforms serve as the locations where Project RIDES will simulate passengers entering
and leaving vehicles in amusement park rides. Ride vehicles can travel along the station area path to reach
the station platforms, station-to-path (STP) switch, and the maintenance bay. The arena will have at least
two pathways that will serve as the main section of one circuit between station platforms. Each of the main
pathways will consist of at least three block sections. Finally, the maintenance bay will act as the location
that vehicles reside in prior to ride initialization. The maintenance bay is split into several block sections to
accommodate all ride vehicles.
The main switches include the STP switch that connects the station area to the pathways and to
the maintenance bay, the path-to-station (PTS) switch that connects the pathways to the other end of the
station area, and the maintenance-to-path (MTP) switch that connects the maintenance bay to the pathway
labeled Pathway 2 in Figure 1. A possible layout of the areas, switches, and block sections are shown in
Figure 1.
Figure 1: Diagram of a possible layout of the arena with all the main areas listed in letters and the main
switches listed in numbers. The block sections are separated by small lines perpendicular to the pathways.
Project RIDES will operate on a moving block-light system. This system is a form of block system.
The simple block system allows one vehicle to occupy a block section, and a vehicle can only progress when
the block section ahead of it is unoccupied. The moving block-light system requires at least one more block
section between two vehicles than a simple block system requires. The defining rule in a moving block-light
system is that there must always be at least one block section separating all ride vehicles. Ideally, three or
Project RIDES 8

more block sections separate a vehicle from the vehicle in front of it. If this is the case, the vehicle behind can
progress at full speed (deﬁned within the Operations Computer subsystem). When only two block sections
separate two vehicles, the vehicle in back slows down enough that the distance between the two vehicles
increases in block sections. If only one block section separates two vehicles, the vehicle in back should stop
and wait until more block sections separate the vehicles. In the event that two ride vehicles occupy adjacent
block sections, the entire ride should emergency stop. The diﬀerent states of the moving block-light system
are illustrated in Figure 2.
Figure 2: Diagram of the possible states for a ride vehicle in the moving block-light system, where the circles
represent the ride vehicles and the black vertical lines represent block section separations.
While in the maintenance bay, a vehicle can be added or removed from ride operations to be serviced
by the operator. The arrangement of the maintenance bay is shown in Figure 3.
Project RIDES 9

Figure 3: Depiction of the pathway inside the maintenance bay on which three vehicles (labeled V1, V2,
and V3) are each separated by one block section as required by the moving block-light system. The blocks
shown are not to scale.
3.2 Vehicle Operation and Coordinate System
Ride vehicles operating in the arena have a local coordinate system to deﬁne their location relative
to the path they are following. In this system, a forward movement along the path is a change of position
in the positive x direction. A 90 degree clockwise rotation from the positive x-axis would face the positive
y-axis. The origin for this coordinate system is the vehicle s center of mass. The arrangement is illustrated
in Figure 4.
Figure 4: Diagram of the local coordinate system of a ride vehicle. The orientation of the axes is based on
the current direction of the vehicle s motion. The positive x-axis lies along the direction of movement. The
center of the coordinate system is the vehicle s center of mass.
Under normal operation, ride vehicles progress as long as they detect the path beneath them and there
are no obstacles in front of them. The path they take is determined by which block sections are supplied
current by the Operations Computer. Each vehicle can simultaneously scan for obstacles and detect current
beneath it. The safety of this system is ensured by the Operations Computer s direction of the vehicles.
When the ride is initialized or after the vehicle has reached its target block section, the Operations Computer
determines the farthest block section ahead of the vehicle to which it can safely travel without stopping to
avoid another vehicle. This block section is called the vehicle s target location. When a vehicle s target
location is set to a block section, that block section is considered eﬀectively occupied, which means that even
Project RIDES 10

though no vehicle currently occupies the block section, a vehicle will be entering the block section shortly
and no other vehicle should attempt to travel to that block section. The target location of a vehicle can
only be set to eﬀectively unoccupied block sections, meaning that the block section is not occupied and not
eﬀectively occupied. The normal operation of the vehicles can be interrupted by an obstacle, a ride stop, or
an emergency stop.
A ride stop is a function of a ride s control system that causes all vehicles to stop and remain stopped
until further notice. In amusement parks, an operator may choose to call a ride stop when a rider loses a
personal possession on the ride or needs to have their harness adjusted. The operator can choose to resume
the ride after triggering a ride stop, and the ride will proceed as normal.
Emergency stops are used to stop the ride in such a manner that the ride will only operate again with
direct intervention from an operator. Typically, this must be reset by power cycling the ride [3]. In an
amusement park, an operator can choose to call an emergency stop if a danger is present to the riders or
one of the vehicles is not operating. The Operations Computer can also call an emergency stop if it detects
one of these events occurring.
Project RIDES 11

L2 System Requirements Specification, Rev. 1.3 4 Requirements Considerations
4 Requirements Considerations
This section discusses the high-level assumptions made during the requirements process of Project
RIDES, the criterion that must be met before development, and what constraints are placed on development.
4.1 Project Constraints
The following are constraints defined by external sources that limit the development of Project RIDES
in accordance with the requirements enumerated further into this document.
4.1.1 Regulation Constraints
Project RIDES is envisioned to be a scale mock-up of an amusement park ride that would be used
for the enjoyment of passengers. Therefore, Project RIDES will be developed with consideration towards
the design standards for amusement park rides defined in ASTM F2291-14 that are unrelated to passengers
physically occupying the ride vehicles [4]. The regulations involving passenger safety are disregarded because
implementing features to meet them are impossible with the limited budget. The budget constrains the size
of the vehicles to be constructed. Regulations defined in ASTM F2291-14 specify minimum weight support
and require that ride vehicles are equipped with harnesses for the passengers. The small vehicle size prevents
Project RIDES from adhering to these regulations. The regulation will be met that specifies a minimum
separation between two vehicles in terms of the size of each vehicle. This specification applies during ride
operation but not for vehicles located in the maintenance bay.
4.1.2 Parallel Operation
The operation of Project RIDES is dependent on the ride vehicles operating in parallel with the
Operations Computer. After issuing instructions to the ride vehicles, the Operations Computer should
continue to instruct and monitor each vehicle.
4.1.3 Budget
Project RIDES is funded entirely by the student development team. The financial resources available
to the team are limited to approximately $1000. This constraint limits the development of Project RIDES
to a small number of vehicles unrepresentative of full-scale amusement park rides and limits the accuracy
with which the Operations Computer tracks the vehicles across block sections.
4.1.4 Schedule
Project RIDES must be completed by mid-May of 2015 for the sake of the grades of all Team Omni
members. The development of Project RIDES began in late August of 2014, so a total of 9 months were avail-
able for development. The scope of the project was made small enough that the goal of project completion
remains ambitious but attainable.
4.2 Assumptions and Dependencies
The following are assumptions made during the requirements extraction process of Project RIDES and
the project s dependencies.
4.2.1 Operation within the US
This project will take note of current standards for design of amusement park attractions by taking
note of attempting to adhere to standards as created by ASTM Committee F24 (Committee for Amusement
Rides and Devices). Specifically we will be designing our systems to take not of ASTM standard 2291
(Standard Practice for Design of Amusement Rides and Devices). It will also adhere to standards that are
present on US based rides based on operations of US theme parks, hence Project RIDES will have a US
focus operations wise.
Project RIDES 12

L2 System Requirements Speciﬁcation, Rev. 1.3 4 Requirements Considerations
4.3 Operator Characteristics
As Project RIDES is currently envisioned, a post-secondary education will not be necessary to operate
the system. The operator of Project RIDES will need a general knowledge of amusement park ride operations,
including the high-level sequence of events that occurs during a ride s operation: a vehicle loads passengers,
the vehicle travels around the ride arena alongside other vehicles, the vehicle unloads passengers. The
operator must also know in what situations ride stops and emergency stops should be triggered. Project
RIDES is a simpliﬁed mock-up of an amusement park ride, so the situations requiring either a ride stop or
an emergency stop are few in number.
Project RIDES 13

L2 System Requirements Speciﬁcation, Rev. 1.3 5 Functional Decomposition of System
5 Functional Decomposition of System
Project RIDES is decomposed into two separate subsystems, the Operations Computer and the vehicle.
The Operations Computer is the brains of the system. It includes a user interface and calculate the speed and
path for each vehicle. The vehicle is a slave, following all directions from the Operations Computer and can
only move forwards and stop. The two subsystems communicate through the use of wireless communication,
vehicle block sensors and inductive line following.
Figure 5: Illustration of the major subsystems of Project RIDES. Overlapping sections indicate that infor-
mation may ﬂow between those two subsystems.
5.1 Operations Computer Decomposition
Figure 6 shows a high-level decomposition of the Operations Computer Subsystem. The subsystems
within includes the I/O Subsystem and the Wireless Communications Subsystem, which outputs a signal to
the vehicle when an emergency stop is triggered.
Figure 6: High-level block diagram for the Operations Computer Subsystem. This shows all major compo-
nents and subsystems encompassed by the Operations Computer and the immediate communication subsys-
tems that is is connected to.
The Operations Computer Subsystem includes three main parts. The User Interface Subsystem allows
the operator to initialize the ride, trigger emergency stops, trigger ride stops, reset ride stops, and observe
the state of each block section. The Operations Computer I/O Subsystem interacts with the arena directly,
sending current through the wires to control the vehicles while receiving the location of each vehicle through
arena sensors. The Scheduling Subsystem is the middle man; it connects the operator with the arena by
connecting the User Interface Subsystem with the Operations Computer I/O Subsystem. The Scheduling
Project RIDES 14

L2 System Requirements Specification, Rev. 1.3 5 Functional Decomposition of System
Subsystem uses input from the arena to direct each vehicle independently by commanding the Operations
Computer I/O Subsystem to output a current through a specific wire. The Operations Computer Subsystem
fulfills requirements 15.1.1 through 15.1.22.
5.2 Vehicle Decomposition
The vehicles are split into six major subsystems that are connected to each other by a microcontroller.
Each subsystem deals with a separate part of the vehicle’s navigation. The Vehicle Power Subsystem is the
base, providing the power to all other subsystems while also allowing the functionality of cutting power via
a relay. The Vehicle Motion Subsystem includes the motors and allows the vehicle to proceed forward, turn,
and stop. This subsystem requires input, which is provided by the Pathfinding Subsystem, which reads the
magnetic field from the arena wire and determines the direction in which the vehicle must proceed. The
Pathfinding Subsystem also accepts input from the Obstacle Detection Subsystem, which stops the vehicle
when an obstruction is detected. The other two subsystems are in direct communication with the Operations
Computer. The Vehicle Identification Subsystem allows the Operations Computer to determine the location
of each vehicle independently while the Wireless Communications Subsystem receives commands from the
Operations Computer such as an emergency stop.
Figure 7: High-level block diagram for the vehicle subsystem. This diagram includes all the major com-
ponents and subsystems encompassed by the vehicle and the communication systems that the vehicle is
connected to.
Project RIDES 15

L2 System Requirements Speciﬁcation, Rev. 1.3 6 User Interface Subsystem
6 User Interface Subsystem
6.1 Description
The User Interface Subsystem is responsible for providing the operator with the ability to trigger ride
stops, to trigger emergency stops, and to initialize the ride. The User Interface Subsystem will be a graphical
user interface run from an application.
Figure 8: Block diagram for the User Interface Subsystem. This includes the user interface that the operator
interfaces with and the processor used to process the inputs.
Figure 9: Flow diagram showing how the user interface communicates with the operator and the Operations
Computer I/O subsystem.
Project RIDES 16

Figure 10: An example user interface that includes options for the operator to start the ride, trigger a ride
stop, and trigger an emergency stop. Grey buttons indicate that the option is disabled. The left side shows
the user interface before the ride has been started. The right side shows the user interface after the ride has
been started. After the ”Init Ride” button is pressed, it is disabled, and the two remaining buttons become
available.
6.2 Constraints
The following are constraints deﬁned by external sources that limit the development of the User Inter-
face Subsystem in accordance with the requirements listed in this document.
6.2.1 Screen Size
The user interface will most likely run on a tablet for portability and ease of use. The average tablet
screen has a height between 7” and 11” and a width between 5” and 7” [5]. A small screen size requires
that only pertinent information to the operator be included in the user interface, so that they can navigate
options easily and perform tasks quickly.
The following are assumptions made during the design of the user interface and the subsystem’s de-
pendencies.
6.3.1 Platform
The operating system is assumed to be Android because no examples of iOS tablets interfacing with
microcontrollers have been found in the team’s research. This will determine how the application is developed.
Cross-platform development is an option, but may be beyond the scope of this project.
Project RIDES 17

6.4 User Interface Subsystem Use Cases
The following use cases describe the sequence of steps that occur when the operator starts the ride,
triggers a ride stop, triggers an emergency stop, or restarts the ride after a ride stop has been triggered. The
main success scenario describes what happens within the system when nothing unexpected happens. The
extensions describe alternatives to the sequence of events listed in the main success scenario. Extensions
labeled with a * can occur at any point within the main success scenario.
6.4.1 Use Case: Start Ride
6.4.1.1 Primary Actors
1. Operator
6.4.1.2 Description
The operator starts the ride from the user interface, and the Operations Computer begins to power
block sections on the arena.
6.4.1.3 Preconditions
1. The ride application is running.
2. The option to start the ride is available on the user interface.
3. The Operations Computer is in the ready state.
4. The vehicles are oﬀ.
6.4.1.4 Postconditions
1. The Operations Computer is powering block sections.
2. Each vehicle occupies a station platform.
3. The vehicles are in the ready state.
4. The option to start the ride is disabled on the user interface.
5. The option to emergency stop the ride is available on the user interface.
6. The option to ride stop the ride is available on the user interface.
6.4.1.5 Main Success Scenario
1. The operator positions each vehicle in the maintenance bay.
2. The operator orients the vehicles so that each of their x-axis points in the direction of the MTP switch.
3. The operator powers on the vehicles.
4. The operator chooses the start ride option on the user interface.
5. The Operations Computer provides power to the indicated blocks (see Use Case: Block Section Out-
put).
6.4.1.6 Frequency of Occurrence
This use case will occur each time the ride begins. If an emergency stop is triggered, this use case
repeats after the situation leading to the emergency stop has been resolved, meaning that the operator will
physically move the vehicles back into the maintenance bay.
Project RIDES 18

6.4.2 Use Case: Ride Stop
1. Operator
6.4.2.2 Description
The operator triggers a ride stop from the user interface, and the vehicles slow to a halt.
3. The option to ride stop is available on the user interface.
4. The vehicles are powered up (see Use Case: Start Ride).
5. The Operations Computer is sending signals to the vehicles wirelessly.
1. The vehicles are stationary.
2. The option to ride stop on the user interface is disabled.
1. The operator chooses the ride stop option on the user interface.
2. The Operations Computer stops providing power to all block sections.
3. The vehicles each slow to a halt.
This use case will occur approximately once an hour on an amusement park ride. These stops are
triggered when riders lose personal possessions on the ride or need to have their harness adjusted.
Project RIDES 19

6.4.3 Use Case: Resume from Ride Stop
1. Operator
6.4.3.2 Description
The operator resets a ride stop by instructing the Operations Computer to resume the ride.
2. The vehicles are in the ready state (see Use Case: Start Ride).
4. The option to resume the ride is available on the user interface.
5. The Operations Computer is not powering block sections.
6. The vehicles are ride stopped.
1. The vehicles are not ride stopped.
2. The option to ride stop is available on the user interface.
1. The operator chooses the resume from ride stop option on the user interface.
2. The vehicles resume Use Case: Ride Cycle from SRS L1.
This use case will occur after every ride stop except in cases in which an emergency stop is called
during a ride stop (see Use Case: Ride Stop and Use Case: Emergency Stop).
Project RIDES 20

6.4.4 Use Case: Emergency Stop
1. Operator
2. Operations Computer
6.4.4.2 Description
The operator or Operations Computer triggers an emergency stop, and the vehicles halt and power
down.
2. The option to emergency stop is available on the user interface.
1. The vehicles are powered down.
2. The option to emergency stop is disabled on the user interface.
3. The option to ride stop is disabled on the user interface.
4. The option to start the ride is disabled on the user interface.
1. The operator chooses the emergency stop option on the user interface.
2. The Operations Computer sends an emergency stop message to the vehicles.
3. Each vehicle receives the message.
4. Each vehicle slows to a halt.
5. Each vehicle powers down.
6.4.4.6 Extensions
3a. A vehicle does not receive the message sent by the Operations Computer.
1. The operator manually turns oﬀ the vehicle.
This use case will occur approximately once a day on an amusement park ride. For this project, this
will occur every time the ride ends.
Project RIDES 21

6.5 Sequence Diagrams
The following system sequence diagrams illustrate the sequence of events occurring in each use case
elaborated in Section 6.4.
6.5.0.8 Use Case: Start Ride
The sequence diagram illustrated in Figure 11 shows the steps that occur when the ride is started.
After the operator turns on the vehicles, places the vehicles in the maintenance bay, and chooses the option
to start the ride from the user interface, the Operations Computer begins powering block sections.
Figure 11: Sequence Diagram for the Use Case: Start Ride
Project RIDES 22

6.5.0.9 Use Case: Ride Stop
The sequence diagram illustrated in Figure 12 shows the steps that occur when a ride stop is triggered.
After the operator triggers a ride stop from the user interface, the Operations Computer stops powering
block sections. Consequently, the vehicles slow to a halt.
Figure 12: Sequence Diagram for the Use Case: Ride Stop
Project RIDES 23

6.5.0.10 Use Case: Resume from Ride Stop
The sequence diagram illustrated in Figure 13 shows the steps that occur when the ride is reset from a
ride stop. The operator chooses the resume from ride stop option from the user interface, and the Operations
Computer resumes powering block sections.
Figure 13: Sequence Diagram for the Use Case: Resume from Ride Stop
Project RIDES 24

6.5.0.11 Use Case: Emergency Stop
The sequence diagram illustrated in Figure 14 shows the steps that occur when an emergency stop is
triggered. After an emergency stop is triggered, the Operations Computer stops powering block sections and
wirelessly sends a message to all vehicles to power down.
Figure 14: Sequence Diagram for the Use Case: Emergency Stop
Project RIDES 25

6.6 User Interface Subsystem Requirements
Requirement Description
15.1.1 The Operations Computer shall initialize the ride.
15.1.2 The Operations Computer shall trigger ride stops.
15.1.3 The Operations Computer shall reset ride stops.
15.1.4 The Operations Computer shall trigger emergency stops.
15.1.5 The Operations Computer shall provide a graphical user interface.
15.1.6
The graphical user interface shall provide the operator with the option to trigger an
emergency stop.
15.1.6.1
The option to trigger an emergency stop shall be disabled until the ride has been
initialized.
15.1.7
The graphical user interface shall provide the operator with the option to trigger a
ride stop.
15.1.7.1 The option to trigger a ride stop shall be disabled until the ride has been initialized.
15.1.7.2
The option to trigger a ride stop shall be disabled after a ride stop was previously
triggered and the ride has not yet been reinitialized.
15.1.8
The graphical user interface shall provide the operator with the option to initialize
the ride.
15.1.8.1
The option to initialize the ride shall be disabled after the ride has been initialized
until the operator ends the ride.
Table 1: Requirements pertaining to the User Interface Subsystem.
Project RIDES 26

6.7 Traceability Matrix
L2 Requirement L1 Requirement Derived From Notes
Redacted
7.2.1.1: The Operations Computer
shall verify that each vehicle’s power
source is enabled before ride initializa-
tion
With the current design, this is
not possible. Communication is
one-way: from the operations
computer to the vehicle.
15.1.1: The Operations Computer
shall initialize the ride.
shall initialize the ride.
No change
Redacted
7.2.1.5.1: The Operations Computer
shall allow an operator to initialize the
ride.
This requirement was redundant
due to 15.1.1 and 15.1.8.
shall trigger ride stops.
shall trigger ride stops.
No change
Redacted
shall provide the operator with the abil-
ity to trigger a ride stop.
due to 15.1.2 and 15.1.7.
shall reset ride stops.
shall reset ride stops.
No change
Redacted
shall provide the operator with the op-
tion to reset a ride stop.
due to 15.1.3.
shall trigger emergency stops.
shall trigger emergency stops.
No change
Redacted
shall provide the operator with the abil-
ity to trigger an emergency stop.
due to 15.1.4 and 15.1.6.
shall provide a graphical user interface.
None Added
15.1.6: The graphical user interface
tion to trigger an emergency stop.
None Added
15.1.6.1: The option to trigger an
emergency stop shall be disabled until
the ride has been started.
None Added
tion to trigger a ride stop.
None Added
15.1.7.1: The option to trigger a ride
stop shall be disabled until the ride has
been started.
None Added
15.1.7.2: The option to trigger a ride
stop shall be disabled after a ride stop
was previously triggered and the ride
has not yet been reinitialized.
None Added
Project RIDES 27

tion to initialize the ride.
None Added
15.1.8.1: The option to start the ride
shall be disabled after the ride has been
started until the operator ends the ride.
None Added
Table 2: The traceability matrix linking each L2 User Interface Subsystem requirement to its relevant L1
requirement. This includes an explanation of the reason behind each change.
Project RIDES 28

L2 System Requirements Speciﬁcation, Rev. 1.3 7 Scheduling Subsystem
7 Scheduling Subsystem
7.1 Description
The Scheduling Subsystem consists of the program that determines the target location of each vehicle
independently. The subsystem receives input from the Operations Computer I/O Subsystem about vehicle
locations within the arena. Based on this information, it calculates which block sections should be powered
and outputs the information back to the Operations Computer I/O Subsystem. It also determines when a
vehicle should visit a station platform and the duration of the stop.
Figure 15: Block diagram for the Scheduling Subsystem. The subsystem includes the scheduling programm
itself and the processor that runs the code durring operation.
Figure 16: Flow diagram for the Scheduling Subsystem. The subsystem is in direct communication with the
user interface, communication with the Input/Output done externally to the mircoprocessor.
7.2 Constraints
7.2.1 Real-time Application
The Scheduling Subsystem must make decisions quickly on which block sections to power so that a
vehicle does not approach the end of a block section and halt because the proceeding block section is not
yet powered. This would occur if the Operations Computer I/O Subsystem had not received the command
to power the next block section from the Scheduling Subsystem.
Project RIDES 29

7.3.1 User Interface Multithreading
The program runs concurrently with the user interface threads. Should an error occur within the User
Interface Subsystem, the Scheduling Subsystem shall cease to function and may output erroneous data to
the Operations Computer I/O Subsystem. Should this happen, the operator will be responsible for manually
resetting the program and ensuring that the vehicles halt or power down.
7.3.2 Static Arena Layout
The assumption is made that the layout of arena block sections, the placement of the maintenance bay,
and the placement of station platforms remains unchanging during the course of a ride session. When changes
to the arena layout are made, the arena representation within the subsystem must be manually updated
to reflect the new configuration. The subsystem requires knowledge of which block sections correspond to
which sensor inputs from the Operations Computer I/O Subsystem and which block sections are connected
end-to-end.
7.3.3 Vehicle Identification Voltage
The subsystem must have an identifying voltage hard coded for each vehicle. The identifying voltage
is read when each vehicle passes over a sensor on the arena, updating the location of each specific vehicle.
Project RIDES 30

7.4 Scheduling Subsystem Use Cases
The following use case describes the sequence of steps that occur within the Scheduling Subsystem
when a vehicle passes over an arena sensor. The main success scenario describes what happens within the
system when nothing unexpected happens. The extensions describe alternatives to the sequence of events
listed in the main success scenario. Extensions labeled with a * can occur at any point within the main
success scenario.
7.4.1 Use Case: Update Vehicle Location
7.4.2 Primary Actors
7.4.3 Description
A vehicle passes over an arena sensor and the Operations Computer updates its knowledge of the
vehicle’s location and changes which block sections are being powered.
7.4.4 Preconditions
2. The ride is initialized.
3. The vehicles are in motion.
7.4.5 Postconditions
1. The Operations Computer knows which block section the vehicle occupies.
7.4.6 Main Success Scenario
1. The vehicle travels along the path.
2. The vehicle passes over a sensor.
3. The vehicle triggers the sensor.
4. The sensor sends a signal with the vehicle’s identiﬁcation voltage back to the Operations Computer
I/O Subsystem.
5. The scheduling program checks the vehicle’s identiﬁcation to determine which vehicle triggered the
sensor.
6. The scheduling program updates the vehicle’s location in the hard-coded arena representation.
7. The scheduling program calculates which block sections to power.
8. The scheduling program tells the Operations Computer I/O Subsystem which block sections to power.
7.4.7 Frequency of Occurance
This use case will occur each time a vehicle enters or leaves a block section, which will happen several
times a minute.
Project RIDES 31

7.5.0.1 Use Case: Update Vehicle Location
The sequence diagram illustrated in Figure 17 shows the steps that occur within the Scheduling Sub-
system when a vehicle passes over an arena sensor. The Operations Computer I/O Subsystem receives input
from the arena sensor and informs the scheduling program, which updates its knowledge of vehicle locations
and decides which block sections should be powered.
Figure 17: Sequence Diagram for the Use Case: Update Vehicle Location
Project RIDES 32

7.6 Scheduling Subsystem Requirements
15.1.4.1
The Operations Computer shall trigger an emergency stop if a vehicle, not currently
at a station platform, fails to reach the end of the currently occupied block section
within 30 s of the expected time.
15.1.4.2 The expected time shall be calculated by the Operations Computer.
15.1.9
The Operations Computer shall direct vehicles out of the maintenance bay when the
ride is initialized.
15.1.11
The Operations Computer shall set the vehicle’s target location to an eﬀectively
unoccupied block section after initialization.
15.1.12
The Operations Computer shall set the vehicle’s target location to an eﬀectively
unoccupied block section upon the vehicles arrival at its previous target location.
15.1.13 The Operations Computer shall instruct a vehicle to the target location of that vehicle.
15.1.14
The Operations Computer shall instruct vehicles in such a way that at least one block
section separates all vehicles.
15.1.15 The Operations Computer shall detect the vehicle entering a block section.
15.1.15.1 The Operations Computer shall detect which block section the vehicle is entering.
15.1.16 The Operations Computer shall detect the vehicle departing a block section.
15.1.16.1 The Operations Computer shall detect which block section the vehicle is departing.
15.1.17 The Operations Computer shall track the occupancy states of all station platforms.
15.1.19
The Operations Computer shall stop providing the vehicle with suggested movement
speeds when the vehicle enters a station platform.
15.1.20
The Operations Computer shall provide a suggested movement speed to the vehicle
with regard to the number of blocks separating the vehicle from the vehicle in front
of it along the vehicle’s pathway.
15.1.20.1
The Operations Computer shall provide a suggested movement speed of 0 cm/s for
the vehicle when the vehicle has 1 block section separating itself and the vehicle in
front of it.
15.1.20.2
The Operations Computer shall direct a vehicle’s movement speed to be less than 5
cm/s when the vehicle has 2 block sections separating itself and the vehicle in front
of it.
15.1.20.3
The Operations Computer shall direct a vehicle’s movement speed to be 15 cm/s
when the vehicle has 3 or more block sections separating itself from the vehicle in
front of it.
15.1.21
The Operations Computer shall direct the vehicle with the lower priority level to
decrease its speed when the vehicle is the same number of block sections behind the
PTC switch as a vehicle on another pathway.
15.3.1 The vehicle shall follow the pathway selected by the Operations Computer.
Table 3: Requirements pertaining to the Scheduling Subsystem.
Project RIDES 33

15.1.4.1: The Operations Com-
puter shall trigger an emergency
stop if a vehicle, not currently at
a station platform, fails to reach
the end of the currently occupied
block section within 30 s of the
expected time.
7.2.1.7.2: The Operations
Computer shall trigger an emer-
gency stop if a vehicle, not
currently at a station platform,
fails to reach the end of the
currently occupied block sec-
tion within 30 s [TBR] of the
expected time.
No change
15.1.4.2: The expected time
shall be calculated by the Oper-
ations Computer.
7.2.1.7.3: The expected time
shall be determined by the Op-
erations Computer.
”determined” was replaced with
”calculated” because the word
better fits the situation.
15.1.9: The Operations Com-
puter shall direct vehicles out of
the maintenance bay when the
puter shall direct vehicles out of
the maintenance bay when the
No change
puter shall set the vehicle’s tar-
get location to an effectively un-
occupied block section.
Computer shall set the vehicle’s
target location to an effectively
unoccupied block section.
No change
puter shall instruct a vehicle to
the target location of that vehi-
cle.
puter shall instruct a vehicle to
the target location of that vehi-
cle.
No change
puter shall instruct vehicles in
such a way that at least one block
section separates all vehicles.
puter shall instruct vehicles in
such a way that at least one
block section separates all vehi-
cles when the vehicles are not in
the maintenance bay.
The part of the L1 requirement
that was removed was redun-
dant.
puter shall detect the vehicle en-
tering a block section.
No change
15.1.15.1: The Operations
Computer shall detect which
block section the vehicle is
entering.
block section the vehicle is enter-
ing.
No change
puter shall detect the vehicle de-
parting a block section.
puter shall detect the vehicle ex-
iting a block section.
”exiting” was replaced with ”de-
parting” because the word better
fits the situation.
departing.
exiting.
”exiting” was replaced with ”de-
parting” because the word better
fits the situation.
puter shall track the occupancy
states of all station platforms.
puter shall track which sta-
tion platforms are occupied and
which are unoccupied.
Changed to be more concise, but
the meaning remains unchanged.
Project RIDES 34

puter shall stop providing the ve-
hicle with suggested movement
speeds when the vehicle enters a
station platform.
puter shall stop providing the ve-
hicle with suggested movement
speeds when the vehicle enters a
station platform.
No change
puter shall provide a suggested
movement speed to the vehi-
cle with regard to the number
of blocks separating the vehicle
from the vehicle in front of it
along the vehicle’s pathway.
movement speed to the vehi-
cle with regard to the number
of blocks separating the vehicle
from the vehicle in front of it
along the vehicle’s pathway.
No change
Computer shall provide a sug-
gested movement speed of 0
cm/s for the vehicle when the
vehicle has 1 block section
separating itself and the vehicle
in front of it.
Computer shall provide a sug-
gested movement speed of 0 cm/s
for the vehicle when the vehicle
has 1 block section separating it-
self and the vehicle in front of it.
No change
Computer shall direct a vehicle’s
movement speed to be less than
5 cm/s when the vehicle has 2
block sections separating itself
and the vehicle in front of it.
movement speed to be less than 5
cm/s [TBR] when the vehicle has
2 block sections separating itself
and the vehicle in front of it.
No change
15.1.20.3:. The Operations
movement speed to be 15 cm/s
when the vehicle has 3 or more
block sections separating itself
from the vehicle in front of it.
movement speed to be 15 cm/s
[TBR] when the vehicle has 3
or more block sections separating
itself from the vehicle in front of
it.
No change
puter shall direct the vehicle
with the lower priority level to
decrease its speed when the vehi-
cle is the same number of block
sections behind the PTC switch
as a vehicle on another pathway.
puter shall direct the vehicle
with the lower priority level to
decrease its speed when the vehi-
cle is the same number of block
sections behind the PTC switch
as a vehicle on another pathway.
No change
15.3.1: The vehicle shall follow
the pathway selected by the Op-
erations Computer.
7.1.1.6: The vehicle shall follow
erations Computer.
No change
Table 4: The traceability matrix linking each L2 Scheduling Subsystem requirement to its relevant L1
Project RIDES 35

L2 System Requirements Specification, Rev. 1.3 8 Operations Computer I/O Subsystem
8 Operations Computer I/O Subsystem
8.1 Description
The Operations Computer I/O Subsystem is responsible for outputting PWM signal to the arena’s
block sections. This signal is used by the vehicle’s Pathfinding Subsystem. The subsystem is also used to
gather input from the sensors placed throughout the arena. These sensors are used to identify each vehicle,
which are read into the Operations Computer to know the relative position of each vehicle.
Figure 18: Block diagram for the Operations Computer I/O Subsystem. This encompases all of the major
components needed for the subsystem to function, but does not list the subsystems that it communicates
with.
Figure 19: Flow diagram showing how the Operations Computer I/O Subsystem communicates with the
Scheduling Subsystem and the arena.
8.2 Constraints
The following are constraints defined by external sources that limit the development of the Operations
Computer I/O Subsystem in accordance with the requirements listed in this document.
For the Operations Computer I/O to work correctly, the block sections in the arena and the sensor
inputs must work asynchronously with other operations. Each block section must be independent of the
Project RIDES 36

others, allowing a complete path to be created for each vehicle while still allowing the inputs from the
sensors to be taken immediately.
The following are assumptions made during the design of the Operations Computer I/O Subsystem
and the subsystem’s dependencies.
8.3.1 Power
This subsystem is dependent on both the Operations Computer and the vehicles receiving power from
their respective power subsystems in order to operate.
8.3.2 Communication
This subsystem is dependent upon receiving input from the user interface in order to know when to
start outputting and receiving data.
8.3.3 Vehicle Pathing
This subsystem assumes that the vehicles themselves can operate with very limited inputs. The Oper-
ations Computer only outputs a signal to the vehicles; it does not directly control each vehicle. If the vehicle
pathing does not work correctly, the Operations Computer can only detect the problem, it cannot help to
resolve it.
Project RIDES 37

8.4 Operations Computer I/O Subsystem Use Cases
The following use cases describe the sequence of steps that occur while the Operations Computer
provides power to block sections and detects vehicles crossing arena sensors. The main success scenario
describes what happens within the system when nothing unexpected happens. The extensions describe
alternatives to the sequence of events listed in the main success scenario. Extensions labeled with a * can
occur at any point within the main success scenario.
8.4.1 Use Case: Block Section Output
1. Operations computer
8.4.1.2 Description
The Operations Computer outputs a signal to the arena block sections. The vehicle then interprets
the signal from the block section it occupies and changes speed based on the input.
1. The Operations Computer determines the speed at which the vehicle should travel.
2. The Operations Computer outputs signals that include speed information to speciﬁc block sections.
3. The vehicle reads the signal from the arena block section that it occupies.
4. The vehicle processes the signal.
5. The vehicle proceeds along the arena at the speed communicated through the signal.
8.4.1.6 Extensions
5a. A vehicle does not move when current is supplied to the block section it occupies.
1. The operator triggers an emergency stop (see Use Case: Emergency Stop).
This use case will occur continuously after the ride has been started except during a ride stop or
emergency stop.
Project RIDES 38

8.4.2 Use Case: Sensor Input
8.4.2.2 Description
The Operations Computer receives input from a vehicle when it passes over an arena sensor.
2. The Operations Computer knows which block section the vehicle occupies.
1. The vehicle receives the signal from the Operations Computer (see Use Case: Path Finding).
2. The vehicle travels along the path.
3. The vehicle passes over a sensor.
4. The vehicle triggers the sensor.
5. The sensor sends a signal back to the Operations Computer.
6. The Operations Computer processes which sensor was triggered and by which vehicle.
8.4.2.6 Extensions
5a. A vehicle does not move when current is supplied to the block section it occupies.
1. The operator triggers an emergency stop (see Use Case: Emergency Stop).
This use case will occur each time a vehicle enters or leaves a block section, which will happen several
times a minute.
Project RIDES 39

8.5.0.8 Use Case: Block Section Output
The sequence diagram illustrated in Figure 20 shows the steps that occur while the Operations Com-
puter powers a block section. The vehicle occupying the block section detects the current running through
the wire beneath it and runs its motors based on the input.
Figure 20: Sequence Diagram for the Use Case: Block Section Output
Project RIDES 40

8.5.0.9 Use Case: Sensor Input
The sequence diagram illustrated in Figure 21 shows the steps that occur when a vehicle passes over a
sensor, and the Operations Computer receives input from the sensor tripped.
Figure 21: Sequence Diagram for the Use Case: Sensor Input
Project RIDES 41

8.6 Operations Computer I/O Subsystem Requirements
15.1.15 The Operations Computer shall detect the vehicle entering a block section.
15.1.15.1 The Operations Computer shall detect which block section the vehicle is entering.
15.1.16 The Operations Computer shall detect the vehicle departing a block section.
15.1.16.1 The Operations Computer shall detect which block section the vehicle is departing.
15.1.18 The Operations Computer shall provide a suggested movement speed to the vehicle.
15.3.1 The vehicle shall follow the pathway selected by the Operations Computer.
15.3.2
The vehicle shall move along the vehicle’s positive x-axis when the vehicle receives an
input from the Operations Computer and does not detect an obstruction
15.3.3
The vehicle’s on-board computer shall receive instructions from the Operations Com-
puter.
Table 5: Requirements pertaining to the Operations Computer I/O Subsystem.
Project RIDES 42

puter shall initialize the ride.
puter shall initialize the ride.
No change
No change
entering.
block section the vehicle is enter-
ing.
No change
puter shall detect the vehicle de-
parting a block section.
puter shall detect the vehicle ex-
iting a block section.
Changed exiting to departing for
clarity
departing.
exiting.
Changed exiting to departing for
clarity
movement speed to the vehicle.
movement speed to the vehicle
No change
15.3.1: The vehicle shall follow
erations Computer.
7.1.1.6: The vehicle shall follow
erations Computer.
No change
15.3.2: The vehicle shall move
along the vehicle’s positive x-
axis.
7.1.1.4: The vehicle shall move
along the vehicle’s negative x-
axis when the vehicle does not
detect an obstruction.
Changed to add functionality to
require the vehicle to always
move forward rather than back-
wards.
15.3.3: The vehicle’s on-board
computer shall execute instruc-
tions from the Operations Com-
puter.
7.1.1.9.1: The vehicle’s on-
board computer shall receive in-
structions from the Operations
Computer.
No change
Table 6: The traceability matrix linking each L2 Operations Computer I/O Subsystem requirement to its
relevant L1 requirement. This includes an explanation of the reason behind each change.
Project RIDES 43

L2 System Requirements Specification, Rev. 1.3 9 Wireless Communications Subsystem
9 Wireless Communications Subsystem
9.1 Description
The Wireless Communications Subsystem is responsible for relaying emergency stop commands from
the Operations Computer to all vehicles on the arena simultaneously. The subsystem consists of a wireless
module or transmitter on the Operations Computer and a wireless module or receiver on each vehicle. The
communication is one-way, and no handshaking is done. This one-way communication is given its own
subsystem to provide a redundant way of stopping vehicle motion. When an emergency stop command is
received on the vehicle side, the power subsystem is disconnected from all other subsystems to stop all vehicle
operation.
Figure 22: Block diagram for the Wireless Communications Subsystem.
Figure 23: Flow diagram showing how the Wireless Communications Subsystem communicates with the
User Interface Subsystem and the Pathfinding Subsystem.
9.2 Constraints
The following are constraints defined by external sources that limit the development of the Wireless
Communications Subsystem in accordance with the requirements listed in this document.
9.2.1 Module Synchronicity
For wireless communication to be executed successfully, the wireless modules on the Operations Com-
puter side and the vehicle side must remain synchronized [6]. The vehicle must sample the incoming signal
at specific instances in time to receive the intended message.
Project RIDES 44

The Wireless Communications Subsystem is intended to operate asynchronously with other vehicle
subsystems using the CPU. The vehicle should should not cease path-following operations while checking for
incoming messages or authenticating received messages. Additionally, the wireless modules cannot interfere
with the Pathﬁnding Subsystem which detects frequencies from the magnetic ﬁeld generated by the arena
wire.
The following are assumptions made during the design of the Wireless Communications Subsystem and
the subsystem’s dependencies.
9.3.1 Message Authenticity
It is not assumed that the vehicle will only receive messages sent by the Operations Computer. To
protect against fraudulent messages, sent messages must be encrypted on the Operations Computer side,
and received messages must undergo an authentication process on the vehicle side before being processed
outside of the Wireless Communications Subsystem.
Project RIDES 45

9.4 Wireless Communications Subsystem Use Cases
The following use case describes the sequence of steps that occur within the Wireless Communications
Subsystem when an emergency stop has been triggered. The main success scenario describes what happens
within the system when nothing unexpected happens. The extensions describe alternatives to the sequence
of events listed in the main success scenario. Extensions labeled with a * can occur at any point within the
main success scenario.
9.4.1 Use Case: Emergency Stop Signalled
9.4.1.2 Description
The Operations Computer sends an emergency stop message to the vehicles, and the vehicles halt and
power down.
3. The wireless communication modules are synchronized.
1. The vehicles are powered down.
1. The operator instructs the Operations Computer to emergency stop the ride using options on the user
interface.
2. The Operations Computer sends an emergency stop message over the wireless module.
3. The vehicle receives the message through the wireless module.
4. The vehicle verifies message authenticity.
5. The vehicle slows to a halt.
6. The vehicle powers down.
9.4.1.6 Extensions
3a. A vehicle does not receive the message sent by the Operations Computer.
1. The operator manually turns off the vehicle.
4a. The message’s authenticity cannot be verified.
1. The vehicle disregards the message.
This use case will occur approximately once a day on an amusement park ride. For this project, this
will occur every time the ride ends.
Project RIDES 46

9.5.0.8 Use Case: Emergency Stop Signalled
The sequence diagram illustrated in Figure 24 shows the steps that occur within the Wireless Com-
munications Subsystem when an emergency stop is triggered. After an emergency stop is triggered, the
Operations Computer sends a message to the vehicles wirelessly to power down and the vehicles authenti-
cate the message.
Figure 24: Sequence Diagram for the Use Case: Emergency Stop Signalled
Project RIDES 47

9.6 Wireless Communications Subsystem Requirements
15.1.4 The Operations Computer shall trigger emergency stops.
15.1.22 The Operations Computer shall encrypt messages before sending them.
15.3.3
The vehicle’s on-board computer shall execute instructions from the Operations Com-
puter.
15.3.8
The vehicle’s power source shall be disconnected within 1 s of the vehicle authenti-
cating the command to emergency stop from the Operations Computer.
15.4.3
The vehicle shall verify the authenticity of a message received before responding to
its content.
Table 7: Requirements pertaining to the Wireless Communications Subsystem.
Project RIDES 48

puter shall trigger emergency
stops.
puter shall trigger emergency
stops.
No change
puter shall encrypt messages be-
fore sending them.
None Added
15.3.3: The vehicle’s on-board
computer shall execute instruc-
tions from the Operations Com-
puter.
7.1.1.9.2: The vehicles’ on-
board computer shall execute in-
structions from the Operations
Computer.
No Change
15.3.8: The vehicle’s power
source shall be disconnected
within 1 s of the vehicle authen-
ticating the command to emer-
gency stop from the Operations
Computer.
7.1.1.3.3: The vehicle’s power
within 1 s [TBR] of the vehicle
receiving the command to emer-
gency stop from the Operations
Computer.
”receiving” was replaced with
”authenticating” because the ve-
hicle shall authenticate the mes-
sage after receiving it and before
processing it.
15.4.3: The vehicle shall verify
the authenticity of a message re-
ceived before executing the in-
structions.
None Added
Table 8: The traceability matrix linking each L2 Wireless Communications Subsystem requirement to its
relevant L1 requirement. This includes an explanation of the reason behind each change.
Project RIDES 49

L2 System Requirements Specification, Rev. 1.3 10 Vehicle Motion Subsystem
10 Vehicle Motion Subsystem
10.1 Description
This subsystem is responsible for moving the vehicle based on input from the vehicle Pathfinding
Subsystem. This system consists of the wheels and motors on the vehicle as well as the controller used to
power the motors. The system receives power from the Vehicle Power Subsystem and a signal from the
vehicle Pathfinding Subsystem and translates that into a motor output that moves the vehicle.
Figure 25: Block diagram for the Vehicle Motion Subsystem.
Figure 26: Flow diagram showing how the Vehicle Motion Subsystem communicates with the Pathfinding
Subsystem and the Vehicle Power Subsystem.
The following are assumptions made during the design of the Vehicle Motion Subsystem and the
subsystem’s dependencies.
10.2.1 Surface
This subsystem assumes that the vehicle is located on the arena floor, which provides a smooth, flat
surface. The system may not operate correctly if not on this type of surface.
Project RIDES 50

10.3 Vehicle Motion Subsystem Use Cases
The following use case describes the sequence of steps that occur when the vehicle receives input from
the Pathfinding Subsystem regarding motor control. The main success scenario describes what happens
within the system when nothing unexpected happens. The extensions describe alternatives to the sequence
of events listed in the main success scenario. Extensions labeled with a * can occur at any point within the
main success scenario.
10.3.1 Use Case: Motor Control
1. Vehicle
10.3.1.2 Description
The vehicle is on the the arena and is following the wire in the arena floor.
1. The vehicle is on the arena floor over a wire.
2. The vehicle is powered on.
1. The PWM output signals from the Pathfinding Subsystem are read in.
2. The PWM output signals are translated to a signal that can drive the motors using the motor controller
and power from the Vehicle Power Subsystem.
3. Motor output signals are sent to the motors.
4. The motors spin at the appropriate speeds for the signal they are given.
5. The motors spin the wheels which cause the vehicle to move.
10.3.1.6 Extensions
*a. The subsystem receives insufficient power from the Vehicle Power Subsystem.
1. The motor controller attempts to power the wheels at a slower speed.
2. If this is not possible, only one of the wheels will be powered.
3. The result will look like the vehicle is slowly wobbling around the arena wire.
4. The operator should notice this behavior and initiate a ride stop to remove the vehicle for charging
(see Use Case: Ride Stop).
This use case will occur continuously while the vehicle is powered on.
Project RIDES 51

10.4.0.8 Use Case: Motor Control
The sequence diagram illustrated in Figure 27 shows the steps that occur when the vehicle receives
input from the Pathﬁnding Subsystem regarding motor control. The vehicle motor controller then controls
the motors based on the input to regulate speed.
Figure 27: Sequence Diagram for the Use Case: Motor Control
Project RIDES 52

10.5 Vehicle Motion Subsystem Requirements
15.3.5
The Vehicle Motion Subsystem shall move the vehicle based on the input from the
Pathfinding Subsystem.
15.3.5.1 The vehicle shall have a speed that does not exceed 0.3 m/s.
15.1.5.2
The vehicle shall travel within 10 mm/s of the speed expected due to the Pathfinding
Subsystem output.
15.3.5.2 The Vehicle Motion Subsystem shall control each motor independently.
15.3.6 The speed of each motor shall correspond to the output of the Pathfinding Subsystem.
Table 9: Requirements pertaining to the Vehicle Motion Subsystem.
Project RIDES 53

15.3.5: The Vehicle Motion
Subsystem shall move the vehi-
cle based on the input from the
Pathfinding Subsystem.
7.1.1.1: The vehicle shall travel
on the floor of the arena.
Updated to reflect the subsystem
decomposition.
15.3.5.1: The vehicle shall have
a speed that does not exceed 0.3
m/s.
None Added
15.3.5.2: The vehicle shall
travel within 10 mm/s of the
speed expected due to the
Pathfinding Subsystem output.
7.1.1.2: The vehicle shall travel
at a speed within 5 mm/s of the
speed instructed by the Opera-
tions Computer when the vehicle
does not detect an obstruction.
The previous wording did not
take into account the pathfind-
ing. Our testing also showed that
the vehicle speed was more vari-
able than anticipated.
15.3.6: The Vehicle Motion
Subsystem shall control each mo-
tor independently.
None Added
Table 10: The traceability matrix linking each L2 Vehicle Motion Subsystem requirement to its relevant L1
Project RIDES 54

L2 System Requirements Specification, Rev. 1.3 11 Vehicle Power Subsystem
11 Vehicle Power Subsystem
11.1 Description
The Vehicle Power Subsystem is a subsystem that is mounted solely on the vehicles with the explicit
purpose of delivering power to the vehicle’s other on-board systems. The primary breakdown of the con-
struction of the Vehicle Power Subsystem is a battery or set of batteries, and a hardware logic circuit that
can handle the delivery of power and also reacting to the other systems.
Figure 28: Block diagram for the Vehicle Power Subsystem
Figure 29: Flow diagram showing how the Vehicle Power Subsystem communicates with the Vehicle Motion
Subsystem, vehicle microcontroller, and the operator.
11.2 Constraints
The following are constraints defined by external sources that limit the development of the Vehicle
Power Subsystem in accordance with the requirements listed in this document.
11.2.1 Vehicle Size
The Vehicle Power Subsystem is constrained in that the entire subsystem must fit onto the vehicle and
be fully contained within the volume of the vehicle. This is in part due to the fact that the vehicles must be
able to move on their own without needing to be powered or connected to external sources.
Project RIDES 55

11.2.2 Electrical Properties
The Vehicle Power Subsystem is also constrained in such a way that it cannot supply a voltage less than
what is needed to power all the vehicles systems. The Vehicle Power Subsystem must also be able to supply
enough current simultaneously to all of the vehicle’s subsystems so that it can run all of the subsystems
simultaneously.
The following are assumptions made during the design of the Vehicle Power Subsystem and the sub-
system’s dependencies.
11.3.1 Batteries
This subsystem assumes that the batteries will not exceed a certain amount of voltage since during
the operation of Project RIDES batteries will only be discharged, not charged. It is also assumed that the
batteries will stay near their posted voltage, unless the battery is near exhausted of its charge.
Project RIDES 56

11.4 Vehicle Power Subsystem Use Cases
The following use cases describe the sequence of steps that occur when the operator powers up the
vehicle and when an emergency stop is triggered within the Vehicle Power Subsystem. The main success
scenario describes what happens within the system when nothing unexpected happens. The extensions
describe alternatives to the sequence of events listed in the main success scenario. Extensions labeled with
a * can occur at any point within the main success scenario.
11.4.1 Use Case: Vehicle Power Up
1. Operator
The operator triggers a vehicle start up, and the Vehicle Power Subsystem starts delivering power to
all of the on-board systems.
1. The battery(s) are connected to the power system.
2. The Vehicle Power Subsystem’s logic circuit is not enabled/latched.
1. Power is being delivered to all vehicle systems.
2. The emergency stop is prepared to trigger.
1. The operator utilizes a pilot device to signal to the Vehicle Power Subsystem to start.
2. The Vehicle Power Subsystem temporarily delivers power to the vehicle microcontroller.
3. The Vehicle Power Subsystem awaits a signal from the vehicle microcontroller.
4. The Vehicle Power Subsystem, upon receiving a signal from the vehicle microcontroller, latches on.
5. The Vehicle Power Subsystem waits for a lack of signal from the vehicle microcontroller, which would
trigger an emergency stop.
11.4.1.6 Extensions
*a The batteries within the Vehicle Power Subsystem are exhausted.
1. Power will no longer be delivered to other subsystems
2. The Vehicle Power Subsystem’s logic circuit will un-latch, eﬀectively emergency stopping the
vehicle.
4a. The vehicle’s computer does not power up/does not transmit signal to the Vehicle Power Subsystem.
1. The temporary latching of the Vehicle’s Power Subsystem ends.
2. The Vehicle Power Subsystem stops delivering power to the other devices.
3. The vehicle slows to a halt.
This will occur once per day, and will be required after every emergency stop.
Project RIDES 57

11.4.2 Use Case: Emergency Stop Power Down
1. Vehicle Microcontroller
The vehicle’s stay-alive signal disappears and the Vehicle Power Subsystem responds to a triggered
emergency stop by stopping power delivery.
1. The Vehicle Power Subsystem is currently delivering power to the vehicle’s subsystems.
2. The vehicle microcontroller is powered on, but it is not outputting the stay-alive signal.
1. Power is not being delivered to any vehicle subsystems.
1. The Vehicle Power Subsystem stops receiving the stay-alive signal.
2. The Vehicle Power Subsystem disables the latching function for power delivery.
3. The Vehicle Power Subsystem stops providing power to all vehicle subsystems.
11.4.2.6 Extensions
*a The batteries within the Vehicle Power Subsystem are exhausted.
1. Power will no longer be delivered to other subsystems
2. The Vehicle Power Subsystem’s logic circuit will un-latch, eﬀectively emergency stopping the
vehicle.
This will occur approximately once per day.
Project RIDES 58

11.5.0.8 Use Case: Vehicle Power Up
The sequence diagram illustrated in Figure 30 shows the steps that occur when the operator powers
on a vehicle using a pilot device on the vehicle. The pilot device temporarily provides power to the vehicle
microcontroller, which then triggers a latch that connects the batter to the other subsystems.
Figure 30: Sequence Diagram for the Use Case: Vehicle Power Up
Project RIDES 59

11.5.0.9 Use Case: Emergency Stop Power Down
The sequence diagram illustrated in Figure 31 shows the steps that occur when the vehicle receives
an emergency stop and the vehicle microcontroller stops sending signal to the relay to remain latched. The
vehicle then slows to a stop.
Figure 31: Sequence Diagram for the Use Case: Emergency Stop Power Down
Project RIDES 60

11.6 Vehicle Power Subsystem Requirements
15.3.7 The vehicle’s power source shall supply DC Power to all of the vehicle’s subsystems.
15.3.8
The vehicle’s power source shall be physically disconnected within 1 s of the vehicle
authenticating an emergency stop command.
Table 11: Requirements pertaining to the Vehicle Power Subsystem
Project RIDES 61

source shall supply DC Power to
all of the vehicle’s systems.
source shall supply 5 V of DC
power [TBR] to all the vehicle’s
systems.
The requirement was split into
two and the voltage level was re-
ﬁned.
source shall be physically discon-
nected within 1 s of the vehicle
authenticating the command to
emergency stop command.
within 1 s [TBR] of the vehicle
receiving the command to emer-
gency stop from the operations
computer.
No change needed.
Table 12: The traceability matrix linking each L2 Vehicle Power Subsystem requirement to its relevant L1
Project RIDES 62

L2 System Requirements Specification, Rev. 1.3 12 Vehicle Pathfinding Subsystem
12 Vehicle Pathfinding Subsystem
12.1 Description
The Pathfinding Subsystem is responsible for generating output to the Vehicle Motion Subsystem based
on the input from the Obstacle Detection Subsystem and the Pathfinding Subsystem’s own sensors. The
subsystem is comprised of two magnetic field sensors, a microcontroller, and a software based control system.
While the vehicle has power, the subsystem will continuously read the sensors and determine the appropriate
motor outputs to stay along the path, if a path is detected.
Figure 32: Block diagram for the Pathfinding Subsystem.
Figure 33: Flow diagram showing how the Pathfinding Subsystem communicates with the Wireless Commu-
nications Subsystem, the arena, the Obstacle Detection Subsystem, and the Vehicle Motion Subsystem.
Project RIDES 63

12.2 Constraints
The following are constraints defined by external sources that limit the development of the Vehicle
Pathfinding Subsystem in accordance with the requirements listed in this document.
12.2.1 Power
The Pathfinding Subsystem is constrained to operate on the vehicle. This means that its size and
power requirements must not exceed the limits of the vehicle chassis and power subsystem respectively.
The following are assumptions made during the design of the Pathfinding Subsystem and the subsys-
tem’s dependencies.
12.3.1 Magnetic Field Detection
This subsystem assumes that any magnetic field detected at the correct frequency must be from the
arena wire. Due to this limitation, the arena is dependent on operating in an environment that does not
have magnetic interference at the operating frequencies.
Project RIDES 64

12.4 Vehicle Pathfinding Subsystem Use Cases
The following use case describes the sequence of steps that occur while the vehicle follows paths in
the arena. The main success scenario describes what happens within the system when nothing unexpected
happens. The extensions describe alternatives to the sequence of events listed in the main success scenario.
Extensions labeled with a * can occur at any point within the main success scenario.
12.4.1 Use Case: Path Finding
1. Vehicle
The vehicle senses the current in the wire beneath it and follows the path based on the sensor input.
2. The vehicle is powered on.
1. The value from the left pathfinding sensor is read.
2. The value from the right pathfinding sensor is read.
3. The frequency of the signal input by the sensors is calculated within 10% of 13.2 kHz.
4. The Obstacle Detection Subsystem indicates that there are no obstacles detected.
5. The values from the pathfinding sensors are input to a control system.
6. The output of the control system is output to the motor controller.
7. The vehicle follows the path.
12.4.1.6 Extensions
3a. Frequency is not calculated within 10% of 13.2 kHz.
1. A countdown timer is started at 1 second.
2. If the frequency is calculated within 10% of 13.2 kHz before the timer reaches 0, the timer stops
and is reset.
3. If the timer reaches 0, the control system is bypassed and the motors are stopped.
4a. An obstacle is detected.
1. The output of the control system is multiplied by the output of the Obstacle Detection Subsystem.
4b. An obstacle is detected closeby.
1. The control system is bypassed and all motor outputs are set to 0.
This use case will occur continuously while the vehicle is powered on.
Project RIDES 65

12.5.0.8 Use Case: Path Finding
The sequence diagram illustrated in Figure 34 shows the steps that occur while the vehicle follows
paths in the arena. The vehicle receives input from the magnetic sensors that are reading the current in the
block section beneath the vehicle. The vehicle then checks for input from the Obstacle Detection Subsystem.
If no obstacles are detected, the vehicle then passes the input from the magnetic sensors to a control system,
which then returns values to control the motors.
Figure 34: Sequence Diagram for the Use Case: Path Finding
Project RIDES 66

12.6 Vehicle Pathfinding Subsystem Requirements
15.3.4
The Pathfinding Subsystem shall output one motor signal to the Vehicle Motion
Subsystem for each motor controlled by the Vehicle Motion Subsystem.
15.3.4.1 The motor signal output shall direct the vehicle to follow the arena wire.
15.3.4.2 The motor signal output shall be 0 if no clear path is detected.
15.3.9 The Pathfinding Subsystem shall read magnetic field signals from the arena wire.
15.3.9.1
Each Pathfinding Subsystem sensor shall read a signal from the arena wire when the
sensor is less than 2 cm from the arena wire.
15.3.9.2
The Pathfinding Subsystem sensors shall read a signal with an amplitude that changes
relative to the inverse of the distance from the arena wire.
15.3.10
The Pathfinding Subsystem shall direct the vehicle such that the geometric center of
the vehicle is less than 5 cm from at least 1 point on the arena wire.
15.3.11
The Pathfinding Subsystem shall accept a value between 0 to 1 from the Obstacle
Detection Subsystem.
15.3.11.1
The motor signal output shall be scaled by the input from the Obstacle Detection
Subsystem.
15.3.12
The Pathfinding Subsystem shall calculate the frequency of the signal input by the
magnetic field sensors.
15.3.12.1
The motor signal outputs shall be set to 0 within 1 s if the calculated frequency is
not within 10% of the expected operating value.
Table 13: Requirements pertaining to the Vehicle Pathfinding Subsystem.
Project RIDES 67

Team Omni L2 Requirements Revised

Team Omni L2 Requirements Revised

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to Team Omni L2 Requirements Revised

Similar to Team Omni L2 Requirements Revised (20)

Team Omni L2 Requirements Revised