team omni l2 requirements revised

Project RIDESL2 SRSTeam 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 theintellectual property of Embry-Riddle Aeronautical University.

L2 System Requirements Specification, Rev. 1.3 Revision History

Revision History

Version Date

0.8 November 24, 20141.0 November 25, 20141.1 December 4, 20141.2 January 13, 20151.3 January 20, 2015

Project RIDES 1

L2 System Requirements Specification, Rev. 1.3 Contents

Contents

Revision History 1

1 Introduction 61.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Mission Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Team Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Stakeholders 72.1 Team Omni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Dr. Garfield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Dr. Barott, Dr. Seker, and Richard Tubbesing . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 ERAU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 High-Level Description 83.1 Arena Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Vehicle Operation and Coordinate System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Requirements Considerations 124.1 Project Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Operator Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Functional Decomposition of System 145.1 Operations Computer Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.2 Vehicle Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 User Interface Subsystem 166.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.2.1 Screen Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.3 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.3.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.4 User Interface Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.4.1 Use Case: Start Ride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.4.2 Use Case: Ride Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.4.3 Use Case: Resume from Ride Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.4.4 Use Case: Emergency Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.6 User Interface Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.7 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Scheduling Subsystem 297.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.2.1 Real-time Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.3 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7.3.1 User Interface Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.3.2 Static Arena Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.3.3 Vehicle Identification Voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7.4 Scheduling Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Project RIDES 2


7.4.1 Use Case: Update Vehicle Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4.2 Primary Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4.3 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4.4 Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4.5 Postconditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4.6 Main Success Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4.7 Frequency of Occurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.6 Scheduling Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.7 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8 Operations Computer I/O Subsystem 368.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8.2.1 Parallel Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368.3 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.3.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.3.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378.3.3 Vehicle Pathing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.4 Operations Computer I/O Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 388.4.1 Use Case: Block Section Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388.4.2 Use Case: Sensor Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408.6 Operations Computer I/O Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . 428.7 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9 Wireless Communications Subsystem 449.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

9.2.1 Module Synchronicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449.2.2 Parallel Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.3 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459.3.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.4 Wireless Communications Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 469.4.1 Use Case: Emergency Stop Signalled . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

9.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479.6 Wireless Communications Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . 489.7 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

10 Vehicle Motion Subsystem 5010.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5010.2 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

10.2.1 Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5010.3 Vehicle Motion Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

10.3.1 Use Case: Motor Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5110.4 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5210.5 Vehicle Motion Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5310.6 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

11 Vehicle Power Subsystem 5511.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5511.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

11.2.1 Vehicle Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5511.2.2 Electrical Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

11.3 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Project RIDES 3


11.3.1 Batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5611.4 Vehicle Power Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

11.4.1 Use Case: Vehicle Power Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5711.4.2 Use Case: Emergency Stop Power Down . . . . . . . . . . . . . . . . . . . . . . . . . . 58

11.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5911.6 Vehicle Power Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6111.7 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

12 Vehicle Pathfinding Subsystem 6312.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6312.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

12.2.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6412.3 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

12.3.1 Magnetic Field Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6412.4 Vehicle Pathfinding Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

12.4.1 Use Case: Path Finding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6512.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6612.6 Vehicle Pathfinding Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 6712.7 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

13 Vehicle Identification Subsystem 7013.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7013.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

13.2.1 Vehicle Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7013.3 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

13.3.1 Arena Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7113.3.2 Arena Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

13.4 Vehicle Identification Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7213.4.1 Use Case: Changing Block Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

13.5 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7413.6 Vehicle Identification Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 7513.7 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

14 Obstacle Detection Subsystem 7714.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7714.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

14.2.1 Parallel Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7714.3 Obstacle Detection Subsystem Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

14.3.1 Use Case: Obstacle Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7814.4 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7914.5 Obstacle Detection Subsystem Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 8014.6 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

15 Project RIDES Requirements 8215.1 Operations Computer Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 8215.2 Operations Computer Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 8315.3 Vehicle Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8415.4 Vehicle Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8515.5 Arena Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

16 Glossary 87

17 Acronyms 89

Project RIDES 4


A Appendix 91A.1 Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91A.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 DynamicElectronic System (RIDES). These requirements include the functional and non-functional requirements thatthe vehicles, Operations Computer, and arena must fulfill upon completion of the project at the end of theacademic year. This document is intended for the consumer, development team, and all other parties involvedwith 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 divergingpathways without colliding. Ride operations will be controlled by an automated Operations Computer ratherthan a human operator.

The autonomous system envisioned is a scale mock-up of an amusement park ride that includes multiplevehicles, an Operations Computer, and an arena. Project RIDES will have multiple pathways, dynamic speedcontrol, 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 anddoes not delve into the technical details of Project RIDES’ design and implementation. An overview of thesystem and each subsystem therein is provided. This document expands on the requirements enumerated inthe 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 RoleJordan Maziarka Scrum Master, Developer

Alex Spradlin DeveloperAndrew Daws Developer

Branden Martin DeveloperDavid Timmons Developer

1.5 Overview

This document is organized into sections to effectively communicate the intended functionalities ofProject 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 scopeof the project and the roles of the development team. Section 2 lists the major stakeholders involvedin 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 coordinatessystem. Section 4 contains the functional decomposition of the Project RIDES system. This section isbroken into an Operations Computer decomposition, wireless communications decomposition, and the vehicledecomposition.

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 requirementsand traceability matrix for the subsystem. Section 15 defines the functional and non-functional requirementsfor the vehicles, Operations Computer, and the arena. Section 16 includes a glossary that contains detaileddefinitions of industry terms and terms exclusive to this document. Section 17 is a table of all acronymsused 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 developmentand 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 ProjectRIDES, the team shall be graded based on the rigor and difficulty of the project as well as its progressover the year and ultimately, the project′s completion. The team will apply knowledge of course contentgained throughout their academic careers attending Embry-Riddle Aeronautical University (ERAU). Theteam 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 ProjectRIDES. 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 befollowing the team′s progress and providing guidance throughout the academic year. They will grade theteam based on their demonstration of the course requirements outlined in the course syllabus [1]. They willcontinue 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 onthe institution. To ensure the safety of everyone on campus, ERAU requires that project′s adhere to thestandards defined in the 2014-2015 Student Handbook [2]. The Student Handbook states that disciplinaryaction will ensue when damage is done to public or private property [2:54]. Disciplinary action will also begiven if Team Omni is found in possession of items considered dangerous, including incendiary devices andtools 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 usedfurther in this document and context the reader needs to understand the requirements and subsystemsdetailed in proceeding sections.

3.1 Arena Configuration

The arena will consist of multiple block sections separated into several main areas and connected toone another by three switches. The first of the main areas is the station area that houses multiple stationplatforms. Station platforms serve as the locations where Project RIDES will simulate passengers enteringand leaving vehicles in amusement park rides. Ride vehicles can travel along the station area path to reachthe station platforms, station-to-path (STP) switch, and the maintenance bay. The arena will have at leasttwo pathways that will serve as the main section of one circuit between station platforms. Each of the mainpathways will consist of at least three block sections. Finally, the maintenance bay will act as the locationthat vehicles reside in prior to ride initialization. The maintenance bay is split into several block sections toaccommodate all ride vehicles.

The main switches include the STP switch that connects the station area to the pathways and tothe maintenance bay, the path-to-station (PTS) switch that connects the pathways to the other end of thestation area, and the maintenance-to-path (MTP) switch that connects the maintenance bay to the pathwaylabeled Pathway 2 in Figure 1. A possible layout of the areas, switches, and block sections are shown inFigure 1.

Figure 1: Diagram of a possible layout of the arena with all the main areas listed in letters and the mainswitches 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 whenthe block section ahead of it is unoccupied. The moving block-light system requires at least one more blocksection between two vehicles than a simple block system requires. The defining rule in a moving block-lightsystem 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 canprogress at full speed (defined within the Operations Computer subsystem). When only two block sectionsseparate two vehicles, the vehicle in back slows down enough that the distance between the two vehiclesincreases in block sections. If only one block section separates two vehicles, the vehicle in back should stopand wait until more block sections separate the vehicles. In the event that two ride vehicles occupy adjacentblock sections, the entire ride should emergency stop. The different states of the moving block-light systemare illustrated in Figure 2.

Figure 2: Diagram of the possible states for a ride vehicle in the moving block-light system, where the circlesrepresent 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 servicedby 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 blocksshown are not to scale.

3.2 Vehicle Operation and Coordinate System

Ride vehicles operating in the arena have a local coordinate system to define their location relativeto the path they are following. In this system, a forward movement along the path is a change of positionin the positive x direction. A 90 degree clockwise rotation from the positive x -axis would face the positivey-axis. The origin for this coordinate system is the vehicle′s center of mass. The arrangement is illustratedin Figure 4.

Figure 4: Diagram of the local coordinate system of a ride vehicle. The orientation of the axes is based onthe current direction of the vehicle′s motion. The positive x -axis lies along the direction of movement. Thecenter 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 thereare no obstacles in front of them. The path they take is determined by which block sections are suppliedcurrent by the Operations Computer. Each vehicle can simultaneously scan for obstacles and detect currentbeneath 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 Computerdetermines the farthest block section ahead of the vehicle to which it can safely travel without stopping toavoid another vehicle. This block section is called the vehicle′s target location. When a vehicle′s targetlocation is set to a block section, that block section is considered effectively occupied, which means that even

Project RIDES 10


though no vehicle currently occupies the block section, a vehicle will be entering the block section shortlyand no other vehicle should attempt to travel to that block section. The target location of a vehicle canonly be set to effectively unoccupied block sections, meaning that the block section is not occupied and noteffectively occupied. The normal operation of the vehicles can be interrupted by an obstacle, a ride stop, oran emergency stop.

A ride stop is a function of a ride′s control system that causes all vehicles to stop and remain stoppeduntil further notice. In amusement parks, an operator may choose to call a ride stop when a rider loses apersonal possession on the ride or needs to have their harness adjusted. The operator can choose to resumethe 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 withdirect intervention from an operator. Typically, this must be reset by power cycling the ride [3]. In anamusement park, an operator can choose to call an emergency stop if a danger is present to the riders orone of the vehicles is not operating. The Operations Computer can also call an emergency stop if it detectsone 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 ProjectRIDES, 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 RIDESin 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 usedfor the enjoyment of passengers. Therefore, Project RIDES will be developed with consideration towardsthe design standards for amusement park rides defined in ASTM F2291-14 that are unrelated to passengersphysically occupying the ride vehicles [4]. The regulations involving passenger safety are disregarded becauseimplementing features to meet them are impossible with the limited budget. The budget constrains the sizeof the vehicles to be constructed. Regulations defined in ASTM F2291-14 specify minimum weight supportand require that ride vehicles are equipped with harnesses for the passengers. The small vehicle size preventsProject RIDES from adhering to these regulations. The regulation will be met that specifies a minimumseparation between two vehicles in terms of the size of each vehicle. This specification applies during rideoperation 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 theOperations Computer. After issuing instructions to the ride vehicles, the Operations Computer shouldcontinue to instruct and monitor each vehicle.

4.1.3 Budget

Project RIDES is funded entirely by the student development team. The financial resources availableto the team are limited to approximately $1000. This constraint limits the development of Project RIDESto a small number of vehicles unrepresentative of full-scale amusement park rides and limits the accuracywith 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 Omnimembers. 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 completionremains ambitious but attainable.

4.2 Assumptions and Dependencies

The following are assumptions made during the requirements extraction process of Project RIDES andthe 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 takingnote of attempting to adhere to standards as created by ASTM Committee F24 (Committee for AmusementRides 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 arepresent on US based rides based on operations of US theme parks, hence Project RIDES will have a USfocus operations wise.

Project RIDES 12

L2 System Requirements Specification, 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 operatethe 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. Theoperator must also know in what situations ride stops and emergency stops should be triggered. ProjectRIDES is a simplified mock-up of an amusement park ride, so the situations requiring either a ride stop oran emergency stop are few in number.

Project RIDES 13

L2 System Requirements Specification, 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 andpath for each vehicle. The vehicle is a slave, following all directions from the Operations Computer and canonly 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 flow between those two subsystems.

5.1 Operations Computer Decomposition

Figure 6 shows a high-level decomposition of the Operations Computer Subsystem. The subsystemswithin includes the I/O Subsystem and the Wireless Communications Subsystem, which outputs a signal tothe 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 allowsthe operator to initialize the ride, trigger emergency stops, trigger ride stops, reset ride stops, and observethe 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 througharena sensors. The Scheduling Subsystem is the middle man; it connects the operator with the arena byconnecting 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 OperationsComputer I/O Subsystem to output a current through a specific wire. The Operations Computer Subsystemfulfills 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 thebase, providing the power to all other subsystems while also allowing the functionality of cutting power viaa 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 themagnetic field from the arena wire and determines the direction in which the vehicle must proceed. ThePathfinding Subsystem also accepts input from the Obstacle Detection Subsystem, which stops the vehiclewhen an obstruction is detected. The other two subsystems are in direct communication with the OperationsComputer. The Vehicle Identification Subsystem allows the Operations Computer to determine the locationof each vehicle independently while the Wireless Communications Subsystem receives commands from theOperations 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 isconnected to.

Project RIDES 15

L2 System Requirements Specification, 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 ridestops, to trigger emergency stops, and to initialize the ride. The User Interface Subsystem will be a graphicaluser interface run from an application.

Figure 8: Block diagram for the User Interface Subsystem. This includes the user interface that the operatorinterfaces with and the processor used to process the inputs.

Figure 9: Flow diagram showing how the user interface communicates with the operator and the OperationsComputer I/O subsystem.

Project RIDES 16


Figure 10: An example user interface that includes options for the operator to start the ride, trigger a ridestop, and trigger an emergency stop. Grey buttons indicate that the option is disabled. The left side showsthe user interface before the ride has been started. The right side shows the user interface after the ride hasbeen started. After the ”Init Ride” button is pressed, it is disabled, and the two remaining buttons becomeavailable.

6.2 Constraints

The following are constraints defined 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 tabletscreen has a height between 7” and 11” and a width between 5” and 7” [5]. A small screen size requiresthat only pertinent information to the operator be included in the user interface, so that they can navigateoptions 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 withmicrocontrollers 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. Themain success scenario describes what happens within the system when nothing unexpected happens. Theextensions describe alternatives to the sequence of events listed in the main success scenario. Extensionslabeled 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 powerblock 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 off.

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 caserepeats after the situation leading to the emergency stop has been resolved, meaning that the operator willphysically 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 aretriggered 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 calledduring 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 powerdown.



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 off the vehicle.


This use case will occur approximately once a day on an amusement park ride. For this project, thiswill 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 caseelaborated 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 optionto 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 poweringblock 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 aride stop. The operator chooses the resume from ride stop option from the user interface, and the OperationsComputer 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 istriggered. After an emergency stop is triggered, the Operations Computer stops powering block sections andwirelessly 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.6The graphical user interface shall provide the operator with the option to trigger anemergency stop.

15.1.6.1The option to trigger an emergency stop shall be disabled until the ride has beeninitialized.

15.1.7The graphical user interface shall provide the operator with the option to trigger aride stop.

15.1.7.1 The option to trigger a ride stop shall be disabled until the ride has been initialized.

15.1.7.2The option to trigger a ride stop shall be disabled after a ride stop was previouslytriggered and the ride has not yet been reinitialized.

15.1.8The graphical user interface shall provide the operator with the option to initializethe ride.

15.1.8.1The option to initialize the ride shall be disabled after the ride has been initializeduntil 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 Computershall verify that each vehicle’s powersource is enabled before ride initializa-tion

With the current design, this isnot possible. Communication isone-way: from the operationscomputer to the vehicle.

15.1.1: The Operations Computershall initialize the ride.

7.2.1.5: The Operations Computershall initialize the ride.

No change

Redacted7.2.1.5.1: The Operations Computershall allow an operator to initialize theride.

This requirement was redundantdue to 15.1.1 and 15.1.8.

15.1.2: The Operations Computershall trigger ride stops.

7.2.1.6: The Operations Computershall trigger ride stops.

No change

Redacted7.2.1.6.1: The Operations Computershall provide the operator with the abil-ity to trigger a ride stop.


15.1.3: The Operations Computershall reset ride stops.

7.2.1.7: The Operations Computershall reset ride stops.

No change

Redacted7.2.1.8.1: The Operations Computershall provide the operator with the op-tion to reset a ride stop.

This requirement was redundantdue to 15.1.3.

15.1.4: The Operations Computershall trigger emergency stops.

7.2.1.7: The Operations Computershall trigger emergency stops.

No change

Redacted7.2.1.7.1: The Operations Computershall provide the operator with the abil-ity to trigger an emergency stop.


15.1.5: The Operations Computershall provide a graphical user interface.

None Added

15.1.6: The graphical user interfaceshall provide the operator with the op-tion to trigger an emergency stop.

None Added

15.1.6.1: The option to trigger anemergency stop shall be disabled untilthe ride has been started.

None Added

15.1.7: The graphical user interfaceshall provide the operator with the op-tion to trigger a ride stop.

None Added

15.1.7.1: The option to trigger a ridestop shall be disabled until the ride hasbeen started.

None Added

15.1.7.2: The option to trigger a ridestop shall be disabled after a ride stopwas previously triggered and the ridehas not yet been reinitialized.

None Added

Project RIDES 27


15.1.8: The graphical user interfaceshall provide the operator with the op-tion to initialize the ride.

None Added

15.1.8.1: The option to start the rideshall be disabled after the ride has beenstarted until the operator ends the ride.

None Added

Table 2: The traceability matrix linking each L2 User Interface Subsystem requirement to its relevant L1requirement. This includes an explanation of the reason behind each change.

Project RIDES 28

L2 System Requirements Specification, 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 vehicleindependently. The subsystem receives input from the Operations Computer I/O Subsystem about vehiclelocations within the arena. Based on this information, it calculates which block sections should be poweredand outputs the information back to the Operations Computer I/O Subsystem. It also determines when avehicle should visit a station platform and the duration of the stop.

Figure 15: Block diagram for the Scheduling Subsystem. The subsystem includes the scheduling programmitself and the processor that runs the code durring operation.

Figure 16: Flow diagram for the Scheduling Subsystem. The subsystem is in direct communication with theuser 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 avehicle does not approach the end of a block section and halt because the proceeding block section is notyet powered. This would occur if the Operations Computer I/O Subsystem had not received the commandto 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 UserInterface Subsystem, the Scheduling Subsystem shall cease to function and may output erroneous data tothe Operations Computer I/O Subsystem. Should this happen, the operator will be responsible for manuallyresetting 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 changesto the arena layout are made, the arena representation within the subsystem must be manually updatedto reflect the new configuration. The subsystem requires knowledge of which block sections correspond towhich sensor inputs from the Operations Computer I/O Subsystem and which block sections are connectedend-to-end.

7.3.3 Vehicle Identification Voltage

The subsystem must have an identifying voltage hard coded for each vehicle. The identifying voltageis 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 Subsystemwhen a vehicle passes over an arena sensor. The main success scenario describes what happens within thesystem when nothing unexpected happens. The extensions describe alternatives to the sequence of eventslisted in the main success scenario. Extensions labeled with a * can occur at any point within the mainsuccess 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 thevehicle’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 identification voltage back to the Operations ComputerI/O Subsystem.

5. The scheduling program checks the vehicle’s identification to determine which vehicle triggered thesensor.

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 severaltimes 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 inputfrom the arena sensor and informs the scheduling program, which updates its knowledge of vehicle locationsand 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.1The Operations Computer shall trigger an emergency stop if a vehicle, not currentlyat a station platform, fails to reach the end of the currently occupied block sectionwithin 30 s of the expected time.

15.1.4.2 The expected time shall be calculated by the Operations Computer.

15.1.9The Operations Computer shall direct vehicles out of the maintenance bay when theride is initialized.

15.1.11The Operations Computer shall set the vehicle’s target location to an effectivelyunoccupied block section after initialization.

15.1.12The Operations Computer shall set the vehicle’s target location to an effectivelyunoccupied 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.14The Operations Computer shall instruct vehicles in such a way that at least one blocksection 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.19The Operations Computer shall stop providing the vehicle with suggested movementspeeds when the vehicle enters a station platform.

15.1.20The Operations Computer shall provide a suggested movement speed to the vehiclewith regard to the number of blocks separating the vehicle from the vehicle in frontof it along the vehicle’s pathway.

15.1.20.1The Operations Computer shall provide a suggested movement speed of 0 cm/s forthe vehicle when the vehicle has 1 block section separating itself and the vehicle infront of it.

15.1.20.2The Operations Computer shall direct a vehicle’s movement speed to be less than 5cm/s when the vehicle has 2 block sections separating itself and the vehicle in frontof it.

15.1.20.3The Operations Computer shall direct a vehicle’s movement speed to be 15 cm/swhen the vehicle has 3 or more block sections separating itself from the vehicle infront of it.

15.1.21The Operations Computer shall direct the vehicle with the lower priority level todecrease its speed when the vehicle is the same number of block sections behind thePTC 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 emergencystop if a vehicle, not currently ata station platform, fails to reachthe end of the currently occupiedblock section within 30 s of theexpected time.

7.2.1.7.2: The OperationsComputer shall trigger an emer-gency stop if a vehicle, notcurrently at a station platform,fails to reach the end of thecurrently occupied block sec-tion within 30 s [TBR] of theexpected time.

No change

15.1.4.2: The expected timeshall be calculated by the Oper-ations Computer.

7.2.1.7.3: The expected timeshall be determined by the Op-erations Computer.

”determined” was replaced with”calculated” because the wordbetter fits the situation.

15.1.9: The Operations Com-puter shall direct vehicles out ofthe maintenance bay when theride is initialized.

7.2.1.2: The Operations Com-puter shall direct vehicles out ofthe maintenance bay when theride is initialized.

No change

15.1.11: The Operations Com-puter shall set the vehicle’s tar-get location to an effectively un-occupied block section.

7.2.1.2.1: The OperationsComputer shall set the vehicle’starget location to an effectivelyunoccupied block section.

No change

15.1.13: The Operations Com-puter shall instruct a vehicle tothe target location of that vehi-cle.

7.2.1.3: The Operations Com-puter shall instruct a vehicle tothe target location of that vehi-cle.

No change

15.1.14: The Operations Com-puter shall instruct vehicles insuch a way that at least one blocksection separates all vehicles.

7.2.1.4: The Operations Com-puter shall instruct vehicles insuch a way that at least oneblock section separates all vehi-cles when the vehicles are not inthe maintenance bay.

The part of the L1 requirementthat was removed was redun-dant.

15.1.15: The Operations Com-puter shall detect the vehicle en-tering a block section.

7.2.1.10: The Operations Com-puter shall detect the vehicle en-tering a block section.

No change

15.1.15.1: The OperationsComputer shall detect whichblock section the vehicle isentering.

7.2.1.10.1: The OperationsComputer shall detect whichblock section the vehicle is enter-ing.

No change

15.1.16: The Operations Com-puter shall detect the vehicle de-parting a block section.

7.2.1.9: The Operations Com-puter shall detect the vehicle ex-iting a block section.

”exiting” was replaced with ”de-parting” because the word betterfits the situation.

15.1.16.1: The OperationsComputer shall detect whichblock section the vehicle isdeparting.

7.2.1.9.1: The OperationsComputer shall detect whichblock section the vehicle isexiting.

”exiting” was replaced with ”de-parting” because the word betterfits the situation.

15.1.17: The Operations Com-puter shall track the occupancystates of all station platforms.

7.2.1.11: The Operations Com-puter shall track which sta-tion platforms are occupied andwhich are unoccupied.

Changed to be more concise, butthe meaning remains unchanged.

Project RIDES 34


15.1.19: The Operations Com-puter shall stop providing the ve-hicle with suggested movementspeeds when the vehicle enters astation platform.

7.2.1.12: The Operations Com-puter shall stop providing the ve-hicle with suggested movementspeeds when the vehicle enters astation platform.

No change

15.1.20: The Operations Com-puter shall provide a suggestedmovement speed to the vehi-cle with regard to the numberof blocks separating the vehiclefrom the vehicle in front of italong the vehicle’s pathway.

7.2.1.13: The Operations Com-puter shall provide a suggestedmovement speed to the vehi-cle with regard to the numberof blocks separating the vehiclefrom the vehicle in front of italong the vehicle’s pathway.

No change

15.1.20.1: The OperationsComputer shall provide a sug-gested movement speed of 0cm/s for the vehicle when thevehicle has 1 block sectionseparating itself and the vehiclein front of it.

7.2.1.13.1: The OperationsComputer shall provide a sug-gested movement speed of 0 cm/sfor the vehicle when the vehiclehas 1 block section separating it-self and the vehicle in front of it.

No change

15.1.20.2: The OperationsComputer shall direct a vehicle’smovement speed to be less than5 cm/s when the vehicle has 2block sections separating itselfand the vehicle in front of it.

7.2.1.13.2: The OperationsComputer shall direct a vehicle’smovement speed to be less than 5cm/s [TBR] when the vehicle has2 block sections separating itselfand the vehicle in front of it.

No change

15.1.20.3:. The OperationsComputer shall direct a vehicle’smovement speed to be 15 cm/swhen the vehicle has 3 or moreblock sections separating itselffrom the vehicle in front of it.

7.2.1.13.3: The OperationsComputer shall direct a vehicle’smovement speed to be 15 cm/s[TBR] when the vehicle has 3or more block sections separatingitself from the vehicle in front ofit.

No change

15.1.21: The Operations Com-puter shall direct the vehiclewith the lower priority level todecrease its speed when the vehi-cle is the same number of blocksections behind the PTC switchas a vehicle on another pathway.

7.2.1.15: The Operations Com-puter shall direct the vehiclewith the lower priority level todecrease its speed when the vehi-cle is the same number of blocksections behind the PTC switchas a vehicle on another pathway.

No change

15.3.1: The vehicle shall followthe pathway selected by the Op-erations Computer.

7.1.1.6: The vehicle shall followthe pathway selected by the Op-erations Computer.

No change

Table 4: The traceability matrix linking each L2 Scheduling Subsystem requirement to its relevant L1requirement. This includes an explanation of the reason behind each change.

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’sblock sections. This signal is used by the vehicle’s Pathfinding Subsystem. The subsystem is also used togather 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 majorcomponents needed for the subsystem to function, but does not list the subsystems that it communicateswith.

Figure 19: Flow diagram showing how the Operations Computer I/O Subsystem communicates with theScheduling Subsystem and the arena.

8.2 Constraints

The following are constraints defined by external sources that limit the development of the OperationsComputer 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 sensorinputs 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 thesensors to be taken immediately.


The following are assumptions made during the design of the Operations Computer I/O Subsystemand the subsystem’s dependencies.

8.3.1 Power

This subsystem is dependent on both the Operations Computer and the vehicles receiving power fromtheir 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 tostart 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 vehiclepathing does not work correctly, the Operations Computer can only detect the problem, it cannot help toresolve 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 Computerprovides power to block sections and detects vehicles crossing arena sensors. The main success scenariodescribes what happens within the system when nothing unexpected happens. The extensions describealternatives to the sequence of events listed in the main success scenario. Extensions labeled with a * canoccur 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 interpretsthe 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 specific 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 oremergency 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 severaltimes 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 throughthe 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 asensor, 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.2The vehicle shall move along the vehicle’s positive x-axis when the vehicle receives aninput from the Operations Computer and does not detect an obstruction

15.3.3The 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




15.1.1: The Operations Com-puter shall initialize the ride.

7.2.1.5: The Operations Com-puter shall initialize the ride.

No change

15.1.15: The Operations Com-puter shall detect the vehicle en-tering a block section.

7.2.1.10: The Operations Com-puter shall detect the vehicle en-tering a block section.

No change

15.1.15.1: The OperationsComputer shall detect whichblock section the vehicle isentering.

7.2.1.10.1: The OperationsComputer shall detect whichblock section the vehicle is enter-ing.

No change

15.1.16: The Operations Com-puter shall detect the vehicle de-parting a block section.

7.2.1.10: The Operations Com-puter shall detect the vehicle ex-iting a block section.

Changed exiting to departing forclarity

15.1.16.1: The OperationsComputer shall detect whichblock section the vehicle isdeparting.

7.2.1.9.1: The OperationsComputer shall detect whichblock section the vehicle isexiting.

Changed exiting to departing forclarity

15.1.18: The Operations Com-puter shall provide a suggestedmovement speed to the vehicle.

7.2.1.13: The Operations Com-puter shall provide a suggestedmovement speed to the vehicle

No change

15.3.1: The vehicle shall followthe pathway selected by the Op-erations Computer.


No change

15.3.2: The vehicle shall movealong the vehicle’s positive x -axis.

7.1.1.4: The vehicle shall movealong the vehicle’s negative x -axis when the vehicle does notdetect an obstruction.

Changed to add functionality torequire the vehicle to alwaysmove forward rather than back-wards.

15.3.3: The vehicle’s on-boardcomputer 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 OperationsComputer.

No change

Table 6: The traceability matrix linking each L2 Operations Computer I/O Subsystem requirement to itsrelevant 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 fromthe Operations Computer to all vehicles on the arena simultaneously. The subsystem consists of a wirelessmodule or transmitter on the Operations Computer and a wireless module or receiver on each vehicle. Thecommunication is one-way, and no handshaking is done. This one-way communication is given its ownsubsystem to provide a redundant way of stopping vehicle motion. When an emergency stop command isreceived on the vehicle side, the power subsystem is disconnected from all other subsystems to stop all vehicleoperation.

Figure 22: Block diagram for the Wireless Communications Subsystem.

Figure 23: Flow diagram showing how the Wireless Communications Subsystem communicates with theUser Interface Subsystem and the Pathfinding Subsystem.

9.2 Constraints

The following are constraints defined by external sources that limit the development of the WirelessCommunications 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 signalat specific instances in time to receive the intended message.

Project RIDES 44



The Wireless Communications Subsystem is intended to operate asynchronously with other vehiclesubsystems using the CPU. The vehicle should should not cease path-following operations while checking forincoming messages or authenticating received messages. Additionally, the wireless modules cannot interferewith the Pathfinding Subsystem which detects frequencies from the magnetic field generated by the arenawire.


The following are assumptions made during the design of the Wireless Communications Subsystem andthe subsystem’s dependencies.

9.3.1 Message Authenticity

It is not assumed that the vehicle will only receive messages sent by the Operations Computer. Toprotect 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 processedoutside 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 CommunicationsSubsystem when an emergency stop has been triggered. The main success scenario describes what happenswithin the system when nothing unexpected happens. The extensions describe alternatives to the sequenceof events listed in the main success scenario. Extensions labeled with a * can occur at any point within themain 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 andpower 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 userinterface.

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, thiswill 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, theOperations 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.3The vehicle’s on-board computer shall execute instructions from the Operations Com-puter.

15.3.8The 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.3The vehicle shall verify the authenticity of a message received before responding toits content.

Table 7: Requirements pertaining to the Wireless Communications Subsystem.

Project RIDES 48




15.1.4: The Operations Com-puter shall trigger emergencystops.

7.2.1.7: The Operations Com-puter shall trigger emergencystops.

No change

15.1.22: The Operations Com-puter shall encrypt messages be-fore sending them.

None Added

15.3.3: The vehicle’s on-boardcomputer 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 OperationsComputer.

No Change

15.3.8: The vehicle’s powersource shall be disconnectedwithin 1 s of the vehicle authen-ticating the command to emer-gency stop from the OperationsComputer.

7.1.1.3.3: The vehicle’s powersource shall be disconnectedwithin 1 s [TBR] of the vehiclereceiving the command to emer-gency stop from the OperationsComputer.

”receiving” was replaced with”authenticating” because the ve-hicle shall authenticate the mes-sage after receiving it and beforeprocessing it.

15.4.3: The vehicle shall verifythe 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 itsrelevant 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 PathfindingSubsystem. This system consists of the wheels and motors on the vehicle as well as the controller used topower the motors. The system receives power from the Vehicle Power Subsystem and a signal from thevehicle 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 PathfindingSubsystem and the Vehicle Power Subsystem.


The following are assumptions made during the design of the Vehicle Motion Subsystem and thesubsystem’s dependencies.

10.2.1 Surface

This subsystem assumes that the vehicle is located on the arena floor, which provides a smooth, flatsurface. 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 fromthe Pathfinding Subsystem regarding motor control. The main success scenario describes what happenswithin the system when nothing unexpected happens. The extensions describe alternatives to the sequenceof events listed in the main success scenario. Extensions labeled with a * can occur at any point within themain 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 controllerand 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 receivesinput from the Pathfinding Subsystem regarding motor control. The vehicle motor controller then controlsthe 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.5The Vehicle Motion Subsystem shall move the vehicle based on the input from thePathfinding Subsystem.

15.3.5.1 The vehicle shall have a speed that does not exceed 0.3 m/s.

15.1.5.2The vehicle shall travel within 10 mm/s of the speed expected due to the PathfindingSubsystem 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 MotionSubsystem shall move the vehi-cle based on the input from thePathfinding Subsystem.

7.1.1.1: The vehicle shall travelon the floor of the arena.

Updated to reflect the subsystemdecomposition.

15.3.5.1: The vehicle shall havea speed that does not exceed 0.3m/s.

None Added

15.3.5.2: The vehicle shalltravel within 10 mm/s of thespeed expected due to thePathfinding Subsystem output.

7.1.1.2: The vehicle shall travelat a speed within 5 mm/s of thespeed instructed by the Opera-tions Computer when the vehicledoes not detect an obstruction.

The previous wording did nottake into account the pathfind-ing. Our testing also showed thatthe vehicle speed was more vari-able than anticipated.

15.3.6: The Vehicle MotionSubsystem shall control each mo-tor independently.

None Added

Table 10: The traceability matrix linking each L2 Vehicle Motion Subsystem requirement to its relevant L1requirement. This includes an explanation of the reason behind each change.

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 explicitpurpose 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 thatcan 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 MotionSubsystem, vehicle microcontroller, and the operator.

11.2 Constraints

The following are constraints defined by external sources that limit the development of the VehiclePower 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 andbe fully contained within the volume of the vehicle. This is in part due to the fact that the vehicles must beable 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 thanwhat is needed to power all the vehicles systems. The Vehicle Power Subsystem must also be able to supplyenough current simultaneously to all of the vehicle’s subsystems so that it can run all of the subsystemssimultaneously.


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 duringthe operation of Project RIDES batteries will only be discharged, not charged. It is also assumed that thebatteries 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 thevehicle and when an emergency stop is triggered within the Vehicle Power Subsystem. The main successscenario describes what happens within the system when nothing unexpected happens. The extensionsdescribe alternatives to the sequence of events listed in the main success scenario. Extensions labeled witha * 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 toall 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 wouldtrigger 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, effectively emergency stopping thevehicle.

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 triggeredemergency 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, effectively emergency stopping thevehicle.


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 powerson a vehicle using a pilot device on the vehicle. The pilot device temporarily provides power to the vehiclemicrocontroller, 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 receivesan emergency stop and the vehicle microcontroller stops sending signal to the relay to remain latched. Thevehicle 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.8The vehicle’s power source shall be physically disconnected within 1 s of the vehicleauthenticating an emergency stop command.

Table 11: Requirements pertaining to the Vehicle Power Subsystem

Project RIDES 61




15.3.7: The vehicle’s powersource shall supply DC Power toall of the vehicle’s systems.

7.1.1.3.1: The vehicle’s powersource shall supply 5 V of DCpower [TBR] to all the vehicle’ssystems.

The requirement was split intotwo and the voltage level was re-fined.

15.3.8: The vehicle’s powersource shall be physically discon-nected within 1 s of the vehicleauthenticating the command toemergency stop command.

7.1.1.3.3: The vehicle’s powersource shall be disconnectedwithin 1 s [TBR] of the vehiclereceiving the command to emer-gency stop from the operationscomputer.

No change needed.

Table 12: The traceability matrix linking each L2 Vehicle Power Subsystem requirement to its relevant L1requirement. This includes an explanation of the reason behind each change.

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 basedon the input from the Obstacle Detection Subsystem and the Pathfinding Subsystem’s own sensors. Thesubsystem 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 appropriatemotor outputs to stay along the path, if a path is detected.

Figure 32: Block diagram for the Pathfinding Subsystem.

Figure 33: Flow diagram showing how the Pathfinding Subsystem communicates with the Wireless Commu-nications Subsystem, the arena, the Obstacle Detection Subsystem, and the Vehicle Motion Subsystem.

Project RIDES 63


12.2 Constraints

The following are constraints defined by external sources that limit the development of the VehiclePathfinding 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 andpower 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 thearena wire. Due to this limitation, the arena is dependent on operating in an environment that does nothave 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 inthe arena. The main success scenario describes what happens within the system when nothing unexpectedhappens. 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 stopsand 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 followspaths in the arena. The vehicle receives input from the magnetic sensors that are reading the current in theblock 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.4The Pathfinding Subsystem shall output one motor signal to the Vehicle MotionSubsystem 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.1Each Pathfinding Subsystem sensor shall read a signal from the arena wire when thesensor is less than 2 cm from the arena wire.

15.3.9.2The Pathfinding Subsystem sensors shall read a signal with an amplitude that changesrelative to the inverse of the distance from the arena wire.

15.3.10The Pathfinding Subsystem shall direct the vehicle such that the geometric center ofthe vehicle is less than 5 cm from at least 1 point on the arena wire.

15.3.11The Pathfinding Subsystem shall accept a value between 0 to 1 from the ObstacleDetection Subsystem.

15.3.11.1The motor signal output shall be scaled by the input from the Obstacle DetectionSubsystem.

15.3.12The Pathfinding Subsystem shall calculate the frequency of the signal input by themagnetic field sensors.

15.3.12.1The motor signal outputs shall be set to 0 within 1 s if the calculated frequency isnot 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.


The Pathfinding Subsystem hasno direct knowledge of the Op-erations Computer and is not indirect control of the motors. Therequirement was updated to re-flect this.

15.3.4.2: The motor signal out-put shall be 0 if no clear path isdetected.

None Added

15.3.9: The Pathfinding Sub-system shall read magnetic fieldsignals from the arena wire.

None Added

15.3.9.1: Each PathfindingSubsystem sensor shall read asignal from the arena wire whenthe sensor is less than 2 cm fromthe arena wire.

None Added

15.3.9.2: The Pathfinding Sub-system sensors shall read a signalwith an amplitude that changesrelative to the inverse of the dis-tance from the arena wire.

None Added

15.3.10: The Pathfinding Sub-system shall direct the vehiclesuch that the geometric center ofthe vehicle is less than 5 cm fromat least 1 point on the arena wire.

7.1.1.6.1: The geometric centerof the vehicle shall deviate fromits current path no more than 5cm [TBR] on either side of thevehicles x-axis while moving for-ward.

The L1 requirement left in toomuch ambiguity, the L2 require-ment can only be fulfilled bystaying on the path, as no twopaths are within 10 cm of eachother.

15.1.10: The Pathfinding Sub-system shall output one motorsignal to the Vehicle Motion Sub-system for each motor controlledby the Vehicle Motion Subsys-tem.

None Added

15.3.11: The Pathfinding Sub-system shall accept a value be-tween 0 to 1 from the ObstacleDetection Subsystem.

None Added

15.3.11.1: The motor signaloutput shall be scaled by the in-put from the Obstacle DetectionSubsystem.

7.1.1.4: The vehicle shall movealong the vehicle’s positive x -axiswhen the vehicle does not detectan obstruction.

The decomposition of thePathfinding Subsystem allowedfor a system that would takeinto account all possible outputsfrom the Obstacle DetectionSubsystem in one requirement.

Project RIDES 68


15.3.12: The Pathfinding Sub-system shall calculate the fre-quency of the signal input by themagnetic field sensors.

None Added

15.3.12.1: The motor signaloutputs shall be set to 0 within1 s if the calculated frequency isnot within 10% of the expectedoperating 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 slowto a halt within 1 s [TBR] whenthe vehicle does not detect apath.

The frequency of the arena wireis used to identify the path. Therequirement was updated to re-flect that system.

Table 14: The traceability matrix linking each L2 Pathfinding Subsystem requirement to its relevant L1requirement. This includes an explanation of the reason behind each change.

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 thevehicle to the Operations Computer when the vehicle reaches the edge of a block section and triggers asensor. On the vehicle, this subsystem consists of two different contact points with the arena and a resistivenetwork. The subsystem will receive a reference voltage from the arena’s block sensors and act as a voltagedivider, 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

The following are constraints defined by external sources that limit the development of the VehicleIdentification 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, thereforeit is constrained by the size requirements of the vehicle chassis. In addition to this, the system will operatepassively 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 flat surface such that both contact pointswith the arena are at the same height and can make a secure connection with the sensors on the arena floor.

13.3.2 Arena Sensors

This subsystem is dependent on the voltage supplied by the lead pad on the arena block sensors. Ifthis voltage is not stable or at the correct value, the subsystem may return an incorrect value, which couldinterfere 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. Extensionslabeled with a * can occur at any point within the main success scenario.

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 pointson the Vehicle Identification Subsystem connect with the sensors on the arena floor. The voltage providedby the sensors is divided by an amount that is unique to the vehicle, and the new voltage is returned to theOperations 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 detectedand 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 arenafloor 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 overa sensor in the arena. The contact points of the Vehicle Identification Subsystem connect with the sensors onthe 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.

Figure 37: Sequence Diagram for the Use Case: Changing Block Sections

Project RIDES 74


13.6 Vehicle Identification Subsystem Requirements


15.3.13The Vehicle Identification Subsystem shall accept an input voltage from the arenablock sensors.

15.3.13.1The input voltage shall be determined by the difference in voltage across the frontand back contact points.

15.3.14The input voltage to the Vehicle Identification Subsystem shall be divided by anamount 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 acceptan input voltage from the arenablock sensors.

None Added

15.3.13.1: The input voltageshall be determined by the differ-ence in voltage across the frontand back contact points.

None Added

15.3.14: The input voltage tothe Vehicle Identification Sub-system shall be divided by anamount unique to each vehicle.

7.1.2.2: The vehicle shall have apriority level unique amongst thesystem’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 relevantL1 requirement. This includes an explanation of the reason behind each change.

Project RIDES 76

L2 System Requirements Specification, 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 betaken. 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 VehiclePathfinding Subsystem.

14.2 Constraints

The following are constraints defined by external sources that limit the development of the ObstacleDetection Subsystem in accordance with the requirements listed in this document.


For the Obstacle Detection Subsystem to operate correctly, the vehicle microcontroller and the sensorinputs must work asynchronous with the other vehicle components. The vehicle must prioritize the obstaclesensor input above any other components, so that the detection of an obstacle is acknowledged and actedupon nearly instantly. When an obstacle is detected, speed instructions from the Operations Computer areignored.

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. Themain success scenario describes what happens within the system when nothing unexpected happens. Theextensions describe alternatives to the sequence of events listed in the main success scenario. Extensionslabeled with a * can occur at any point within the main success scenario.

14.3.1 Use Case: Obstacle Detected


1. Vehicle


The obstacle detection sensor outputs a signal to the vehicle microcontroller, which is then interpretedby 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 anobstacle in its path. The vehicle either slows to a complete stop, or reduces its speed, depending on thedistance 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.1The vehicle shall disregard speed signals received from the Operations Computer whilethe vehicle detects an obstruction.

15.3.15.2The vehicle shall resume following instructions from the Operations Computer whenthe vehicle does not detect the obstruction.

15.3.15.3The vehicle shall detect obstructions larger than 8 cm x 8 cm x 8 cm within 15 cm ofthe vehicle when the obstruction is within 10 degrees of the positive x -axis.

15.3.15.4The vehicle shall reduce speed to half of its speed when an obstruction is detectedbetween 15 cm and 4 cm of the vehicle within 10 degrees of the vehicle’s positivex -axis.

15.3.15.5The vehicle shall reduce speed to a halt when an obstruction is detected closer than7 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 detectobstructions.

No change.

15.3.15.1: The vehicle shalldisregard speed signals receivedfrom the Operations Computerwhile the vehicle detects an ob-struction.

7.1.1.8.1: The vehicle shalldisregard speed signals receivedfrom the Operations Computerwhile the vehicle detects an ob-struction.

No change.

15.3.15.2: The vehicle shall re-sume following instructions fromthe Operations Computer whenthe vehicle does not detect theobstruction.

7.1.1.8.2: The vehicle shall re-sume following instructions fromthe Operations Computer whenthe vehicle does not detect theobstruction.

No change.

15.3.15.3: The vehicle shall de-tect obstructions larger than 8cm x 8 cm x 8 cm within 15 cmof the vehicle when the obstruc-tion is within 10 degrees of thepositive x -axis.

7.1.1.8.3: The vehicle shall de-tect obstructions larger than 3cm x 3 cm x 3 cm within 10 cmof the vehicle when the obstruc-tion is within 10 degrees of thenegative x -axis.

Refined distances.

15.3.15.4: The vehicle shall re-duce speed to half of its speedwhen an obstruction is detectedbetween 15 cm and 4 cm of thevehicle within 10 degrees of thevehicle’s positive x -axis.

7.1.1.8.4: The vehicle shall re-duce speed to half of its speedwhen an obstruction is detectedbetween 10 cm and 3 cm of thevehicle within 10 degrees of thevehicle’s negative x -axis.

Refined distances.

15.3.15.5: The vehicle shall re-duce speed to a halt when an ob-struction is detected closer than7 cm within 10 degrees of the ve-hicle’s positive x -axis.

7.1.1.8.5: The vehicle shall re-duce speed to a halt when an ob-struction is detected closer than3 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 relevantL1 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 separatedinto 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 stationplatform, fails to reach the end of the currently occupied block section within 5 s of the expectedtime.

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 andthe 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 theoperator 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 targetlocations.

15.1.11 The Operations Computer shall set the vehicle’s target location to an effectively unoccupied blocksection after initialization.

15.1.12 The Operations Computer shall set the vehicle’s target location to an effectively unoccupied blocksection 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 separatesall 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 thevehicle enters a station platform.

15.1.20 The Operations Computer shall provide a suggested movement speed to the vehicle with regard to thenumber 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 vehiclewhen 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 vehiclehas 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 thevehicle 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 speedwhen the vehicle is the same number of block sections behind the PTC switch as a vehicle on anotherpathway.

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 targetlocation 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 isa 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 areunoccupied 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 eachmotor 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 Subsystemoutput.

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 emergencystop 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 thearena wire.

15.3.9.2 The Pathfinding Subsystem sensors shall read a signal with an amplitude that changes relativeto 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 lessthan 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 fieldsensors.

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 backcontact points of each vehicle.

15.3.14 The input voltage to the Vehicle Identification Subsystem shall be divided by an amount unique toeach 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 vehicledetects an obstruction.

Project RIDES 84


15.3.15.2 The vehicle shall resume following instructions from the Operations Computer when the vehicledoes 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 vehiclewhen 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 cmand 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 fromthe 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 sectionconflicts:

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 floor 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 SectionA section of path that can safely accommodate a singlevehicle. At no time should a block section contain morethan one vehicle.

Block

Block SystemA way of introducing high levels of safety into a ride bysectioning the ride into block sections.

Effectively OccupiedA state in which a block section exists where the blocksection is a vehicle′s target location.

Effectively UnoccupiedA state in which a block section exists where the blocksection is not the target location of any vehicle.

Emergency Stop

Used to stop the ride in such a manner that the ride willonly operate again with direct intervention from an opera-tor. Typically, this must be reset by power cycling the ride[4].

Maintenance BayA path or area of a ride on which vehicles can be storedand worked on.

Moving Block-LightSystem

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. Thefirst moving block-light system was introduced for the WaltDisney World Monorail System known as MAPO (MAryPOppins) [7].

PathThe block sections that are in front of a vehicle betweenthe vehicle and its target location.

PathwayA chain of block sections that lead from the STP switch tothe 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 betweenthe operator and the machine.

ObstructionAn object that unexpectedly enters a section of path aheadof the ride vehicle.

OccupiedA state in which a block section exists where a vehicle ison the block switch.

Operations Computer

The device that monitors the movement and location of allof the vehicles and the status of each station platform. Itmakes decisions regarding vehicle movement based on thisinformation.

Ride StopA function on a ride’s control system that causes all vehiclesto stop and remain stopped until further notice.

Station AreaAn area that houses one or more station platforms and apathway that vehicles can be directed onto to bypass stationplatforms.

Station PlatformA location where vehicles stop to simulate the loading andunloading of passengers. The vehicles stop there for alength of time that is based on estimated loading time.

SwitchA block that can direct a vehicle to one of multiple possibleblocks or can direct a vehicle from one of multiple blocksonto a single block.

Project RIDES 87

L2 System Requirements Specification, Rev. 1.3 16 Glossary

Target LocationThe furthest open block that a vehicle can route to that isnot about to be occupied, or will be occupied by anothervehicle before the original vehicle enters it.

Target Block

UnoccupiedA state in which a block section exists where no vehicle ison the block switch.

Vehicle ComputerThe device on-board each of the vehicles that is able to pro-cess commands from the Operations Computer and enactthose commands, controlling the vehicle′s movement.

Vehicle Mi-crocontroller

Project RIDES 88

L2 System Requirements Specification, Rev. 1.3 17 Acronyms

17 Acronyms

Name DefinitionERAU Embry-Riddle Aeronautical UniversityID IdentificationI/O Input/OutputMTP Maintenance-To-PathPTS Path-To-StationPWM Pulse-Width ModulationRF Radio FrequencyRIDES Ride Integrating Dynamic Electronic SystemSTP Station-To-Path

Project RIDES 89

L2 System Requirements Specification, 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 WirelessCommunications and Networking 2009, 2009:568369 doi:10.1155/2009/568369

[7] Railroad Accident Brief, National Transportation Safety Board, Washington DC, RAB-11-07, October31, 2011

Project RIDES 90

L2 System Requirements Specification, Rev. 1.3 A Appendix

A Appendix

A.1 Changelog

Section Description

IntroductionChanged the team roles to be more uniform and correctly defineour current roles at this stage of project development. Overviewchanged 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

RequirementsAdded and removed many different subsystems to better fit thesystem 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

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. 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: 1. Operations computer

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.

Main Success Scenario: 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.





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.

Frequency of Occurrence: 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


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 vehicles are stationary.

Main Success Scenario: 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>




2. See Use Case 4.







*d. The vehicle collides with an object or another vehicle.

1. See Use Case 4. <deleted some>

Frequency of Occurrence: 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


2. Operations computer

Description: The operator or operations computer triggers an emergency stop, and the vehicles halt and power

down.


2. The vehicles are in the ready state (see Use Case 1).



Project RIDES 105

11


Postconditions: 1. The vehicles are stationary.


Main Success Scenario: 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.



Frequency of Occurrence: 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: 1. The vehicles are in the ready state (see Use Case 1).

2. The operations computer is in the ready state (see Use Case 1).

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 vehicles are not ride stopped.


Main Success Scenario: 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.




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>

Frequency of Occurrence: 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.


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.


Main Success Scenario: 4. The operator physically removes the vehicles from the arena.

5. The operator begins Use Case 1.

Extensions: See Use Case 1.

Frequency of Occurrence: This use case will occur after every emergency stop, followed by ride initialization.


Project RIDES 107

13

6. Sequence Diagrams The following system sequence diagrams illustrate the sequence of events occurring in each use case

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