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).
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.18 The Operations Computer shall provide a suggested movement speed to the vehicle.
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.
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.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
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.
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
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.
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

15.3.4.1: The motor signal out-
put shall direct the vehicle to fol-
low the arena wire.
erations Computer.
The Pathfinding Subsystem has
no direct knowledge of the Op-
erations Computer and is not in
direct control of the motors. The
requirement was updated to re-
flect this.
15.3.4.2: The motor signal out-
put shall be 0 if no clear path is
detected.
None Added
15.3.9: The Pathfinding Sub-
system shall read magnetic field
signals from the arena wire.
None Added
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.
None Added
15.3.9.2: The Pathfinding Sub-
system sensors shall read a signal
with an amplitude that changes
relative to the inverse of the dis-
tance from the arena wire.
None Added
system 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.
7.1.1.6.1: The geometric center
of the vehicle shall deviate from
its current path no more than 5
cm [TBR] on either side of the
vehicles x-axis while moving for-
ward.
The L1 requirement left in too
much ambiguity, the L2 require-
ment can only be fulfilled by
staying on the path, as no two
paths are within 10 cm of each
other.
system shall output one motor
signal to the Vehicle Motion Sub-
system for each motor controlled
by the Vehicle Motion Subsys-
tem.
None Added
system shall accept a value be-
tween 0 to 1 from the Obstacle
Detection Subsystem.
None Added
15.3.11.1: The motor signal
output shall be scaled by the in-
put from the Obstacle Detection
Subsystem.
7.1.1.4: The vehicle shall move
along the vehicle’s positive x-axis
when the vehicle does not detect
an obstruction.
The decomposition of the
Pathfinding Subsystem allowed
for a system that would take
into account all possible outputs
from the Obstacle Detection
Subsystem in one requirement.
Project RIDES 68

system shall calculate the fre-
quency of the signal input by the
magnetic field sensors.
None Added
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.
7.1.1.7: The vehicle shall re-
main stationary if it does not de-
tect a path.
7.1.1.5: The vehicle shall slow
to a halt within 1 s [TBR] when
the vehicle does not detect a
path.
The frequency of the arena wire
is used to identify the path. The
requirement was updated to re-
flect that system.
Table 14: The traceability matrix linking each L2 Pathfinding Subsystem requirement to its relevant L1
Project RIDES 69

L2 System Requirements Specification, Rev. 1.3 13 Vehicle Identification Subsystem
13 Vehicle Identification Subsystem
13.1 Description
The Vehicle Identification Subsystem is the system responsible for returning the identification of the
vehicle to the Operations Computer when the vehicle reaches the edge of a block section and triggers a
sensor. On the vehicle, this subsystem consists of two different contact points with the arena and a resistive
network. The subsystem will receive a reference voltage from the arena’s block sensors and act as a voltage
divider, returning a lower voltage unique to the vehicle.
Figure 35: Block diagram for the Vehicle Identification Subsystem
Figure 36: Flow diagram illustrating how the voltage flows into and out of the Vehicle Identification Sub-
system.
13.2 Constraints
Identification Subsystem in accordance with the requirements listed in this document.
13.2.1 Vehicle Chassis
This subsystem is one of many subsystems that is going to be included on the vehicle chassis, therefore
it is constrained by the size requirements of the vehicle chassis. In addition to this, the system will operate
passively and must operate without power from the vehicle.
The following are assumptions made during the design of the Pathfinding Subsystem and the subsys-
tem’s dependencies.
Project RIDES 70

13.3.1 Arena Surface
This subsystem assumes that the vehicle is operating on a ﬂat surface such that both contact points
with the arena are at the same height and can make a secure connection with the sensors on the arena ﬂoor.
13.3.2 Arena Sensors
This subsystem is dependent on the voltage supplied by the lead pad on the arena block sensors. If
this voltage is not stable or at the correct value, the subsystem may return an incorrect value, which could
interfere with normal operation.
Project RIDES 71

13.4 Vehicle Identification Subsystem Use Cases
The following use cases describe the sequence of steps that occur when the vehicle passes over a 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
13.4.1 Use Case: Changing Block Sections
1. Vehicle
The vehicle proceeds from one block section to another on the arena. As it proceeds, the contact points
on the Vehicle Identification Subsystem connect with the sensors on the arena floor. The voltage provided
by the sensors is divided by an amount that is unique to the vehicle, and the new voltage is returned to the
Operations Computer.
3. The vehicle is near the end of a block section.
4. The vehicle is not stationary.
1. The vehicle has passed the end of the previous block section.
1. The vehicle passes over the edge of the block section.
2. Both contact points of the Vehicle Identification Subsystem contact the sensors on the arena floor.
3. The arena floor sensors provide a specific DC voltage to the Vehicle Identification Subsystem.
4. The provided voltage is divided by the resistive network.
5. The divided voltage is returned to the arena floor sensors.
6. The Operations Computer receives the divided voltage.
7. The Operations Computer updates the location of the vehicle within its program.
13.4.1.6 Extensions
*a. The arena floor sensors provide an incorrect voltage.
1. The incorrect voltage is divided by the resistive network.
2. The result is returned to the arena floor sensors.
3. The Operations Computer receives the incorrect voltage.
3a. If the incorrect voltage corresponds to a different vehicle, a discontinuity error will be detected
and the ride will emergency stop.
3b. If the incorrect voltage does not correspond to any vehicle, a sensor error will be detected,
and the ride will emergency stop.
Project RIDES 72

*b. Both of the contact points on the Vehicle Identification Subsystem do not make contact with the arena
floor sensors.
1. No voltage is delivered to the Vehicle Identification Subsystem.
2. The Operations Computer does not update the location of the vehicle.
3. The Operations Computer triggers a vehicle timeout error, and the ride emergency stops.
13.4.1.7 Frequency of Occurance
This use case occurs every time the vehicle travels onto a new block sections. During normal operation,
this will happen between one and five times every minute.
Project RIDES 73

13.5.0.8 Use Case: Changing Block Sections
The sequence diagram illustrated in Figure 37 shows the steps that occur when the vehicle passes over
a sensor in the arena. The contact points of the Vehicle Identiﬁcation Subsystem connect with the sensors on
the arena ﬂoor. The voltage provided by the sensors is divided by an amount that is unique to the vehicle,
and the new voltage is returned to the Operations Computer.
Figure 37: Sequence Diagram for the Use Case: Changing Block Sections
Project RIDES 74

13.6 Vehicle Identification Subsystem Requirements
15.3.13
The Vehicle Identification Subsystem shall accept an input voltage from the arena
block sensors.
15.3.13.1
The input voltage shall be determined by the difference in voltage across the front
and back contact points.
15.3.14
The input voltage to the Vehicle Identification Subsystem shall be divided by an
amount unique to each vehicle.
Table 15: Requirements pertaining to the Vehicle Identification Subsystem.
Project RIDES 75

L2 Requirement L1 Requirement derived from Notes
15.3.13: The Vehicle Identifi-
cation Subsystem shall accept
an input voltage from the arena
block sensors.
None Added
15.3.13.1: The input voltage
shall be determined by the differ-
ence in voltage across the front
and back contact points.
None Added
15.3.14: The input voltage to
the Vehicle Identification Sub-
system shall be divided by an
amount unique to each vehicle.
7.1.2.2: The vehicle shall have a
priority level unique amongst the
system’s vehicles.
The language in the L1 require-
ment was updated to fit the sys-
tem decomposition.
Table 16: The traceability matrix linking each L2 Vehicle Identification Subsystem requirement to its relevant
L1 requirement. This includes an explanation of the reason behind each change.
Project RIDES 76

L2 System Requirements Speciﬁcation, Rev. 1.3 14 Obstacle Detection Subsystem
14 Obstacle Detection Subsystem
14.1 Description
The Obstacle Detection Subsystem is responsible for sensing any objects that enter a vehicle’s path.
This subsystem indicates to the vehicle how far away an obstacle is such that the appropriate action can be
taken. The Obstacle Detection Subsystem will control the speed of the vehicle based on what is detected.
Figure 38: Block diagram of the Obstacle Detection Subsystem.
Figure 39: Flow diagram showing how the Obstacle Detection Subsystem communicates with the Vehicle
14.2 Constraints
The following are constraints deﬁned by external sources that limit the development of the Obstacle
Detection Subsystem in accordance with the requirements listed in this document.
For the Obstacle Detection Subsystem to operate correctly, the vehicle microcontroller and the sensor
inputs must work asynchronous with the other vehicle components. The vehicle must prioritize the obstacle
sensor input above any other components, so that the detection of an obstacle is acknowledged and acted
upon nearly instantly. When an obstacle is detected, speed instructions from the Operations Computer are
ignored.
Project RIDES 77

14.3 Obstacle Detection Subsystem Use Cases
The following use cases describe the sequence of steps that occur when an obstacle is detected. The
extensions describe alternatives to the sequence of events listed in the main success scenario. Extensions
14.3.1 Use Case: Obstacle Detected
1. Vehicle
The obstacle detection sensor outputs a signal to the vehicle microcontroller, which is then interpreted
by the vehicle to determine the desired movement speed.
1. The vehicle is in the ready state.
1. The vehicle is stopped.
1. The obstacle sensor detects an object within 3 cm.
2. The Obstacle Detection Subsystem outputs a signal to the vehicle.
3. The vehicle receives the signal.
4. The vehicle authenticates the signal.
14.3.1.6 Extensions
1a. The obstacle is detected within 10 cm but no closer than 3 cm.
1. The vehicle decreases in speed.
This use case will occur for a vehicle whenever a path obstruction is encountered.
Project RIDES 78

14.4.0.8 Use Case: Obstacle Detected
The sequence diagram illustrated in Figure 40 shows the steps that occur when the vehicle detects an
obstacle in its path. The vehicle either slows to a complete stop, or reduces its speed, depending on the
distance between itself and the obstacle.
Figure 40: Sequence Diagram for the Use Case: Obstacle Detected
Project RIDES 79

14.5 Obstacle Detection Subsystem Requirements
15.3.15 The vehicle shall detect obstructions.
15.3.15.1
The vehicle shall disregard speed signals received from the Operations Computer while
the vehicle detects an obstruction.
15.3.15.2
The vehicle shall resume following instructions from the Operations Computer when
the vehicle does not detect the obstruction.
15.3.15.3
The vehicle shall detect obstructions larger than 8 cm x 8 cm x 8 cm within 15 cm of
the vehicle when the obstruction is within 10 degrees of the positive x-axis.
15.3.15.4
The vehicle shall reduce speed to half of its speed when an obstruction is detected
between 15 cm and 4 cm of the vehicle within 10 degrees of the vehicle’s positive
x-axis.
15.3.15.5
The vehicle shall reduce speed to a halt when an obstruction is detected closer than
7 cm within 10 degrees of the vehicle’s positive x-axis.
Table 17: Requirements pertaining to the Obstacle Detection Subsystem.
Project RIDES 80

15.3.15: The vehicle shall de-
tect obstructions.
7.1.1.8: The vehicle shall detect
obstructions.
No change.
15.3.15.1: The vehicle shall
disregard speed signals received
from the Operations Computer
while the vehicle detects an ob-
struction.
7.1.1.8.1: The vehicle shall
disregard speed signals received
from the Operations Computer
while the vehicle detects an ob-
struction.
No change.
sume following instructions from
the Operations Computer when
the vehicle does not detect the
obstruction.
7.1.1.8.2: The vehicle shall re-
sume following instructions from
the Operations Computer when
the vehicle does not detect the
obstruction.
No change.
15.3.15.3: The vehicle shall de-
tect obstructions larger than 8
cm x 8 cm x 8 cm within 15 cm
of the vehicle when the obstruc-
tion is within 10 degrees of the
positive x-axis.
7.1.1.8.3: The vehicle shall de-
tect obstructions larger than 3
cm x 3 cm x 3 cm within 10 cm
of the vehicle when the obstruc-
tion is within 10 degrees of the
negative x-axis.
Refined distances.
duce speed to half of its speed
when an obstruction is detected
between 15 cm and 4 cm of the
vehicle within 10 degrees of the
vehicle’s positive x-axis.
duce speed to half of its speed
when an obstruction is detected
between 10 cm and 3 cm of the
vehicle within 10 degrees of the
vehicle’s negative x-axis.
Refined distances.
duce speed to a halt when an ob-
struction is detected closer than
7 cm within 10 degrees of the ve-
hicle’s positive x-axis.
duce speed to a halt when an ob-
struction is detected closer than
3 cm within 10 degrees of the ve-
hicle’s negative x-axis.
Refined distances.
Table 18: The traceability matrix linking each L2 Obstacle Detection Subsystem requirement to its relevant
L1 requirement. This includes an explanation of the reason behind each change.
Project RIDES 81

L2 System Requirements Specification, Rev. 1.3 15 Project RIDES Requirements
15 Project RIDES Requirements
This section contains the complete list of the Project RIDES requirements. The section is separated
into subsections for the vehicle, Operations Computer, and arena functional and non-functional requirements.
15.1 Operations Computer Functional Requirements
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.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 5 s of the expected
time.
15.1.4.2 The expected time shall be calculated by the Operations Computer.
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.
15.1.9 The Operations Computer shall direct vehicles out of the maintenance bay when the ride is initialized.
15.1.10 The Operations Computer shall initiate cycling when all the vehicles arrive at their respective target
locations.
15.1.11 The Operations Computer shall set the vehicle’s target location to an effectively unoccupied block
section after initialization.
15.1.12 The Operations Computer shall set the vehicle’s target location to an effectively unoccupied block
section upon the vehicle’s 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.
Project RIDES 82

15.1.17 The Operations Computer shall track the occupancy state of each station platforms.
15.1.18 The Operations Computer shall provide a suggested movement speed to the vehicle.
15.1.19 The Operations Computer shall stop providing the vehicle with a suggested movement speed 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 to 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 10 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 [TBR] 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.1.22 The Operations Computer shall encrypt messages before sending them.
15.2 Operations Computer Non-Functional Requirements
15.2.1 The Operations Computer shall set a vehicle’s target location.
15.2.2 The Operations Computer shall mark a station platform as effectively occupied when a vehicle’s target
location is set to the specified station platform.
15.2.3 The Operations Computer shall mark a block section as effectively occupied when the block section is
a vehicle’s target location.
15.2.4 The Operations Computer shall determine when the vehicle dispatches from the station platform.
15.2.4.1 The vehicle shall remain stationary at the station platform between 30 s to 60 s.
15.2.4.2 The Operations Computer shall check to see if the block sections in front of the vehicle are
unoccupied before instructing the vehicle to leave the station platform.
Project RIDES 83

15.3 Vehicle Functional Requirements
15.3.2 The vehicle shall move along the vehicle’s positive x-axis.
15.3.3 The vehicle s on-board computer shall execute instructions from the Operations Computer.
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.5 The Vehicle Motion Subsystem shall move the vehicle based on input from the Pathfinding Subsystem.
15.3.5.1 The vehicle shall have a speed that does not exceed 0.3 m/s.
15.3.5.2 The vehicle shall travel within 10 mm/s of the speed provided as the Pathfinding Subsystem
output.
15.3.6 The Vehicle Motion Subsystem shall control each motor independently.
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 authenticating an emergency
stop command.
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 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 and 1 from the Obstacle Detection Subsys-
tem.
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.
15.3.13 The Vehicle Identification Subsystem shall accept an input voltage from the arena block sensors.
15.3.13.1 The input voltage shall be determined by the difference in voltage across the front and back
contact points of each vehicle.
15.3.14 The input voltage to the Vehicle Identification Subsystem shall be divided by an amount unique to
each vehicle.
15.3.15 The vehicle shall detect obstructions.
15.3.15.1 The vehicle shall disregard speed signals received from the Operations Computer while the vehicle
detects an obstruction.
Project RIDES 84

15.3.15.2 The vehicle shall resume following instructions from the Operations Computer when the vehicle
does not detect the obstruction.
15.3.15.3 The vehicle shall detect obstructions larger than 8 cm x 8 cm x 8 cm within 15 cm of the vehicle
when the obstruction is within 10 degrees of the vehicle’s positive x-axis.
15.3.15.4 The vehicle shall reduce speed to half of its speed when an obstruction is detected between 15 cm
and 4 cm of the vehicle within 10 degrees of the vehicle’s positive x-axis.
15.3.15.5 The vehicle shall reduce speed to a halt when an obstruction is detected closer than 7 cm from
the front of the vehicle within 10 degrees of the vehicle’s positive x-axis.
15.4 Vehicle Non-Functional Requirements
15.4.1 RIDES shall have at least 2 vehicles.
15.4.1.1 The number of vehicles shall be constrained by the following equation to avoid block section
conﬂicts:
MaxNumberOfV ehicles = ((TotalNumberOfBlockSections) − 1)/3
15.4.2 The vehicle shall have a priority level unique amongst the system’s vehicles.
15.4.3 The vehicle shall verify the authenticity of a message received before responding to its content.
15.4.4 The vehicle’s power source shall be located on the vehicle.
Project RIDES 85

15.5 Arena Non-Functional Requirements
15.5.1 The arena shall have a ﬂoor consisting of 0.75 inch MDF with dimensions at least 240 cm x 120 cm.
15.5.2 The course shall have at least 2 pathways.
15.5.2.1 Each pathway shall be composed of at least 3 block sections.
15.5.2.2 Each block section shall end at the start of another block section.
15.5.2.3 Each block section shall be no shorter in length than a vehicle.
15.5.3 The course shall have a maintenance bay.
15.5.3.1 The maintenance bay shall be comprised of at least 2 block sections.
15.5.3.2 The maintenance bay shall be connected to the MTP switch.
15.5.3.3 The maintenance bay shall be connected to the STP switch.
15.5.4 The course shall have a station area.
15.5.4.1 The arena shall have fewer station platforms than the number of vehicles.
15.5.4.2 The arena shall have at least 1 station platform.
15.5.5 The arena shall remain indoors.
Project RIDES 86

L2 System Requirements Specification, Rev. 1.3 16 Glossary
16 Glossary
Word Definition Aliases
Block Section
A section of path that can safely accommodate a single
vehicle. At no time should a block section contain more
than one vehicle.
Block
Block System
A way of introducing high levels of safety into a ride by
sectioning the ride into block sections.
Effectively Occupied
A state in which a block section exists where the block
section is a vehicle s target location.
Effectively Unoccupied
A state in which a block section exists where the block
section is not the target location of any vehicle.
Emergency Stop
Used to stop the ride in such a manner that the ride will
only operate again with direct intervention from an opera-
tor. Typically, this must be reset by power cycling the ride
[4].
Maintenance Bay
A path or area of a ride on which vehicles can be stored
and worked on.
Moving Block-Light
System
An advanced block system where a vehicle s movement is re-
stricted based on the number of unoccupied blocks separat-
ing itself and the vehicle proceeding it along the path. The
first moving block-light system was introduced for the Walt
Disney World Monorail System known as MAPO (MAry
POppins) [7].
Path
The block sections that are in front of a vehicle between
the vehicle and its target location.
Pathway
A chain of block sections that lead from the STP switch to
the PTS switch.
Pilot Device
A family of related products, including push-buttons, selec-
tor switches, pilot lights, toggle switches, and signal bea-
cons. A pilot device communicates information between
the operator and the machine.
Obstruction
An object that unexpectedly enters a section of path ahead
of the ride vehicle.
Occupied
A state in which a block section exists where a vehicle is
on the block switch.
Operations Computer
The device that monitors the movement and location of all
of the vehicles and the status of each station platform. It
makes decisions regarding vehicle movement based on this
information.
Ride Stop
A function on a ride’s control system that causes all vehicles
to stop and remain stopped until further notice.
Station Area
An area that houses one or more station platforms and a
pathway that vehicles can be directed onto to bypass station
platforms.
Station Platform
A location where vehicles stop to simulate the loading and
unloading of passengers. The vehicles stop there for a
length of time that is based on estimated loading time.
Switch
A block that can direct a vehicle to one of multiple possible
blocks or can direct a vehicle from one of multiple blocks
onto a single block.
Project RIDES 87

L2 System Requirements Speciﬁcation, Rev. 1.3 16 Glossary
Target Location
The furthest open block that a vehicle can route to that is
not about to be occupied, or will be occupied by another
vehicle before the original vehicle enters it.
Target Block
Unoccupied
A state in which a block section exists where no vehicle is
on the block switch.
Vehicle Computer
The device on-board each of the vehicles that is able to pro-
cess commands from the Operations Computer and enact
those commands, controlling the vehicle s movement.
Vehicle Mi-
crocontroller
Project RIDES 88

L2 System Requirements Specification, Rev. 1.3 17 Acronyms
17 Acronyms
Name Definition
ERAU Embry-Riddle Aeronautical University
ID Identification
I/O Input/Output
MTP Maintenance-To-Path
PTS Path-To-Station
PWM Pulse-Width Modulation
RF Radio Frequency
RIDES Ride Integrating Dynamic Electronic System
STP Station-To-Path
Project RIDES 89

L2 System Requirements Speciﬁcation, Rev. 1.3 References
References
[1] Electrical, Computer, Software, and Systems Engineering Department.
(2014, 8 25). ERAU Capstone Design Requirements [Online]. Available:
https://erau.blackboard.com/webapps/blackboard/execute/content
[2] Student Handbook, Embry-Riddle Aeronautical University, Daytona Beach, FL, 2014
[3] ABB Inc., Basic Training, Pilot Devices - 101
[4] Standard Practice for Design of Amusement Rides and Devices, ASTM Standard F2291-14.
[5] Tablet PC Dimensions and Case Sizes. Wikipedia [Online]. Available:
http://en.wikipedia.org/wiki/Tablet PC dimensions and cases sizes
[6] Heidi Steendam et. al, Synchronization in Wireless Communication, EURASIP Journal on Wireless
Communications and Networking 2009, 2009:568369 doi:10.1155/2009/568369
[7] Railroad Accident Brief, National Transportation Safety Board, Washington DC, RAB-11-07, October
31, 2011
Project RIDES 90

L2 System Requirements Specification, Rev. 1.3 A Appendix
A Appendix
A.1 Changelog
Section Description
Introduction
Changed the team roles to be more uniform and correctly define
our current roles at this stage of project development. Overview
changed to include all subsystems.
Stakeholders Nothing changed
High-Level Description Nothing changed
Requirements Considerations Nothing changed
Functional Decomposition of System Imported from Budget Document to further explain the system
User Interface Subsystem Added to document to better explain the system
Scheduling Subsystem Added to document to better explain the system
Operations Computer I/O Subsystem Added to document to better explain the system
Wireless Communication Subsystem Added to document to better explain the system
Vehicle Motion Subsystem Added to document to better explain the system
Vehicle Power Subsystem Added to document to better explain the system
Vehicle Pathfinding Subsystem Added to document to better explain the system
Vehicle Identification Subsystem Added to document to better explain the system
Obstacle Detection Subsystem Added to document to better explain the system
Requirements
Added and removed many different subsystems to better fit the
system as a whole
Glossary Updated to add any terms not used in the L1 SRS
Acronyms Updated to add any Acronyms not used in the L1 SRS
Project RIDES 91

A.2 L1 SRS
Project RIDES 92

Project RIDES SRS 1.2-2014
(Revision 2014-10-07)
System Requirements Specification for Project
Ride Integrating Dynamic Electronic System
Released September 18, 2014
Developed By
Team Omni
Abstract
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 the project RIDES customer and the development team.
Project RIDES 93

1
Revision History
Date Version Reason for Changes
Sep. 15, 2014 0.1 Initial draft of the document
Sep. 17, 2014 0.2 Parts reviewed by Dr. Barott, Jorge Torres, and Dr. Garfield
Sep. 18, 2014 1.0 Finalized Requirements L1
Oct 4, 2014 1.1 Initial Revisions to Requirements L1
Oct. 7, 2014 1.2 Finalized Revisions to Requirements L1
Project RIDES 94

ii
Table of Contents
2. Introduction........................................................................................................................................... 1
2.1. Purpose........................................................................................................................... 1
2.2. Mission Statement.......................................................................................................... 1
2.3. Scope.............................................................................................................................. 1
2.4. Team Information .......................................................................................................... 1
2.5. Overview........................................................................................................................ 1
3. High-Level Description ........................................................................................................................ 2
3.1. Arena Configuration ...................................................................................................... 2
3.2. Vehicle Operation and Coordinate System.................................................................... 4
3.3. Constraints ..................................................................................................................... 5
3.4. Assumptions and Dependencies..................................................................................... 5
3.5. User Characteristics ....................................................................................................... 5
4. Stakeholders.......................................................................................................................................... 5
4.1. Team Omni .................................................................................................................... 6
4.2. Dr. Garfield.................................................................................................................... 6
4.3. Dr. Barott, Dr. Seker, and Jorge Torres ......................................................................... 6
4.4. ERAU............................................................................................................................. 6
5. Use Cases.............................................................................................................................................. 6
5.1. Use Case 1: Start System ............................................................................................... 6
5.2. Use Case 2: Ride Cycle.................................................................................................. 8
5.3. Use Case 3: Ride Stop.................................................................................................. 10
5.4. Use Case 4: Emergency Stop....................................................................................... 10
5.5. Use Case 5: Ride Start ................................................................................................. 11
5.6. Use Case 6: Ride Reset................................................................................................ 12
6. Sequence Diagrams..............................................................................................................................13
6.1. Use Case 1.................................................................................................................... 13
6.2. Use Case 2.................................................................................................................... 14
6.3. Use Case 3.................................................................................................................... 15
6.4. Use Case 4.................................................................................................................... 15
6.5. Use Case 5.................................................................................................................... 16
7. Requirements .......................................................................................................................................17
7.1. Vehicle Requirements.................................................................................................. 17
7.2. Operations Computer Requirements............................................................................ 18
7.3. Arena Requirements..................................................................................................... 20
8. References............................................................................................................................................22
9. Glossary ...............................................................................................................................................23
10. Acronyms.............................................................................................................................................25
Project RIDES 95

1
2. Introduction
2.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 of Project RIDES,
the development team of Project RIDES, and all other parties involved with the design, construction,
or maintenance of Project RIDES.
2.2. Mission Statement
To produce a scale mockup of an amusement park ride with multiple autonomous vehicles that operate
simultaneously on converging and diverging pathways within an arena while avoiding collisions.
2.3. Scope
Project RIDES will direct multiple autonomous vehicles along converging and diverging pathways
without colliding in order to reduce operator involvement during ride operations. Ride operations will
instead be controlled by an automated operations computer.
The autonomous system envisioned is a scale mockup of an amusement park ride that will include
multiple vehicles, an operations computer, and an arena. Project RIDES will have multiple pathways
and dynamic speed control with sensors to detect obstructions in the vehicles’ paths. In 2012, 1,424
accidents occurred at amusement parks across the United States. [1]
Amusement park implementation
of the conceptual framework of Project RIDES would help to lower the annual number of accidents by
reducing the responsibilities of ride operators and the number of opportunities for human error.
2.4. Team Information
The following lists the members of the Project RIDES development team and their roles.
Name Role
Jordan Maziarka Scrum Master
Alex Spradlin Software Lead
Andrew Daws Developer
Branden Martin Developer
David Timmons Developer
2.5. Overview
This document is organized into sections to effectively communicate the intended functionalities of
Project RIDES and the project’s high-level description.
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 provides a high-level description of the project, including the constraints limiting
development, the assumptions made, and the project’s dependencies.
Project RIDES 96

2
Section 3 lists the major stakeholders involved in the development of Project RIDES and their impact
on its development.
Section 4 contains the use cases written to define the sequence of events that occur when the operator
initializes the ride, triggers an emergency stop, triggers a ride stop, resumes the ride after a ride stop, or
resets the ride after an emergency stop.
Section 5 supplements the use cases with system sequence diagrams.
Section 6 defines the functional and non-functional requirements for the vehicles, operations computer,
and arena.
The glossary contains detailed definitions of industry terms and terms exclusive to this document. The
table of acronyms included is a quick reference guide for all acronyms used within this document to
dispel ambiguity.
3. High-Level Description
3.1.Arena Configuration
The arena will consist of multiple block sections separated into several main areas and connected to
one another by 3 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 2 pathways that will serve as the main section of one circuit from station platform to
station platform. Each of the main pathways will consist of at least 3 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 97

3
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 1
more block sections between vehicles than a simple block system requires. The defining rule in a
moving block-light system is that there must always be at least 1 block section separating all ride
vehicles. The ideal case exists where 3 or 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 (defined within the
operations computer system). When only 2 block sections separate the vehicles, the vehicle in back
should slow down enough that the distance between the 2 vehicles increases in block sections. If only 1
block section separates the vehicles, the vehicle in back should stop and wait until more block sections
separate the vehicles. In the event that 2 ride vehicles exist on adjacent block sections, the entire ride
should emergency stop. The different 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. As such, the maintenance bay does not follow the same block restrictions that the main
pathways do. Block sections in the maintenance bay can be smaller than the length of a ride vehicle to
allow for compact placement of all ride vehicles in the maintenance bay prior to ride initialization. The
arrangement is shown in Figure 3.
Project RIDES 98

4
Figure 3. Depiction of the pathway inside the maintenance bay on which three vehicles
(labeled V1, V2, and V3) are each separated by 1 block section as required by the moving
block-light system.
3.2. Vehicle Operation and Coordinate System
Ride vehicles operating in the arena have a local coordinate system to define 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 vehicles motion. The center of the coordinate
system is at the center of mass.
Under normal operation, ride vehicles progress as long as they can identify the path beneath them
and there are no obstacles in front of them. The path they take is determined by which blocks are
activated by the operations computer. Each vehicle can perform these operations simultaneously.
The safety of this system is ensured by how the operations computer directs the vehicles. When
the ride starts, or after the vehicle has reached the block it was traveling to, the ride computer
determines the farthest block ahead of the vehicle to which it can safely travel and not have to
stop. This block is called the vehicle’s target location. When a vehicle’s target location is set to a
block, that block is considered effectively occupied, which means that even though no vehicle is in
the block, a vehicle will be entering the block shortly and no other vehicle should attempt to travel
to that block. The target location of a vehicle can only be set to effectively unoccupied blocks,
which means that the block is not occupied or effectively occupied. The normal operation of the
vehicles can be interrupted by an obstacle, ride stop, or emergency stop.
A ride stop is a function on a ride’s control system that causes all vehicles to stop at and remain as
so until further notice. The operator may choose to call a ride stop when a rider loses a personal
Project RIDES 99

5
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.
[2]
The operator can choose to call an emergency stop a danger is present to the riders or one of the
vehicles is not operating. The operations computer can also call an emergency stop it detects one
of these things occurring.
3.3.Constraints
The following are constraints defined by external sources that limit the development of Project RIDES
in accordance with the requirements listed in this document.
3.3.1. Regulation Constraints
Project RIDES is envisioned to be a scale mockup 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. [2]
3.3.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.
3.3.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.
3.4.Assumptions and Dependencies
The following are assumptions made during the design of Project RIDES and the project’s
dependencies.
3.4.1. Operation within the United States
This project will adhere to amusement park design standards defined within the United States of
America (USA). Use of Project RIDES outside of the USA would need to conform to the
standards for amusement park rides of that area.
3.5.User Characteristics
As Project RIDES is currently envisioned, a postsecondary 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 simplified mockup of an amusement park ride, so the situations requiring
either a ride stop or an emergency stop are few in number.
4. Stakeholders
The following are the individuals and groups that are involved in or have an interest in the development
and completion of Project RIDES.
Project RIDES 100

6
4.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. <deleted>
4.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.
4.3. Dr. Barott, Dr. Seker, and Jorge Torres
As the overseers of the capstone program, Dr. Barott, Dr. Seker, and Jorge Torres shall be following
the team’s progress and providing guidance throughout the academic year. They will be grading the
team based on their demonstration of the course requirements outlined in the course syllabus. They
will continue to help the team define the scope of the project and will oversee the development
process.
4.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 projects adhere to the
standards defined in the 2014-2015 Student Handbook. [3]
5. Use Cases
The following use cases describe the sequence of steps that occur when the operator initializes the ride,
triggers a ride stop, or triggers an emergency stop and the steps that occur during a complete ride cycle. The
extensions describe alternatives to the sequence of events listed in the main success scenario. The
extensions labeled with a * can occur at any point within the main success scenario.
5.1. Use Case 1: Start System
Primary Actors:
1. Operator
Description:
The operator initializes the ride, causing the vehicles to travel along the pathway from the maintenance
bay to the station platforms.
Preconditions:
1. The vehicles are off.
2. The operations computer is off.
Postconditions:
1. The operations computer is in the ready state.
3. The operations computer is sending signals to the vehicles wirelessly.
Main Success Scenario:
1. The operator positions the vehicles in the maintenance bay ordered by increasing priority (the
vehicles’ priorities are predefined within the operations computer).
Project RIDES 101

7
2. The operator orients the vehicles so that their <-x axis points> in the direction of the MTP
switch.
3. The operator powers on the vehicles.
4. The operator powers on the operations computer.
5. The operator instructs the operations computer to initialize the ride. <switched these two>
6. The operations computer starts sending signals conveying a speed to each vehicle.
7. The operations computer directs the vehicle in the maintenance bay with the highest priority
to proceed along the maintenance bay path.
8. The vehicle follows the path.
9. The vehicle enters the MTP switch.
10. The vehicle exits the MTP switch onto the pathway.
11. The vehicle travels along the pathway.
12. The vehicle enters the PTS switch.
13. The vehicle exits the PTS switch.
14. The vehicle travels along the station area path.
15. The operations computer directs the vehicle to an unoccupied station platform.
16. The vehicle enters the station platform.
17. The operations computer stops sending signals to the vehicle.
19. Steps 7 through 18 repeat until all station platforms are occupied.
Extensions:
*a. A vehicle loses power.
1. The operations computer triggers an emergency stop after 30 s of the vehicle remaining
in the same block section.
2. See Use Case 4.
3. The operator physically removes the vehicle from the arena.
*b. The operations computer loses power.
1. Moving vehicles slow to a halt.
*c. A vehicle does not receive the signals sent by the operations computer.
2. See extension *a.
*d. The vehicle detects an obstruction.
2. The obstruction is removed from the vehicle’s path.
3. The vehicle detects that the path is no longer obstructed.
4. The vehicle continues to travel along the path.
5. The vehicle resumes the main success scenario.
1.a. The vehicle is stationary for longer than 30 s in the same block section and does
not occupy a station platform.
1. The operations computer triggers an emergency stop.
2. See Use Case 4.
*e. The vehicle collides with an object or another vehicle.
1. See Use Case 4. <deleted one here>
3a. A vehicle does not power on.
4a. The operations computer does not power on.
1. The operator powers down the vehicles.
2. The operator services the operations computer.
5a. The vehicle does not receive the signals sent by the operations computer.
1. See extension *c.
7a. The next block section in the vehicle’s path is occupied by another vehicle.
1. The vehicle remains in the maintenance bay.
2. The block section becomes unoccupied.
3. The vehicle continues from step 7 of the main success scenario.
12a. The station platforms are occupied.
Project RIDES 102

8
1. The vehicle enters the block section on the vehicle’s pathway behind the PTS switch.
1.a. The block section on the vehicle’s pathway behind the PTS switch is occupied.
1. The vehicle enters the block section on the pathway that is 2 block sections
behind the vehicle closest to the PTS switch.
Frequency of Occurrence:
This use case will occur each time the ride begins. If an emergency stop is initiated, this use case
repeats after the situation leading to the emergency stop has been resolved, meaning the operator will
physically move the vehicles back into the maintenance bay.
5.2. Use Case 2: Ride Cycle
Primary Actors:
Description:
The operations computer instructs the vehicle to exit the station platform it occupies and then instructs
the vehicle down a pathway and back to a station platform.
Preconditions:
1. The operations computer is in the ready state (see Use Case 1).
2. The vehicles are in the ready state (see Use Case 1).
3. The operations computer is sending signals to the vehicles wirelessly (see Use Case 1).
5. The vehicles are not emergency stopped.
6. The vehicle occupies a station platform.
Postconditions:
1. The vehicle occupies a station platform.
1. The vehicle is awaiting directions at a station platform.
2. The operations computer directs the vehicle to exit the station platform.
3. The vehicle exits the station platform.
5. The vehicle enters the STP switch.
6. The operations computer determines which pathway the vehicle will be directed to take.
7. The operations computer directs the vehicle to take the pathway.
8. The vehicle exits the STP switch onto the directed pathway.
9. The vehicle travels along the pathway.
13. The operations computer directs the vehicle to an unoccupied station platform.
14. The vehicle enters the station platform.
Extensions:
Project RIDES 103

9
2. See Use Case 4.
*d. The vehicle detects an obstruction.
2. The obstruction is removed from the vehicle’s path.
3. The vehicle detects that the path is no longer obstructed.
4. The vehicle continues to travel along the path.
5. The vehicle resumes the main success scenario.
1.a. The vehicle is stationary in the same block section for longer than 30 s and does
not occupy a station platform.
1. The operations computer triggers an emergency stop .
2. See Use Case 4.
*e. The vehicle collides with an object or another vehicle.
1. See Use Case 4. <deleted one here>
2a. The vehicle does not occupy a station platform.
4. The vehicle continues from step 4 of the main success scenario.
2b. A vehicle is ready to leave another station platform.
1. The operations computer checks the vehicles’ priority levels.
2. The operations computer directs the vehicle with the higher priority level to leave the
station platform the vehicle occupies.
3. The vehicle with the higher priority level continues from step 3 of the main success
scenario.
4. The vehicle with the higher priority level enters the STP switch.
5. The vehicle with the lower priority level continues from step 3 of the main success
scenario.
10a. A vehicle on another pathway is traveling along the PTS switch.
1. The operations computer checks the vehicles’ priority levels.
2. The operations computer directs the vehicle with the lower priority level to decrease its
speed.
3. The vehicle with the higher priority level continues from step 11 of the main success
scenario.
4. The vehicle with the higher priority level travels along the station area path.
5. The vehicle with the lower priority level continues from step 11 of the main success
scenario.
This use case will occur multiple times for each vehicle after the ride has been initialized, barring the
need for ride maintenance, an emergency stop, or a ride stop.
Project RIDES 104

10
5.3. Use Case 3: Ride Stop
Primary Actors:
1. Operator
Description:
The operator triggers a ride stop, and the vehicles slow to a halt.
Preconditions:
1. The operations computer is on (see Use Case 1).
2. The vehicles are on (see Use Case 1).
Postconditions:
1. The operator instructs the operations computer to ride stop.
2. The operations computer stops sending signals to the vehicles.
3. The vehicles each slow to a halt. <deleted some>
Extensions:
2. See Use Case 4.
*d. The vehicle collides with an object or another vehicle.
1. See Use Case 4. <deleted some>
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.
5.4. Use Case 4: Emergency Stop
Primary Actors:
1. Operator
Description:
The operator or operations computer triggers an emergency stop, and the vehicles halt and power
down.
Preconditions:
Project RIDES 105

11
Postconditions:
1. The operator instructs the operations computer to emergency stop.
2. The operations computer stops sending signals to the vehicles.
3. The vehicles slow to a halt.
4. The vehicles power down.
Extensions:
*a. The operations computer loses power.
*b. A vehicle does not receive the signals sent by the operations computer.
This use case will occur approximately once a day in an amusement park ride.
5.5. Use Case 5: Ride Start
Primary Actors:
1. Operator
Description:
The operator resets a ride stop by instructing the operations computer to resume the ride.
Preconditions:
3. The operations computer is not sending signals to the vehicles wirelessly (see Use Case 3).
5. The vehicles are ride stopped.
Postconditions:
1. The operator instructs the operations computer to ride start.
2. The operations computer checks the block sections that were occupied by vehicles before the
ride stop was called.
3. The vehicles resume Use Case 2.
Extensions:
2. See Use Case 4.
Project RIDES 106

12
*d. The vehicle collides with an object or another vehicle.
1. See Use Case 4. <deleted some>
This use case will occur after every ride stop except for cases in which an emergency stop is called
during a ride stop (see Use Case 3 and Use Case 4).
5.6. Use Case 6: Ride Reset
Primary Actors:
2. Operator
Description:
The operator resets an emergency stop by physically removing the vehicles from the arena, placing the
vehicles in the maintenance bay, and telling the operations computer to initialize the ride.
Preconditions:
7. The operations computer is not sending signals to the vehicles wirelessly (see Use Case 3).
9. The vehicles are emergency stopped.
Postconditions:
3. The operations computer is in the ready state.
5. The operations computer is sending signals to the vehicles wirelessly.
4. The operator physically removes the vehicles from the arena.
5. The operator begins Use Case 1.
Extensions:
See Use Case 1.
This use case will occur after every emergency stop, followed by ride initialization.
Project RIDES 107

13
6. Sequence Diagrams
elaborated in Section 4.
6.1.Use Case 1
The sequence diagram illustrated in Figure 5 shows the steps that occur to initialize the ride. After the
operator turns on the vehicles, places the vehicles in the maintenance bay, and turns on the operations
computer, the operations computer starts sending out navigational signals to the vehicles, giving them
each a direction and a speed at which to travel.
Figure 5. Sequence Diagram for Use Case 1: System Start
Project RIDES 108

14
6.2.Use Case 2
The sequence diagram illustrated in Figure 6 shows the steps that occur in a ride cycle. After a vehicle
occupying a station platform, the operations computer directs it to move along the station area path.
When the vehicle reaches the STP switch, the operations computer chooses a pathway for the vehicle
to take and directs the vehicle down that path. When the vehicle reaches the pathway’s PTS switch, the
operations computer directs the vehicle to a station platform and then stops sending the vehicle
navigational signals.
Figure 6. Sequence Diagram for Use Case 2: Ride Cycle
Project RIDES 109

15
6.3.Use Case 3
The sequence diagram illustrated in Figure 7 shows the steps that occur when a ride stop is triggered.
After the operator triggers a ride stop on the operations computer, the operations computer stops
sending navigational signals to the vehicles. Consequently, the vehicles slow to a halt.
Figure 7. Sequence Diagram for Use Case 3: Ride Stop
6.4.Use Case 4
The sequence diagram illustrated in Figure 8 shows the steps that occur when an emergency stop is
triggered. After an emergency stop is triggered, the operations computer stops sending navigational
signals to the vehicles and sends commands to the vehicles to power down.
Figure 8. Sequence Diagram for Use Case 4: Emergency Stop
Project RIDES 110

16
6.5.Use Case 5
The sequence diagram illustrated in Figure 9 shows the steps that occur when the ride is reset from a
ride stop. After the operator resets the ride, the operations computer resumes sending navigational
signals to the vehicles.
Figure 9. Sequence Diagram for Use Case 5: Ride Start
5.6 Use Case 6
The sequence diagram illustrated in Figure 10 shows the steps that occur when the ride is reset from an
emergency stop. The operator physically removes the vehicles from their block sections and returns them to
the maintenance bay.
Figure 10. Sequence Diagram for Use Case 6: Ride Reset
Project RIDES 111

17
7. Requirements
7.1.Vehicle Requirements
7.1.1.Vehicle Functional Requirements
7.1.1.1. The vehicle shall travel on the floor of the arena.
7.1.1.2. The vehicle shall travel at a speed within 5 mm/s of the speed instructed by
the operations computer when the vehicle does not detect an obstruction.
7.1.1.3. The vehicle shall have a power source.
7.1.1.3.1. The vehicle’s power source shall supply 5V of DC power [TBR]
to all the vehicle’s systems.
7.1.1.3.2. The vehicle’s power source shall be located on the vehicle.
7.1.1.3.3. The vehicle’s power source shall be disconnected within 1 s
[TBR] of the vehicle receiving the command to emergency stop
from the operations computer.
7.1.1.4. The vehicle shall move along the vehicle’s positive x-axis when the vehicle
does not detect an obstruction.
7.1.1.5. The vehicle shall slow to a halt within 1 s [TBR] when the vehicle does not
detect a path.
7.1.1.6. The vehicle shall follow the pathway selected by the operations computer.
7.1.1.6.1. The geometric center of the vehicle shall deviate from its current
path no more than 5 cm [TBR] on either side of the vehicle’s x-
axis while moving forward.
7.1.1.7. The vehicle shall remain stationary if it does not detect a path.
7.1.1.8. The vehicle shall detect obstructions.
7.1.1.8.1. The vehicle shall disregard speed signals received from the
operations computer while the vehicle detects an obstruction.
7.1.1.8.2. The vehicle shall resume following instructions from the
operations computer when the vehicle does not detect the
obstruction.
7.1.1.8.3. The vehicle shall detect obstructions larger than 3 cm x 3 cm x 3
cm within 10 cm [TBR] of the vehicle when the obstruction is
within 10 degrees of the negative x-axis.
7.1.1.8.4. The vehicle shall reduce speed to half of its speed [TBR] when an
obstruction is detected between 10 cm and 3 cm of the vehicle
within 10 degrees [TBR] of the vehicle’s negative x-axis.
Project RIDES 112

18
7.1.1.8.5. The vehicle shall reduce speed to a halt when an obstruction is
detected closer than 3 cm within 10 degrees [TBR] of the vehicle’s
negative x-axis.
7.1.1.9. The vehicle shall have an on-board computer.
7.1.1.9.1. The vehicle’s on-board computer shall receive instructions from
the operations computer.
7.1.1.9.2. The vehicle’s on-board computer shall execute instructions from
the operations computer.
7.1.2.Vehicle Non-Functional Requirements
7.1.2.1. RIDES shall have at least 2 vehicles.
7.1.2.1.1. The number of vehicles shall adhere to the following equation, to
avoid section conflicts.
𝑁𝑢𝑛𝑏𝑒𝑟 𝑜𝑓 𝑉𝑒ℎ𝑖𝑐𝑙𝑒𝑠 =
(𝑇𝑜𝑡𝑎𝑙 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐵𝑙𝑜𝑐𝑘 𝑆𝑒𝑐𝑡𝑖𝑜𝑛𝑠)−1
3
7.1.2.2. The vehicle shall have a priority level unique amongst the system’s
vehicles.
7.2.Operations Computer Requirements
7.2.1.Operations Computer Functional Requirements
7.2.1.1. The operations computer shall verify that each vehicle’s power source is
enabled before ride initialization.
7.2.1.2. The operations computer shall direct vehicles out of the maintenance bay
when the ride is initialized.
7.2.1.2.1. The operations computer shall set the vehicle’s target location to
an effectively unoccupied block section.
7.2.1.3. The operations computer shall instruct a vehicle to the target location of
that vehicle.
7.2.1.4. The operations computer shall instruct vehicles in such a way that at least
one block section separates all vehicles when the vehicles are not in the
maintenance bay.
7.2.1.5. The operations computer shall initialize the ride.
7.2.1.5.1. The operations computer shall allow an operator to initialize the
ride.
7.2.1.6. The operations computer shall trigger ride stops.
7.2.1.6.1. The operations computer shall provide the operator with the ability
to trigger a ride stop.
Project RIDES 113

19
7.2.1.7. The operations computer shall trigger emergency stops.
7.2.1.7.1. The operations computer shall provide the operator with the ability
to trigger an emergency stop.
7.2.1.7.2. 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 [TBR] of the
expected time.
7.2.1.7.3. The expected time shall be determined by the operations
computer.
7.2.1.8. The operations computer shall reset ride stops.
7.2.1.8.1. The operations computer shall provide the operator with the option
to reset a ride stop.
7.2.1.9. The operations computer shall detect the vehicle exiting a block section.
7.2.1.9.1. The operations computer shall detect which block section the
vehicle is exiting.
7.2.1.10. The operations computer shall detect the vehicle entering a block section.
7.2.1.10.1. The operations computer shall detect which block section the
vehicle is entering.
7.2.1.11. The operations computer shall track which station platforms are occupied
and which are unoccupied.
7.2.1.12. The operations computer shall stop providing the vehicle with suggested
movement speeds when the vehicle enters a station platform.
7.2.1.13. 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.
7.2.1.13.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.
7.2.1.13.2. The operations computer shall direct a vehicle’s 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.
7.2.1.13.3. The operations computer shall direct a vehicle’s 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.
7.2.1.14. The operations computer shall provide a suggested movement speed for the
vehicle less than 25 cm/s [TBR].
Project RIDES 114

20
7.2.1.15. 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.
7.2.2.Operations Computer Non-Functional Requirements
7.2.2.1. The operations computer shall set a vehicle’s target location.
7.2.2.2. The operations computer shall mark a station platform as effectively
occupied when a vehicle’s target location is set to the specified station
platform.
7.2.2.3. The operations computer shall mark a block section as effectively occupied
when the block section is another vehicle’s target location.
7.2.2.4. The operations computer shall select an initial target location for each
vehicle.
7.2.2.4.1. The operations computer shall initiate cycling when all the
vehicles arrive at their respective target locations.
7.2.2.5. The operations computer shall determine when the vehicle dispatches from
the station platform.
7.2.2.5.1. The vehicle shall remain stationary at the station platform between
30 s to 60 s [TBR].
7.2.2.5.2. The operations computer shall check to see if the block sections in
front of the vehicle are unoccupied before instructing the vehicle
to leave the station platform.
7.3.Arena Requirements
7.3.1.Arena Non-Functional Requirements
7.3.1.1. The arena shall have a floor consisting of ¾ inch plywood [TBR] with
dimensions 200 cm x 200 cm x 20 cm [TBR].
7.3.1.2. The course shall have at least 2 pathways.
7.3.1.2.1. Each pathway shall be composed of at least 3 block sections.
7.3.1.2.2. Each block section shall end at the start of another block section.
7.3.1.2.3. Each block section shall be no shorter in length than a vehicle.
7.3.1.3. The course shall have a maintenance bay.
7.3.1.3.1. The maintenance bay shall be comprised of at least 2 block
sections [TBR].
7.3.1.3.2. The maintenance bay shall be connected to the MTP switch.
7.3.1.3.3. The maintenance bay shall be connected to the STP switch.
Project RIDES 115

21
7.3.1.4. The course shall have a station area.
7.3.1.4.1. The arena shall have fewer station platforms than the number of
vehicles.
7.3.1.4.2. The arena shall have at least 1 station platform.
7.3.1.5. The arena shall remain indoors.
Project RIDES 116

22
8. References
[1] National Safety Council Research and Statistical Services Group.(August 2013).
FIXED-SITE AMUSEMENT RIDE INJURY SURVEY, 2012 UPDATE [Online]. Available:
http://www.nsc.org/news_resources/injury_and_death_statistics/Documents/Injury-Facts-
Report.pdf
[2] Standard Practice for Design of Amusement Rides and Devices, ASTM Standard F2291-14.
[3] Student Handbook, Embry-Riddle Aeronautical University, Daytona Beach, FL, 2014
[4] “Railroad Accident Brief”,National Transportation Safety Board, Washington DC, RAB-11-07, October
31, 2011
Project RIDES 117

23
9. Glossary
Word Definition Aliases
Block Section A section of path that can safely accommodate a single vehicle. At no
time should a block ever contain more than one vehicle.
Block System A way of implementing high levels of safety into a ride by sectioning the
ride into block sections.
Effectively
Occupied
A state in which a block section exists where the block section is a
vehicle’s target location.
Effectively
Unoccupied
A state in which a block section exists where the block section is not the
target location of any vehicle.
Emergency
Stop
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 .[2]
E-Stop
Maintenance
Bay
A path or area in a ride on which vehicles can be stored and worked on.
Moving Block-
Light System
A more advanced version of a block system where a vehicle’s movement
is restricted based on the number of unoccupied blocks separating itself
and the vehicle in front of it. Vehicles halt in this system when one block
separates itself and the vehicle in front of it. The first moving block-light
system was introduced by the Walt Disney Company for use on the Walt
Disney World Monorail System, whereas it is known as MAPO (MAry
Poppins).[4]
Path The block sections that are in front of a vehicle between the vehicle and
its target location.
Pathway A chain of block sections that lead from the STP switch to the PTS
switch.
Obstruction An object that enters in front of the ride vehicle unexpectedly.
Occupied A state in which a block section exists where a vehicle is on the block
switch.
Operations
Computer
The device that monitors the movement and location of all of the
vehicles and the station platforms’ statuses and makes decisions
regarding vehicle movement based on this information.
Ride
Computer
Ride Stop A function on a ride’s control system that causes all vehicles to stop at
and remain as so until further notice.
Station Area An area that houses one or multiple station platforms and a pathway that
vehicles can be directed on to bypass the station platforms.
Station
Platform
A location where vehicles stop to simulate the loading and unloading of
passengers. The vehicles pause for a certain amount of time based on
estimated loading time.
Project RIDES 118

24
Switch A block that can direct a vehicle to one of multiple possible blocks, or
can direct a vehicle from one of multiple blocks into a single block.
Target
Location
The furthest open block that a vehicle can route to that is not about to be
occupied, or will be occupied by another vehicle before the origin
vehicle gets there.
Target
Block
Unoccupied A state in which a block section exists where no vehicle is on the block
switch.
Vehicle
Computer
The device onboard each of the vehicles that is able to read commands
from the operations computer and enact those commands in regards to
the vehicle’s movement.
Project RIDES 119

25
10. Acronyms
Word Definition
ERAU Embry-Riddle Aeronautical University
MTP Maintenance-to-Path
PTS Path-to-Station
RIDES Ride Integrating Dynamic Electronic System
STP Station-to-Path
TBD To be Defined
TBR To be Refined
USA United States of America
Project RIDES 120

Team Omni L2 Requirements Revised

More Related Content

What's hot

Viewers also liked

Similar to Team Omni L2 Requirements Revised

Team Omni L2 Requirements Revised