scc-b-conops mmtpa-cps final 20180810 › legacy › uploaded...2018/08/30 · the united states...

Smart Columbus

Concept of Operations for the Multimodal Trip Planning Application/Common Payment System for the Smart Columbus Demonstration Program

www.its.dot.gov/index.htm

Final Report – August 10, 2018

Source: City of Columbus – November 2015

Produced by City of Columbus, Ohio U.S. Department of Transportation Office of the Assistant Secretary for Research and Technology

Notice

This document is disseminated under the sponsorship of the Department of Transportation in the interest of information exchange. The United States Government assumes no liability for its contents or use thereof.

The U.S. Government is not endorsing any manufacturers, products, or services cited herein and any trade name that may appear in the work has been included only because it is essential to the contents of the work.

Acknowledgement of Support

This material is based upon work supported by the U.S. Department of Transportation under Agreement No. DTFH6116H00013.

Disclaimer

Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the Author(s) and do not necessarily reflect the view of the U.S. Department of Transportation.

Technical Report Documentation Page

1. Report No.

N/A

2. Government Accession No.

3. Recipient’s Catalog No.

4. Title and Subtitle

Concept of Operations for the Multimodal Trip Planning Application/Common Payment System (MMTPA/CPS) for the Smart Columbus Demonstration Program

5. Report Date

10-August-2018

6. Performing Organization Code

7. Author(s)

Andy Wolpert (City of Columbus), Alex Kavanagh (HNTB), Robert James (HNTB)

8. Performing Organization Report No.

9. Performing Organization Name and Address

City of Columbus |90 West Broad Street Columbus, OH 43215-9004

10. Work Unit No. (TRAIS)

11. Contract or Grant No.

DTFH6116G00013

12. Sponsoring Agency Name and Address

U.S. Department of Transportation (USDOT) Federal Highway Administration (FHWA) Office of Acquisition and Grants Management 1200 New Jersey Avenue, SE Mail Drop: E62-204 Washington, DC 20590

13. Type of Report and Period Covered

Concept of Operations

14. Sponsoring Agency Code

15. Supplementary Notes

16. Abstract

This Concept of Operations (ConOps) provides an approach that ensures that the correct system is built to address the needs of the City of Columbus. It addresses the opportunity to deploy a Multimodal Trip Planning Application (MMTPA) and Common Payment System (CPS) in an operational environment. It is intended for use by the City of Columbus as they begin to install and operate the MMTPA/CPS. This document goes so far as to describe needs of the users of the system, what the intended system will do, constraints on the system, and describe potential system operational characteristics, but it does not impose requirements on the system or recommend specific technology solutions for the system. Ultimately, this document provides a connection between program-level visions/goals and project-level concepts. Technical specifications and design details will be developed in subsequent documents.

17. Keywords

Smart Columbus, Multimodal Trip Planning Application, MMTPA, Common Payment System, CPS, Concept of Operations

18. Distribution Statement

19. Security Classif. (of this report)

Unclassified

20. Security Classif. (of this page)

Unclassified

21. No. of Pages

156

22. Price

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized

U.S. Department of Transportation Office of the Assistant Secretary for Research and Technology

Intelligent Transportation Systems Joint Program Office

Multimodal Trip Planning Application/Common Payment System Concept of Operations – Final Report | i

Table of Contents

Table of Contents .................................................................................................................................. i

Chapter 1. Introduction ....................................................................................................................... 1

Project Scope ........................................................................................................................................................... 2

Mobility as a Service .......................................................................................................................................... 3

Elements of the Operating System ................................................................................................................... 4

Geographic Scope ............................................................................................................................................. 5

Project Relation to the System of Systems ............................................................................................................. 6

High-Level Components ........................................................................................................................................... 7

Travelers ............................................................................................................................................................ 8

The Operating System ...................................................................................................................................... 9

Common Payment System Payment Broker ................................................................................................... 9

Common Payment System Back Office ........................................................................................................... 9

Data Consumers ................................................................................................................................................ 9

Mobility Providers .............................................................................................................................................. 9

Parking Providers ............................................................................................................................................ 13

Regional Systems ............................................................................................................................................ 13

Chapter 2. References ....................................................................................................................... 15

Stakeholder Engagement Summary...................................................................................................................... 18

Linden Community Plan Meetings .................................................................................................................. 18

Cluster Sampling Field Surveys ...................................................................................................................... 19

Linden Community Outreach .......................................................................................................................... 20

Linden Residential District ............................................................................................................................... 20

Chapter 3. Current System ............................................................................................................... 23

Disintegrated Apps and Services ........................................................................................................................... 23

Social Equity Issues ............................................................................................................................................... 24

Background and Objectives ................................................................................................................................... 25

Operational Policies and Constraints ..................................................................................................................... 26

Description of Current System ............................................................................................................................... 27

Central Ohio Transit Agency Fare System Redesign .................................................................................... 27

Table of Contents

U.S. Department of Transportation Office of the Assistant Secretary for Research and Technology Intelligent Transportation Systems Joint Program Office

ii | Multimodal Trip Planning Application/Common Payment System Concept of Operations – Final Report

Modes of Operation for the Current System .......................................................................................................... 30

User Classes of the Current System ..................................................................................................................... 31

Chapter 4. Justification and Nature of Changes ............................................................................ 33

Justification for Changes ........................................................................................................................................ 34

Description of Desired Changes ............................................................................................................................ 35

Priorities Among Changes ..................................................................................................................................... 52

Changes Considered but not Included .................................................................................................................. 54

Connection Protection ..................................................................................................................................... 54

Purchase First Mile/Last Mile Tickets at Central Ohio Transit Agency Ticket Vending Machines ............... 54

Chapter 5. Concept for the New System ......................................................................................... 55

Background, Objectives and Scope ....................................................................................................................... 55

Goal No.1: Enhanced Mobility......................................................................................................................... 55

Goal No. 2: Enhanced Access to Opportunities and Service ........................................................................ 56

Goal No. 3: Increased Customer Satisfaction ................................................................................................ 56

Operational Policies and Constraints ..................................................................................................................... 57

Description of Proposed System ............................................................................................................................ 59

Operating System (Central System) ...................................................................................................................... 61

Trip Optimization .............................................................................................................................................. 61

Mobility Providers ............................................................................................................................................ 62

Data Services................................................................................................................................................... 62

Trip and Payment Data ................................................................................................................................... 62

Payment Broker Service .................................................................................................................................. 63

Common Payment System Back-Office ................................................................................................................ 63

Common Payment System Payment Processor/Gateway ............................................................................ 63

Common Payment System Accounts ............................................................................................................. 64

Central Ohio Transit Agency Fare Management System ..................................................................................... 65

Mobility Provider Systems ...................................................................................................................................... 65

Fixed-Route Mobility Providers ....................................................................................................................... 66

On-Demand Mobility Providers ....................................................................................................................... 66

Shared Vehicle Providers ....................................................................................................................................... 67

Ride-Sharing Providers ................................................................................................................................... 67

Transaction Equipment .......................................................................................................................................... 67

Traveler Web Portal ......................................................................................................................................... 68

Central Ohio Transit Agency Ticket Vending Machine .................................................................................. 68

Central Ohio Transit Agency Farebox ............................................................................................................ 68

Smart Mobility Hubs ........................................................................................................................................ 68

Interactive Voice Response System ............................................................................................................... 68

Multimodal Trip Planning App ................................................................................................................................ 68

Interface with Operating System ..................................................................................................................... 69

Table of Contents



Multimodal Trip Planning Application/Common Payment System Concept of Operations – Final Report | iii

Interface with Transaction Equipment ............................................................................................................ 69

User Preferences ............................................................................................................................................. 69

Incentives/Rewards ......................................................................................................................................... 70

Modes of Operation for the Proposed System ...................................................................................................... 70

User Classes and Other Involved Personnel ........................................................................................................ 72

Support Environment .............................................................................................................................................. 76

Security and Privacy ............................................................................................................................................... 76

Payment Card Industry Compliance ............................................................................................................... 77

Personally Identifiable Information .................................................................................................................. 78

Operating System Security ............................................................................................................................. 78

Chapter 6. Operational Scenarios ................................................................................................... 81

Chapter 7. Summary of Impacts .................................................................................................... 123

Challenges ............................................................................................................................................................ 123

Operational Impacts ............................................................................................................................................. 123

Organizational Impacts ......................................................................................................................................... 123

Impacts During Development ............................................................................................................................... 124

Chapter 8. Analysis of Multimodal Trip Planning App ................................................................ 125

Summary of Improvements .................................................................................................................................. 125

Disadvantages and Limitations ............................................................................................................................ 125

Alternatives and Trade-Offs Considered ............................................................................................................. 125

Chapter 9. Notes .............................................................................................................................. 129

Appendix A. Stakeholder Engagement Summary ....................................................................... 131

Appendix B. Acronyms and Definitions ....................................................................................... 141

Appendix C. Glossary ..................................................................................................................... 145

List of Tables

Table 1: References .................................................................................................................................... 15

Table 2: Meetings ........................................................................................................................................ 16

Table 3: Operational Policies and Constraints of the Current System ........................................................ 26

Table 4: Modes of Operation for the Existing COTA System ...................................................................... 30

Table 5: Current System Users ................................................................................................................... 31

Table 6: Justification for Changes ............................................................................................................... 34

Table 7: Major Capability Changes in the Proposed System ...................................................................... 36

Table 8: User Needs .................................................................................................................................... 38

Table 9: Priorities Among Changes ............................................................................................................. 52

Table 10: Objectives of the Proposed System ............................................................................................ 57

Table of Contents


iv | Multimodal Trip Planning Application/Common Payment System Concept of Operations – Final Report

Table 11: Operational Policies and Constraints .......................................................................................... 58

Table 12: Common Payment System Accounts – Traveler ......................................................................... 64

Table 13: Common Payment System Accounts – Merchant ....................................................................... 65

Table 14: Selectable User Preferences by Mobility Providers .................................................................... 69

Table 15: Modes of Operation for the Proposed System ............................................................................ 71

Table 16: Proposed System Users .............................................................................................................. 74

Table 17: UC1-S1: Traveler Installs and Launches the MMTPA ................................................................. 82

Table 18: UC2-S1: Traveler Adds User Preferences to the MMTPA ........................................................... 84

Table 19: UC3-S1: Traveler Gathers Information for a Multimodal Trip ...................................................... 87

Table 20: UC4-S1: Traveler Executes a Multimodal Trip (Fixed-Route and Bike-Share) ........................... 89

Table 21: UC4-S2: Failure Condition – Bike Not Available at Docking Station ........................................... 93

Table 22: UC4-S3: Failure Condition – Loss of Communications ............................................................... 95

Table 23: UC5-S1: Traveler Without Smartphone Uses IVR System to Activate FMLM Trip ..................... 98

Table 24: UC6-S1: Traveler Creates a CPS Account ................................................................................ 100

Table 25: UC6-S2: Traveler Registers a New Payment Method and Enables Auto-Fill and Automated Alerts ............................................................................................. 103

Table 26: UC6-S3: Traveler Updates CPS Account to Qualify for Accessibility Services for ADA-Compliant Trip Segments ................................................................... 106

Table 27: UC6-S4: Traveler Recovers Lost CPS Password ..................................................................... 109

Table 28: UC6-S5: Traveler Closes CPS Account .................................................................................... 111

Table 29: UC6-S6: Traveler Pays for a Trip Using a CPS Guest Account ................................................ 112

Table 30: UC7-S1: Mobility Provider Establishes an Account in the Operating System ........................... 115

Table 31: UC8-S1: Mobility Provider Manages CPS Account ................................................................... 117

Table 32: UC9-S1: City of Columbus User Retrieves Data from Operating System ................................ 119

Table 33: UC9-S2: Third-Party User Retrieves Data from Operating System .......................................... 121

Table 34: Summary of Improvements ....................................................................................................... 125

Table 35: Alternatives and Trade-Offs Considered ................................................................................... 126

Table 36: What travel services are you interested in using? ..................................................................... 134

Table 37: How do you currently get information about these services if you use them today? ................ 135

Table 38: How would you like to get information? ..................................................................................... 135

Table 39: What information is most important? ......................................................................................... 136

Table 40: What are the obstacles to getting all the information in one place? .......................................... 137

Table 41: How do you currently pay for these services if you use them today? ....................................... 137

Table 42: How do you currently pay for these services if you use them today? ....................................... 138

Table 43: How do you want to pay for these services? ............................................................................. 138

Table 44: What are the obstacles? ............................................................................................................ 139

Table 45: Acronym List .............................................................................................................................. 141

Table 46: Glossary .................................................................................................................................... 145

Table of Contents



Multimodal Trip Planning Application/Common Payment System Concept of Operations – Final Report | v

List of Figures

Figure 1: Mobility as a Service Diagram ....................................................................................................... 3

Figure 2: Elements of the Smart Columbus Operating System .................................................................... 4

Figure 3: COTA Service Area ........................................................................................................................ 6

Figure 4: System of Systems Context Diagram ............................................................................................ 7

Figure 5: High-Level Context Diagram .......................................................................................................... 8

Figure 6: COTA Farebox Upgrade .............................................................................................................. 29

Figure 7: MMTPA/CPS Proposed System Context Diagram ...................................................................... 60

Figure 8: Traveler Installs and Launches the MMTPA ................................................................................ 82

Figure 9: Traveler Adds User Preferences to the MMTPA .......................................................................... 84

Figure 10: UC3-S1, UC3-S2, UC3-S3: Traveler Gathers Information for a Multimodal Trip ...................... 87

Figure 11: UC4-S1: Traveler Executes a Multimodal Trip (Fixed-Route and Bike-Share) .......................... 89

Figure 12: UC4-S2, UC4-S3: Failure Condition – Bike Not Available at Docking Station .......................... 93

Figure 13: UC5-S1: Traveler Without Smartphone Uses IVR System to Activate FMLM Trip .................... 98

Figure 14: UC6-S1, UC6-S2, UC6-S3, UC6-S4, UC6-S5, UC6-S6: Traveler Creates a CPS Account .... 100

Figure 15: UC7-S1: Mobility Provider Establishes an Account in the Operating System ......................... 115

Figure 16: UC8-S1: Mobility Provider Manages CPS Account ................................................................. 117

Figure 17: UC9-S1, UC9-S2: City of Columbus and Third-Party Users Retrieve Data from Operating System ...................................................................................................... 119



Multimodal Trip Planning Application/Common Payment System Concept of Operations – Final Report | 1

Chapter 1. Introduction

This Concept of Operations (ConOps) serves as the first in a series of engineering documents that describe the development of the Multimodal Trip Planning Application (MMTPA) and Common Payment System (CPS). The purpose of the ConOps is to clearly convey a high-level view of the system to be developed from the viewpoint of each stakeholder. This document frames the overall system and establishes the technical course for the project by serving as a bridge between early project motivations and the eventual technical requirements. By design, the ConOps is technology independent, focusing instead on the overall functionality of the proposed system. The ConOps is based upon extensive stakeholder engagement with both the users of the system as well as all the agencies that will play a role on its implementation. It has involved input from many transportation companies and groups that will be participants in the system as well. The ConOps also serves to communicate user needs for, and expectations of, the proposed system. The document provides stakeholders the opportunity to offer input regarding proposed system functionality. The document is intended to help form a consensus among all stakeholders and to create a single vision for the proposed system moving forward.

The document is structured in accordance with Institute of Electrical and Electronics Engineers (IEEE) Standard 1362-1998 and contains the following chapters:

Chapter 1. Introduction provides a document overview.

Chapter 2. References identifies all documents referenced and interviews conducted in developing this document.

Chapter 3. Current System describes the current system and those systems that support it. This section provides a description of the problem(s) to be addressed and is tailored to describe the motivations for the developing a new system.

Chapter 4. Justification and Nature of Changes describes the user needs that motivate development of the project. This section serves as a transition from Chapter 3, which describes the current and supporting systems, to Chapter 5, which describes the proposed system.

Chapter 5. Concept for the New System describes the proposed system resulting from implementing the features described in Chapter 4. It describes the proposed system at a high level, indicating the operational features that are to be provided, without specifying design details.

Chapter 6. Operational Scenarios describes the Use Cases and Operational Scenarios, which illustrate how the project will operate from various perspectives.

Chapter 7. Summary of Impacts describes the impacts the project will have on multiple stakeholders including system users, owners, and operators.

Chapter 8. Analysis of Multimodal Trip Planning App provides an analysis of the impacts presented in Chapter 7.

Chapter 9. Notes includes additional information to aid in understanding the overall system concept.



2 | Multimodal Trip Planning Application/Common Payment System Concept of Operations – Final Report

Project Scope

The U.S. Department of Transportation (USDOT) pledged $40 million to Columbus, Ohio, as the winner of the Smart City Challenge. With this funding, Columbus intends to define what it means to be a “Smart City” and serve as a model for other cities wishing to fully integrate innovative technologies, such as self-driving cars, connected vehicles, and smart sensors, into the transportation network. Columbus is acting as a laboratory for Intelligent Transportation Systems (ITS) and disseminating lessons learned and best practices to cities across the United States in an effort known as Smart Columbus. The goal of the Smart Columbus project is to connect people by creating opportunity for city residents to better access jobs and services while improving the overall safety and efficiency of the transportation network. The goal of the Smart Columbus project is both exciting and ambitious given the four-year implementation time frame which began in the summer of 2016 and will conclude in March of 2021.

The MMTPA/CPS is one of nine Smart Columbus projects. The MMTPA/CPS will be used throughout Columbus and outlying communities that are serviced by shared-use transportation services (Mobility Providers). The project will allow travelers to create multimodal trips and pay once using an account-based system, which is linked to different payment media and modes of transportation. Options for multimodal trips will include walking, fixed-route bus service, car-sharing, ride-sharing, bikesharing, paratransit, and on-demand service such as taxis, limousines, and Uber and Lyft services.

Columbus residents and visitors do not have access to a system that allows for the seamless planning of or paying for a trip involving multiple transportation options. Moreover, some Columbus residents are unbanked and therefore cannot access alternative modes of transportation including car and bike-sharing systems. The MMTPA will make multimodal options easily accessible to all by providing a robust set of transit and alternative transportation options including routes, schedules and dispatching possibilities. The application will allow travelers to request and view multiple trip itineraries and make reservations for shared-use transportation options such as transit, bike-sharing, transportation network companies (TNCs) and car-sharing. Using the MMTPA, users will be able to compare travel options across modes, plan and pay for their travel based upon current traffic conditions and availability of services.

It is the city’s goal that this application will allow residents to more easily access the transportation systems available in Columbus today and in the future, so they can maximize services to improve their lifestyle. This project is anticipated to provide an innovative solution to improve mobility and access to opportunity. The City of Columbus identified the following objectives to evaluate the measurable impact the MMTPA/CPS project is intended to have:

Facilitate improved access to multimodal trip planning information

Increase usage of the available transportation services

Improve ease of multimodal trip planning

Provide travelers with more convenient access to transportation service options

Increase access to jobs and services

Increase customer satisfaction





Mobility as a Service

Columbus wishes to become a facilitator for Mobility as a Service, or MaaS, by providing a platform that integrates end-to-end trip planning, booking, electronic ticketing, and payment services across all modes of transportation, public or private. The effective outcome will be to make its communities work more effectively and improve access to transportation options for communities in need to travel to jobs and job centers in the region.

Columbus defines MaaS as a shift away from personally-owned vehicles to a solution that combines both public and private transportation services. Integration with the Smart Columbus Operating System (Operating System) is central to Columbus’ vision for facilitating MaaS. The Operating System will serve as a unified gateway for the region, by combining the transportation services of Mobility Providers into a single platform accessible to Travelers using the MMTPA. The account-based CPS will provide Travelers with the ability to pay for all trips with a single account.

Figure 1: Mobility as a Service shows the Operating System at the heart of the Smart Columbus vision and provides the fabric of connectivity and data sharing between systems. The Operating System overlaps with Mobility Providers to provide customized multimodal travel options for Travelers using the MMTPA. Components of the MMTPA/CPS solution reside in the Operating System as shared services and will be accessible to other Smart Columbus projects for trip planning and trip payment.

Source: City of Columbus

Figure 1: Mobility as a Service Diagram




Elements of the Operating System

Figure 2: Elements of the Smart Columbus Operating System depicts high-level system elements of the Operating System. Shared Services and Analytics are key components of the MMTPA/CPS system as explained in Chapter 5. Concept for the New System.


Figure 2: Elements of the Smart Columbus Operating System

The Operating System is a platform for Smart Cities development. It consists of several core functions, which can be leveraged across the Smart Columbus program, as well as other functions that will specifically enhance and support “Smart Apps” such as the MMTPA/CPS system (Figure 4: System of Systems Context Diagram). The core functions in the Operating System are described below:

Data Environment: The orderly ingestion, aggregation and tagging of many forms of data from real-time, to slow-moving or manually-uploaded data.

Data Lake: A storage repository that holds a massive amount of raw data in a secure way and makes it available to all the other supported operations in the system.

Security: To ensure trust, it is imperative that the Operating System is exceptional at managing the users and systems that have access to it.

Scalable Capacity: The Operating System is “scalable” and “elastic” which means that it can grow and shrink to meet the demand of the system at any given time.

Shared Services Environment: Application components can be housed and made available to any number of applications connected to the Operating System.

Data Research Environment: In a data-rich environment, Columbus and its residents, businesses, nonprofits and visitors will be increasingly able to share, use and leverage previously





unavailable datasets to address complex problems and improve current operations and capabilities

Analytics: Analytics will also be used to predict future conditions and the potential benefits of implementing different operational strategies, control plans and response plans coordinated among agencies and Mobility Providers.

Geographic Scope

The geographic scope of the MMTPA/CPS is citywide and beyond, encompassing all the Central Ohio Transit Agency’s (COTA’s) service area (Figure 3: COTA Service Area) and extending into outlying communities that are further serviced by Mobility Providers. COTA’s service area includes all of Franklin County and parts of Delaware, Fairfield, Licking, and Union Counties. Outlying communities are characterized by lower-density commercial, retail, and housing development. The Columbus region as a whole is growing in both urban and suburban areas – growth which has contributed to increased congestion and need for better transportation alternatives to move people between urban and suburban areas and employment centers. The Mid-Ohio Regional Planning Commission (MORPC) has projected that by 2040 COTA’s service area will experience a 13 percent increase in population, 15 percent increase in employment, and 13 percent increase in highway traffic congestion.




Source: COTA

Figure 3: COTA Service Area

Project Relation to the System of Systems

The Smart Columbus program contains many interrelated systems that work together to provide a System of Systems (SoS). Information from these systems are shared in the Smart Columbus Operating System (Operating System). Both real-time and archived data is maintained in the Operating System for use by the other Smart Columbus projects and other future applications. The SoS work together to provide Smart Applications, Smart Vehicles, and Smart infrastructure to travelers in the Columbus area. The Operating System enables the SoS to share data with many external systems to provide the framework for the services provided. Figure 4: System of Systems Context Diagram shows the relationship of the SoS with the external travelers and systems.





The Smart Infrastructure element contains the roadside units (RSUs), hubs, and corresponding network that enable interactions between these items and the Operating System. Smart Vehicles include the on-board units (OBUs) that will be installed in vehicles and include various vehicle types. Smart Applications include the software-oriented solutions that will deliver other Smart Columbus project capabilities such as multimodal trip planning, common payment, prenatal trip assistance, etc. The overlap between Smart Applications and the Operating System indicates a shared services envionrment. The Operating System is the repository for all performance data from the Smart Infrastructure and Smart Vehicles, as well as the shared services platform that allow the Smart Applications to be directly integrated.


Figure 4: System of Systems Context Diagram

Mobility Providers provide travel data to the Operating System which is then made available to the MMTPA/CPS. Individual trip requests by multimodal travelers using the MMTPA are optimized in the Operating System, using all available transportation data. Travelers pay for trips using their CPS account, and Mobility Providers are paid for trips from the CPS. Using this model, Travelers will be able to maintain a single account across all Smart Columbus applications and access shared features such as trip planning and common payment across various channels.

High-Level Components

Figure 5: High-Level Context Diagram shows the relationship of the MMTPA/CPS to the Operating System and to existing systems. Travelers interact with the MMTPA to plan and execute trips, and the MMTPA interacts with the Operating System to optimize trip information from Mobility Providers and to facilitate payment requests between the MMTPA and CPS. Travelers pay for service using their CPS




accounts, which are integrated with COTA’s Fare System and validation equipment through back-office functions. MMTPA trip planning functionality is also available to users at Smart Mobility Hubs in Columbus. Over time, Regional Systems will be able to connect to the Operating System to utilize trip optimization in other apps. City of Columbus and Third-Party Users are able to connect to the Operating System to receive analytics and performance measures on the system. Each of these components is described in more detail in the remainder of this section.


Figure 5: High-Level Context Diagram

Travelers

Travelers will interact with the MMTPA/CPS system to plan, pay for, and execute single and multimodal trips in the defined service area (Geographic Scope).

Travelers will engage in any of the modes of transportation described in Mobility Providers. Travelers will pay for transportation services by opening a CPS account, which can be funded using a variety of different payment media.

Travelers will access the MMTPA/CPS system primarily via smartphones. Travelers without access to smartphones or personal computers will be able to access the MMTPA/CPS system using an interactive voice response (IVR) system at Smart Mobility Hubs to purchase tickets.

Travelers will be able to purchase COTA smart cards at ticket vending machines (TVMs) throughout the City or reload their CPS accounts at TVMs using cash or credit.

Travelers consist of all residents of Columbus and visitors to the City and are both banked and unbanked (Table 46: Glossary) with respect to using the system to pay for transportation services.





The Operating System

The Operating System will communicate with Mobility Providers to create personalized trip itineraries for Travelers through a process called “trip optimization.” Trip optimization is based on input from Travelers using the MMTPA, such as origin and destination address, as well as individual preferences. The MMTPA will display the results of trip optimization and Travelers will be able to select from a list of possible routes and modes to determine the best choice.

Trip and payment data generated by the MMTPA/CPS will reside in a “big data” environment within the Operating System that is comprised of data storage and data retrieval systems. Consumers of this data will connect to the Operating System to access the data. Data will be anonymized to protect personal information from being shared with consumers.

Common Payment System Payment Broker

The CPS Payment Broker will communicate payment requests between the MMTPA and COTA’s Fare System.

Common Payment System Back Office

The CPS Back office will be capable of handling one-to-one and one-to-many payments to Mobility Providers. For example, a Traveler using the MMTPA/CPS system to pay for a multimodal trip will pay once for the total trip (all trip segments) and have the funds split for each Mobility Provider for each segment of the total trip.

Data Consumers

The City of Columbus will have access to reports and performance measurement data via connection to the Operating System to make informed decisions regarding future improvements to the MMTPA/CPS and to support broader transportation policy decisions. The City is comprised of governmental staff within the following departments as well as others: Department of Technology (DoT) and Department of Public Service employees.

Third-party users are members of the public, including researchers, evaluators, and entrepreneurs, who will have limited access to data that is generated by the system for research, evaluation and development purposes. Third-party users will pull data from the Operating System (no bidirectional connection).

Mobility Providers

Mobility Providers are shared-use transportation services in which vehicles are accessed by multiple users for a variety of trip purposes1. For the purposes of the ConOps, Mobility Providers include public transit, car-sharing, bike-sharing, TNCs (or ridesourcing), taxis/ limos, car/vanpooling, and paratransit. The following are examples of Mobility Providers and their relationships to the proposed system.

1 Transit Cooperative Research Program (TCRP): Shared Mobility and the Transformation of Public Service.




Columbus is actively seeking Service Agreements with one or more Mobility Providers from each of the categories provided below.

Central Ohio Transit Authority

COTA is the regional public transit provider for greater Columbus and central Ohio, offering fixed-route bus service for the general public. Fixed-route describes public transportation service on which a vehicle is operated along a prescribed route according to a fixed schedule. COTA serves 1.2 million residents and provides more than 19 million passenger trips annually. COTA is currently undergoing a redesign of its fare collection system and has replaced all the current fareboxes on their fixed-route fleet of approximately 350 coaches with a new central fare management system (Central Ohio Transit Agency Fare System Redesign).

Relationship to Proposed System

The CPS back-office and COTA back-office will share a common ledger of account information. COTA transportation services will include fixed-route bus service, CBUS (the City’s free Downtown Circulator bus service) and AirConnect (a direct bus service connecting Downtown and Port Columbus International Airport) locations and schedules. COTA will provide real-time vehicle location data from its bus Automated Vehicle Location (AVL) system to the Operating System for trip optimization purposes for MMTPA users. COTA farebox equipment will be used to validate electronic transit tickets held by users of the MMTPA.

Transportation Network Companies

TNCs are ridesourcing companies that utilize smartphone app-based services to connect drivers with riders in exchange for payment. TNCs differ from taxi and limo services in that drivers use their own vehicles (non-commercial) and scheduling and payment are all app-based (payment is completely cashless). TNCs are less regulated than taxis or similar vehicles for hire, and definition of what constitutes a TNC may differ depending on geographic location. According to the 131st General Assembly of the State of Ohio, a TNC is defined as “a corporation, partnership, association, limited liability company, proprietorship, or any other entity operating in this state that uses a digital network to connect transportation network company riders to transportation network company drivers who provide transportation network company services.” Services provided by a TNC are distinguished as “the provision of transportation beginning when a transportation network company driver accepts a ride requested by a rider through a digital network controlled by a transportation network company, continuing while the driver transports the requesting rider, and ending when the last requesting rider departs from the personal vehicle.


It is intended that TNCs will provide vehicle information, location, availability, and costs to the Operating System for trip optimization of on-demand and scheduled trips. TNCs will have accounts in the CPS and will be reimbursed from Traveler’s CPS accounts. Progress has been made toward achieving acceptance and buy-in of the proposed system, but formal agreements have yet to be established.

Car-Sharing Providers

Car-sharing providers usually are private companies that provide access to an automobile for short-term use, typically on an hourly basis. Cars are distributed across a network of locations within a metropolitan





area. Members of a car-sharing service can access the vehicles at any time with a reservation and are charged by time or by mile. Car-sharing is suited to individuals who are infrequent car users and benefit from access to a car when needed and without the overhead of car ownership.

Zipcar has recently announced a partnership with Columbus to provide on-demand access to area residents, businesses, visitors and students. A small fleet of vehicles is available for reservation from on-street parking spots Downtown, as well as Short North, German Village and Weinland Park. The MMTPA will aggregate services from Zipcar to provide Travelers with shared-vehicle options in addition to other modes.


It is intended that car-sharing providers will provide vehicle information, location, availability, and costs to the Operating System for trip optimization of car-sharing options. Car-sharing providers will have accounts in the CPS and be reimbursed from Travelers’ CPS accounts. The City is currently having discussions with Zipcar to achieve acceptance and buy-in of the proposed system. Progress had been made toward achieving acceptance and buy-in of the proposed system with Car2go, but the company is no longer in operation in Columbus.

Bike-Sharing Providers

Bike-sharing providers allow individuals to access a network of shared bicycles for short-term use. Bike-sharing docking stations use technology to balance demand for bicycles and allow users to pay electronically. Many of these networks are publicly owned and contractor operated, whereas some are run by non-profit organizations. In downtown Columbus, CoGo provides a bicycle sharing network operated by Motivate, which includes over 365 bicycles strategically located at 46 stations. The MMTPA will aggregate services from CoGo to provide travelers with bike-sharing options in addition to other modes.


It is intended that bike-sharing providers will provide bicycle availability, location, and costs to the Operating System for trip optimization services. Bike-sharing providers will have accounts in the CPS and be reimbursed from Traveler’s CPS accounts. Progress has been made toward achieving acceptance and buy-in of the proposed system, but formal agreements have yet to be established.

Taxi/Limo

Taxi and limo services employ regulated vehicles that pick-up passengers via street hailing or through a reservation service such as an internet website. The fare for these vehicles, such as taxis and limos, is typically meter-based and is determined at the end of the ride, as opposed to ridesourcing services where price is predetermined and agreed to in advance. The MMTPA will aggregate services for taxis and limos to provide Travelers with for-hire options in addition to other modes.


It is intended that taxis/limos will provide vehicle information, location, availability, and cost estimates to the Operating System for trip optimization of on-demand and scheduled trips. Taxis/limos will have accounts in the CPS and be reimbursed from Traveler’s CPS accounts. Progress has been made toward achieving acceptance and buy-in of the proposed system, but formal agreements have yet to be established.




Car/Vanpool Providers

Car/vanpooling, also referred to as ride-sharing, involves adding passengers to a private trip in which driver and passengers share a destination. This arrangement is desirable in that it reduces each person's travel costs such as fuel costs, tolls, vehicle wear, and stress of having to drive. Car/vanpool commuting tends to be more popular in areas with higher residential densities and nearby jobs.


It is intended that car/vanpooling providers will provide commute and travel information to the Operating System for trip optimization so that MMTPA users may view and join trips.

Paratransit Services

Paratransit provides door-to-door service for individuals with disabilities who are unable to use fixed-route transportation systems. For eligible paratransit riders in Central Ohio, COTA offers three types of mobility services offered: Mainstream (compliance with the Americans with Disabilities Act, or ADA), Non-ADA Service and Will Call. Eligibility for paratransit is determined in compliance with the ADA prohibiting discrimination against persons with disabilities in the areas of employment, public accommodations and public services such as transportation.

The ADA considers fixed-route bus service to be “the primary mode of public transportation for everyone, including people with disabilities.” For this reason, all cities with fixed-route bus service must make the service accessible to individuals with disabilities and provide a comparable origin-to-destination or paratransit service for those who are unable to use the fixed-route bus service due to a disability (refer to https://www.cota.com/mobility-services/).

Mainstream Service

Traveling within ¾ mile of fixed-route and during fixed-route service hours

A shared-ride service scheduled in advance

Schedule up to seven days prior and at least one day in advance

Americans with Disabilities Act-Noncompliant Service

Beyond ¾ mile of fixed-route but within COTA’s service area or outside of fixed-route service hours

A shared-ride service scheduled in advance

Scheduled in advance, at least 24 hours in advance of trip request time

Will Call

Transportation service for riders who receive ongoing, long-term medical treatments such as dialysis, radiation or chemotherapy

Same-day service, at least one hour before every pickup






COTA will provide travel information to the Operating System for trip optimization so that qualifying Travelers with disabilities may schedule on-demand, same-day paratransit trips through integration with ridesourcing services.

Connected Electric Autonomous Vehicles

The Smart Columbus CEAV demonstration project proposes the deployment of autonomous shuttles within Columbus. The project objective is to learn how autonomous shuttles can be used to provide convenient, reliable First Mile, Last Mile (FMLM) transportation to individuals. It is believed that deployment of the CEAVs will increase COTA ridership and the number of residents able to access jobs and services through convenient, reliable first and last mile trips in the deployment area. The Smart Columbus program is currently investigating various use cases across the city in which to test, deploy, and evaluate use of the autonomous shuttles.


CEAV will provide schedule, location, and availability to the Operating System for trip optimization for FMLM connections. CEAV connections will be free of charge.

Parking Providers

Parking Providers are parking garages or surface lots in the Downtown District and Short North. Also included are third-party Online Parking Management Services Businesses that provide online parking management services to the public via a website or app. Columbus does not currently have a unified parking availability and reservation system. Under the current system, Columbus parking is managed by a conglomeration of public and private entities. Online sites provide private parking and payment options; and each site only presents a partial offering of the City’s available parking. Travelers must search multiple sites to assess the full range of parking options available, which can lead to confusion. During events, workday commutes, and on weekends, when parking is in the highest demand, drivers experience longer drive times and increased traffic congestion as they attempt to find available parking. These conditions lead to longer travel times due to the search for parking, an increase in fuel consumption, and negative impacts on air quality. The Smart Columbus program is addressing these challenges through implementation of an Event Parking Management (EPM) system. Further information on Parking Providers is available in the EPM ConOps.


It is intended that Parking Providers will allow access to CPS accounts to pay for parking options, but there will be no planned integration at this time. Refer to the Event Parking Management (EPM) ConOps document for more information.

Regional Systems

The Ohio Department of Transportation

ODOT is the administrative department of the Ohio state government responsible for developing and maintaining all state and federal roadways in Ohio with exception of the Ohio Turnpike. ODOT is




headquartered in Columbus. To facilitate regional development initiatives ODOT has divided the state of Ohio into 12 districts with each district responsible for the planning, design, construction, and maintenance of the state and federal highways in their region.

ODOT has created goals around mobility and human services transportation for the regions facilitated through ODOT’s Ohio Mobility Management Program. The program seeks to promote cost-effective use of available funding and to take advantage of regional deployment of enhanced technologies for all of Ohio’s human services programs that utilize agency sponsored and public transportation resources. The MMTPA/CPS aims to meet these goals by reducing roadway congestion through multimodal options and improving options for non-auto (and non-single-occupant auto) mode services.


It is envisioned that ODOT will utilize the Operating System as a central resource for trip optimization and shared mobility services, and the CPS for centralized payments in exchange for transportation-related services.

Dayton Regional Transit Authority

Dayton RTA has recently released a Request for Information (RFI) for their novel concept of combining Paratransit as part of their overall Mobility as a Service (MaaS) architecture for Non-Emergency Medical Transport (NEMT), RTA Fixed-Route Transit, transit operators in other counties, taxis, bike-share and car-share, parking, TNCs and other services. They envision one seamless cashless system with RTA as “mobility managers” for the region. This is one of the first agencies to take on Federal Transit Administration (FTA) Associate Administrator, Vincent Valdes’ vision of transit agencies and the “multimodal mobility managers for their region.” Dayton’s initiative also aligns with ODOT’s vision for mobility regions for human services transportation.


It is envisioned that regional systems, such as the Dayton RTA, may utilize the Operating System as a central resource for trip optimization and shared mobility services, and the CPS for centralized payments in exchange for transportation-related services.




Chapter 2. References

Table 1: References contains document number, title, revision and publication date of all documents referenced in this document.

Table 1: References

Document Number Title Revision Publication Date

IEEE 1362-1998 Electrical and Electronics Engineers (IEEE) IEEE Guide for Information Technology System Definition Concept of Operations (ConOps) Document

1998 03/19/1998

USDOT Solicitation No.: DTFH6116RA00002

City of Columbus Smart City Application: Beyond Traffic: The Smart City Challenge Phase 2.

"USDOT Application Volume I”

https://www.columbus.gov/smartcolumbus/application/

1 07/29/2016

N/A Smart Columbus Systems Engineering Management Plan (SEMP) for Smart Columbus Demonstration Program

V0.1 2/2/2017

N/A COTA Short-Range Transit Plan 2017-2021

https://www.cota.com/wp-content/uploads/2016/04/SRTP.pdf

Final Draft

April 2017

N/A COTA 2016-2040 Long-Range Transit Plan

https://www.cota.com/wp-content/uploads/2016/04/LRTP.pdf

Final Draft

April 2016

N/A 131st General Assembly of the State of Ohio, Substitute House Bill Number 237

http://www.legislature.ohio.gov/legislation/legislation-status?id=GA131-HB-237

N/A 03/23/2016

N/A Shared Use Mobility Center’s (SUMC) Share-Use Mobility Guide http://www.sharedusemobilitycenter.org/wp-content/uploads/2016/10/Reference-Guide-Editsweb-version-10.24.2016.pdf

N/A 2015




Document Number Title Revision Publication Date

ISBN 978-0-309-44582-5

TCRP RESEARCH REPORT 188: Shared Mobility and the Transformation of Public Transit

Final Draft

2016

N/A Ford Greenfield Labs: Columbus Mobility Design Research Report

Final Draft

03/19/2018

N/A Justification for ODOT HSTC Regions Final Report

January 2018

N/A Federal Transit Administration Shared Mobility Definitions

https://www.transit.dot.gov/regulations-and-guidance/shared-mobility-definitions

N/A 02/13/2017


Table 2: Meetings contains meetings which were relevant to development of the MMTPA/CPS ConOps and are referenced directly or indirectly in the document.

Table 2: Meetings

Meeting Title Date

Smart Columbus Technical Discussion with SPX/Genfare at APTA Conference 05/07/2018

Via MMTPA/CPS Information Meeting 04/24/2018

Ford/TransLoc/Chariot & COTA/OSU Smart Columbus Meeting about Microtransit and Multimodal Journey Planning

04/23/2018

SPX/Genfare and Smart Columbus Coordination Meeting 04/20/2018

Mid-Ohio Regional Planning Commission Coordination Meeting 04/11/2018

SPX/Genfare/Smart Columbus Working Session 04/06/2018

Lyft Coordination Meeting 04/05/2018

Yellow Cab and Mobile Knowledge Integration Meeting 04/05/2018

Technolution Information Meeting 03/29/2018

Transloc and MMPTA/CPS Meeting 03/23/2018

Google and MMPTA/CPS Meeting 03/23/2018

COTA MMTPA/CPS Integration Meeting 03/21/2018

Ford/Greenfield Labs Report 03/19/2018

Yellow Cab and MMTPA/CPS Coordination Meeting 03/06/2018





Meeting Title Date

Demandtrans and MMTPA/CPS Meeting 03/06/2018

Cogo and MMTPA/CPS Integration Meeting 03/05/2018

Uber and MMTPA/CPS Coordination Meeting 03/02/2018

Lyft and MMTPA/CPS Coordination Meeting 03/02/2018

Ridewithshare and MMPTA/CPS Meeting 02/26/2018

CoGo and Department of Recreation and Parks Coordination Meeting 02/15/2018

Columbus and Siemens SiMobility Connect Meeting 07/13/2017

Smart Columbus and Lyft Involvement Meeting 07/12/2017

CoGo and Smart Columbus Projects Coordination Meeting 07/10/2017

Yellow Cab and Smart Columbus Projects Meeting 07/06/2017

Moovel RiderApp Demo Meeting 06/28/2017

Linden Focus Groups for Mothers and Older People 06/21/2017

USDOT Performance Measures Review Meeting 06/21/2017

Moovel and Smart Columbus Projects Meeting 06/06/2017

Car2go and Smart Columbus Meeting 06/02/2017

Smart City - MMTPA, IDE, and GIS Meeting 06/01/2017

Weekly Performance Measures Working Group Meeting 05/02/2017 to 11/01/2017

Siemens SiMobility Connect for Smart Columbus Meeting 05/02/2017

COTA SPX/Genfare Discussion 04/25/2017

COTA and Smart Columbus Projects Meeting 03/09/2017

COTA Mobility Advisory Board Meeting 03/08/2017

Connected Travelers Weekly Coordination Meeting (Recurring Meeting with Project Team)

02/24/2017 to present

Smart Columbus IDE Roles Meeting 02/22/2017

Interested Vendors Review Meeting 02/21/2017

Residential Projects Decision Matrix Review Meeting 02/21/2017




Meeting Title Date

Smart Columbus Connects Linden, A Community Planning Event 02/10/2017 to 02/11/2017

Smart Columbus Connected Travelers Working Group Meeting 01/26/2017


Stakeholder Engagement Summary

The following is a summary of end-user and stakeholder engagement activities to assess community interest in utilizing a mobile app for multimodal trip planning and payment. Additional stakeholder engagement summaries, as well as survey questions and answers, are provided in the Appendix of the ConOps.

Linden Community Plan Meetings – August 2017 to March, 2018

Cluster Sampling Field Surveys – March 5-23, 2018

Linden Moms2B Focus Group – June 21, 2017

Linden Older Adults Focus Group – June 21, 2017

Online Survey – April 2017

Smart Columbus Connects Linden – February 10-11, 2017

Linden Community Plan Meetings

From August of 2017 through April of 2018, the City of Columbus and the Linden community have been working together to develop a master plan to shape Linden’s future. Linden formed working groups for five focus areas:

Education and workforce

Health and safety

Housing

Retail and small business

Transportation

The Smart Columbus team participated in monthly Transportation Working Group meetings to better understand the needs of the community and how Smart Columbus could help address those needs. On Thursday, December 7, 2017, and Saturday, December 9, 2017, the Linden community members came together for an open house at Linden McKinley High School to discuss the most important priorities from the five topic areas. Attendees considered the past discussions and provided their own input to create new priorities.





From the Transportation Working Group meetings and Open House events, Smart Columbus staff gained input and user needs from the Linden community on Smart Mobility Hubs and the MMTPA/CPS. After each project was described, the attendee was asked to complete questionnaires to identify gaps and/or risks that we may not yet have considered.

The feedback received from over 30 residents and is summarized below.

1. MMTPA/CPS

a. Every participant had a cell phone. Over 93% of participants have a smartphone

b. Over 85% of participants have a data plan

c. Almost 80% of participants pay for travel using credit or debit cards

d. Participants were also asked to provide feedback regarding what notifications/alerts should be received from the MMTPA/CPS. The majority of participants need:

i. Texts to alert me when I should depart my current location in order to get where I want to go

ii. Texts to alert me when a ride is on its way

iii. Texts to confirm payment

e. In addition, participants were asked to provide feedback on what preferences/attributes should be included in the MMTPA/CPS and if there were any preferences that have been missed. Items needed by the participants included:

i. Plan and select multiple types of travel

ii. Save favorite and/or preferred types of travel

iii. Determine how much walking is involved

iv. Save my payment information in the app for future use

v. Find family-friendly routes (includes pedestrian or bike facilities)

vi. Find the least costly way to get somewhere

vii. Find the quickest way to get somewhere

viii. Find the route that is most friendly to the environment

ix. Find ADA-accessible routes

f. General feedback expressed great excitement and the need for the project to happen quickly. One resident stated that he does not own a car and this application would help him make his travel decisions. Several residents stated that the ability to pay for all modes of transportation on one application would make life much easier.

Cluster Sampling Field Surveys

The Smart Columbus team created and administered surveys to examine how community members see themselves using smart technology to help them live their best lives. From March 5 through March 23, 2018, two community liaisons collected a total of 171 surveys at three survey locations – Linden, Easton




and Columbus State Community College (CSCC). The results from these surveys will inform the design of the Smart Mobility Hubs and MMTPA/CPS projects.

Surveys were administered at three Columbus regions using a cluster sampling methodology: Linden, Easton, and CSCC. The community liaisons visited about four physical locations within each region in an effort to get a good sampling of residents and visitors to those areas. Surveys were administered on site and in person via paper surveys. The survey results were then entered into a database for analysis.

Key takeaways from field surveys issued to stakeholders in the Columbus area in 2018 are included in Appendix B and summarized below. There were about 100 respondents to the surveys.

Over 90 percent of respondents stated that they had a cell phone. Of those, over 90 percent said their cell phone was a smartphone. The majority of people with smartphones – 87 percent – have a data plan.

Text messages are the most popular choice for receiving notifications from an app.

The most popular three features that respondents would like to see in an app (in order of preference) are: 1) Plan/select multiple types of travel; 2) Find the quickest way to get somewhere; 3) Find the least costly way to get somewhere.

When making plans for getting around, 40 percent of respondents said they would be most likely to use cash; 35 percent of respondents said they would be likely to use a debit card; and 25 percent said they would be most likely to use a credit card. Respondents were asked to pick one preference.

Linden Community Outreach

More than 170 Linden community residents (Linden Residential District) shared their views and ideas regarding what will make Linden a “smart” community as part of the Smart Columbus initiative. The two-day community dialogue, branded the “Smart Columbus Connects Linden” community planning event, was held February 10 and 11, 2017, at St. Stephen’s Community House, 1500 E. 17th Ave. in Columbus. The desired outcome of these meetings was to solicit input on the deficiencies or limitations of the current system, and to inform the ConOps development for Smart Columbus projects that directly affect Linden. Information gathered during the two-day Connect Linden discussions, as well as discussions with Linden leaders, community surveys, and other feedback, is included in Appendix A. Stakeholder Engagement Summary.

Key takeaways from the sessions included: most of the attendees said that they would favor a smartphone app to make travel arrangements and pay for them, seeing it as a convenient, no-cash-needed option; also, Linden residents have privacy concerns with personal information provided at kiosks.

Linden Residential District

Linden is a high-opportunity Columbus neighborhood in need of economic improvement. Linden was chosen as the first neighborhood district for its numerous socio-economic challenges, including low household income, lack of major employers and high infant mortality rates. These problems are compounded by the lack of access to transportation options. Despite proximity to the central core of the





city, basic services such as healthcare, grocery stores and banking are scarce within its boundaries. Many residents are transit-reliant; however, planning and completing a trip to access employment and services can be challenging, particularly for parents with young children, seniors and travelers with disabilities. There are also many FMLM challenges in the district.

The Linden residential area is the primary focus of the MMTPA/CPS to solve how to allow residents to get FMLM access to COTA’s service. Linden has been identified as an underserved community and access to jobs is the motivator to provide MMTPA service to this community. The secondary focus area of the MMTPA is the outlying communities which are not directly serviced by COTA.




Chapter 3. Current System

The current system is comprised of mobility services that are not designed to work together in a comprehensive way that is convenient for all travelers. Travelers must create multiple payment accounts across different modes of transportation and rely on disintegrated ways of planning and booking a trip. There is no single platform that links payments and accounts and allows travelers to seamlessly book and pay for any mode of transportation as part of a single trip regardless of the mobility provider.

There are challenges to facilitating MaaS in the current system that must be overcome (Mobility as a Service), such as improving service integration through a common interface, encouraging open and secure data-sharing with Mobility Providers, solving issues related to customer “ownership” and trip data, and determining ways to incentivize Mobility Providers to work together to support a common mobility platform.

Disintegrated Apps and Services

Mobility Providers in Columbus, as in the rest of the country, offer their own single-purpose mobile apps to promote their own services, with the common objective of offering superior transportation and parking services to customers. Many of these apps include interactive reservations, ability to track vehicle arrival and progress, make schedule adjustment and cancelations, in addition to dynamic dispatch and routing of vehicles to customers. Integrated payment systems allow travelers to register various payment media to pay for services using their smartphones. While these systems provide great service and flexibility to travelers of a single mode, there is lack of integration with other transportation services. Customers are required to download and install multiple apps, and register and maintain multiple payment methods, to complete trips involving more than one segment, or to compare prices, location, and availability between modes and services.

Third-party mobile apps serve as “data integrators” for the traveling public by combining schedule information and service availability from different transportation companies (including COTA, TNCs, bike-shares, and car-shares) using Software Development Kits (SDKs) and Application Programming Interfaces (APIs) to link with other apps. These apps rely on links to other apps to complete booking and payment for requested services. As a MaaS solution (Mobility as a Service), these applications fall short by providing only limited access to different modes and failing to include comprehensive coverage or a single payment method for all legs of a multimodal trip, requiring that users move from one app to the next to book and pay for services.

Transit App is a notable, free integrated mobile app used in Columbus that is available on both Apple and Android devices. Transit App works by aggregating fixed-route schedule information and real-time bus tracking information provided by COTA, in addition to providing real-time availability of ridesourcing (Uber), and bike-sharing (CoGo). Users can enter their location or use a device’s GPS to access a list of nearby bus connections based on their location on a map or tap on a bike-sharing icon on a map to open a linked account to book or reserve a connection. Transit App also provides access to COTA bus routes, CBUS (the City’s free Downtown Circulator bus service) and AirConnect (a direct bus service connecting




Downtown and Port Columbus International Airport) locations and schedules. An additional feature of Transit App includes the ability to provide a countdown of when each bus will arrive at the nearest stop. Users can be alerted at the time they need to leave to catch the bus, and when to alight if the user has selected a stop.

While Transit App provides many of the features desirable in a trip planning app, it does not provide a multimodal trip plan (it provides only one mode at a time) or a comprehensive platform to plan, book, and pay for multimodal trips from a single account. Furthermore, it does not provide a mechanism for the City to capture the trip and payment data which is central to this ConOps.

MORPC’s Gohio Commute program was created in 2017 with RideAmigos. It is a website that seeks to improve the way people commute between home and work by connecting users via transit, carpool, vanpool, and bike/walking services. The program helps employers reduce single occupancy vehicle (SOV) usage at their workplaces. Employers can manage their own private sub-network for employees. The program consists of online tools and resources that can help employees try new modes of transportation. Individuals can explore their travel options within a multimodal trip planner, find carpool partners, learn about transit, find bike-friendly routes, and request a free Emergency Ride Home. The website also encourages employers and other users to log their commutes and participate in challenge goals and gamification. Incentives include the Central Ohio Commuter Challenge where participants can win prizes by replacing driving alone trips with alternative modes of transportation. Employers can set up their own independent challenges or incentives for work place benefits. Gohio Commute also seeks to emphasize the positive health and environmental impacts of non-SOV travel, such as calculating the amount of CO2 emitted and calories burned from each mode of travel.

COTA currently provides a trip planner application on its website allowing customers to create a trip itinerary, but this service is limited to the fixed-route bus system and does not incorporate additional transportation modes or comprehensive regional service.

Social Equity Issues

As the paratransit provider for Central Ohio, COTA is responsible for social equity issues (like accessible vehicles) that other private companies, such as TNCs, do not have to address. The Americans with Disabilities Act (ADA) requires public agencies provide paratransit service within ¾ of a mile from any fixed-route service. Within the current system, however, paratransit service may not be convenient if it requires at least 24 hours advance trip reservations and provides a large (about 30 minutes) arrival window. This situation results in high cancelation rates and opportunities to enhance service.

Only about 20 percent of paratransit users require accessible vehicles. This means that the other ambulatory 80 percent of the riders could be accommodated by lower cost TNCs. COTA’s paratransit contracted trips cost on average $36, whereas TNC costs for the same trip can be under $20.

Many agencies have begun to use on-demand ridesourcing options for paratransit trips for their ambulatory customers instead of the higher cost alternative. The Massachusetts Bay Transportation Authority (MBTA) in Boston, for example, was one of the first to explore this operation with their on-demand pilot for their RIDE paratransit customers, allowing customers to book accessible trips via smartphones. (https://www.mbta.com/accessibility/the-ride/on-demand-pilot). A result of this program has been to reduce the average per trip cost from $46 to $13; however, it has become very popular and





usage of the service has increased significantly. The MBTA has estimated a net savings of about 6 percent. By capping the per-trip trip subsidy, they have been able to produce a net savings. Other strategies can be explored like limiting the number of trips per day.

TNCs have lowered the trip costs and increased ease of use of FMLM transportation over traditional taxi services. However, end-to-end use of ridesourcing options are still too expensive for most travelers to use on a regular basis. Transit agencies are subsidized at least 50 percent of their operating cost because society recognized the benefit of moving single passenger travelers to shared services. UberPool and LyftLine shared ride services have helped reduce costs. The major players like Google Maps are still trying to show TNCs as alternatives to transit for trips instead of a compliment to transit. Many cities are deploying multimodal trip planners that combine transit with TNCs. While multimodal apps that provide door-to-door trip planning and a single CPS can increase transit ridership, it will not likely see large scale adoption unless the FMLM trips are subsidized to the extent the transit trips are subsidized.

Background and Objectives

The Columbus area is characterized by high SOV usage, low transit usage, and low-density urbanization.2 For many residents, car dependency is not a choice as there are insufficient travel options (based on location) or there is a preexisting lack of trust or familiarity with existing travel options. Despite many positive initiatives to improve transit service and reliability, there is a public perception of excessive trip time and service uncertainty, coupled with a lack of familiarity with different options, such as AirConnect, CBUS, and others.

COTA’s objectives as the public transit provider in central Ohio and Columbus are to increase customer convenience and operational efficiency through seamless integration with implementation of its new Fare System and mobile ticketing solution. Below are specific objectives with respect to the new Fare System upgrade:

Reduce the use of cash-for-fare payment onboard buses to minimize dwell time and reduce operating costs, and to achieve cost efficiencies through the reduction of cash handling, number of forms of fare media and operating cost.

Reduce onboard fare processing time to improve on-time performance and make the boarding process easier and more convenient for customers.

Use centralized server/account-based processing in which fare calculation and payment are completely carried out in the back-office.

Provide customers a “guaranteed lowest fare” system that would automatically charge customers the lower amount based on how much they’ve travelled.

Allow retrieval of accurate and timely ridership and revenue data which can be used for detailed analysis and reporting to determine transit trends among riders.

Protect customer privacy and transaction security by complying with Payment Card Industry (PCI) standards, ensuring the security and confidentiality of Personally Identifiable Information (PII).

2 Ford Greenfield Labs: Columbus Mobility Design Research Report




Support open architecture and be extensible to support new technologies as they mature in the industry.

Operational Policies and Constraints

Operational policies and constraints in this section apply to the current situation. Operational policies are predetermined decisions regarding the operations of each component or sub-component of the current system, typically in the form of general decisions or understandings that guide development and decision-making activities. Operational policies inform decisions made in the design of the current system. Constraints are impediments outside of policy that restrict the current system from achieving its goal with respect to objectives.

Table 3: Operational Policies and Constraints of the Current System

Category Operational Policies and Constraints

Constraint COTA is limited in its ability to address the needs of the Smart Columbus program until the Fare System upgrade is complete.

Constraint COTA's new Fare System relies on a single vendor (SPX/Genfare) rather than open architecture designed to accept and support devices and technology from other vendors without custom integration. Integration with COTA's Fare System will require direct contracting with SPX/Genfare in addition to coordination with COTA.

Constraint It is acknowledged there are existing policies and constraints imposed by Mobility Providers through existing API usage which limit the functionality available to third-party developers, such as the ability to compare detailed cost information with potential competitor services. Also, some Mobility Providers may not currently share APIs with third-party developers or support open standards and data exchange. Many of these operational policies and constraints are described in detail for the proposed system (Chapter 5. Concept for the New System) and will be addressed in subsequent partner agreements.

Constraint Parking Providers may not, under their current contracts, be under obligation to share data with a third party. This constraint is addressed in more detail in the EPM ConOps.





Category Operational Policies and Constraints

Policy With respect to COTA’s Fare System upgrade, there are no operational policies preventing integration with the CPS or limiting third-party developers from integrating with the new system; however, integration is only possible through a separate contract with SPX/Genfare, the vendor for the system upgrade. COTA’s specifications with SPX/Genfare require compatibility with alternate modes of transportation – such as ridesourcing and car-sharing companies – as part of the integration with the Smart City initiative and to be able to expand as new technology becomes available.

According the COTA’s specification for the new fare system, Requirement 15.4.1.a: The fare management system shall maintain flexibility for potential future integration with external systems including, but not limited to, accepting for COTA rides the payment media associated with, and/or enabling acceptance of COTA fare media with:

COTA City Cards

Third-party transit agency cards

Ridesourcing services (e.g. Uber)

Mode-share services (e.g. Zipcar, CoGo bike-sharing); and Partner retailers

Policy Fixed-route schedule and bus location data feeds are freely available from COTA but are provided on an “as is” and “as available” basis. COTA grants non-exclusive, limited and revocable rights to use, reproduce, and redistribute its data subject to the terms of agreement and use defined on their website (http://www.cota.com/data).


Description of Current System

Central Ohio Transit Agency Fare System Redesign

COTA is currently undergoing a redesign of its fare collection system by replacing all the fareboxes on its fleet of approximately 367 coaches and installing “validators” on approximately 80 coaches that will permit cashless transactions and integrate with an account-based mobile ticketing solution. COTA is also planning to upgrade and/or replace their current Ticket Vending Machines (TVMs) and Point of Sale (PoS) workstations to allow for multiple forms of payments and payment media such as smart cards, online payments and standard magnetic cards.

COTA’s Fare System upgrade consists of the following components and subsystems:

Fare Management Central System (account-based)

Reporting module

Mobile ticketing application

Fareboxes (e.g., accepting cash, smartcards, e-tickets, read-only magnetic stripe cards)

Ticket Vending Machines (TVMs)




Point of Sale (POS) workstations

Stand-alone smartcard, magnetic stripe card, and e-ticket reader for demand response vehicles (conserving space in comparison to a farebox)

Smart card stock

Smart card printer and encoder

Accepted fare media include:

Contactless, Radio Frequency Identification (RFID)-equipped smart cards

Mobile devices with optical bar code [and support for Near-field Communications(NFC)] – “e-ticket”

Limited-Use Media (LUM) with optical bar code

Magnetic stripe cards

Cash

Fareboxes on busses will be equipped with a contactless RFID reader compliant with the ISO 14443 Type A and B standard for smart cards, NFC-enabled mobile devices, and credit/debit contactless payments. The Fare System will accept various forms of payment including cash, magnetic cards, smart cards and mobile tickets (Figure 6: COTA Farebox Upgrade).






Figure 6: COTA Farebox Upgrade

A mobile ticket represents a virtual credit redeemable for one trip in the COTA network. After positive validation at a farebox, the mobile ticket is redeemed in the central Fare System and expires from the Traveler’s account. Fare payment media, such as credit/debit cards, that are activated on a mobile app will be visually represented as a mobile e-ticket: a virtual page with standardized graphical elements, to be displayed on the mobile device screen for presentation and validation visually and/or by optical scanning. All mobile tickets will display at minimum the following information:

A machine readable 2D optical code compliant with ISO-15415, encoding the unique serial number that shall serve to create the identifier used to validate and track the ticket and associated transactions in the system

Human readable text displaying the serial number encoded in the optical code

A dynamic security feature verifiable by a human inspector (e.g. moving graphic, changing color, real-time clock)

A soft key to close the mobile ticket

Opening the mobile ticket page will set the ticket in an active state (in use). For the duration that the mobile ticket is active, a selectable notification shall appear in the mobile device’s notification center. The




device user will be able to access the mobile ticket page directly by selecting this notification. For the duration that a mobile ticket is active, the user will retain the unlimited ability to move between pages of the app, minimize the app, and use other apps on the device, and return to the active mobile ticket screen upon maximizing the app. An active mobile ticket will remain accessible to the user in an active state for presentation and validation following an unexpected shutdown of the app, or reboot of the device; the original activation time and date shall remain in effect.

If the mobile device NFC-enabled and compliant with ISO 18092/ ISO 21481, the device will broadcast the same unique serial number that is encoded in the optical code, while the mobile ticket remains active. Closing the mobile ticket page will set the ticket in an inactive state (not in use), clearing the notification from the device’s notification center, and terminating any NFC transmission.

Modes of Operation for the Current System

Table 4: Modes of Operation for the Existing COTA System describes the modes of operation for the current system, including the impacted user classes for each mode.

Table 4: Modes of Operation for the Existing COTA System

Mode Definition

Operational (regular) Normal operating condition, the current system is operating as designed. The system is function during all hours of the day and is continually available, 24-hour per day, 365-day per year operation.

Reduced availability Reduced availability associated with planned maintenance but falling outside the start and/or end times and dates agreed between COTA and the Contractor as considered as impacting system availability.

Mission Critical Errors (Severity 1) A Mission Critical Error is defined as an error that renders the system or a core set of functions unusable.

Severe Impact Errors (Severity 2) A Severe Impact Error is defined as an error that severely impacts the core functions by slowing them down to perform outside of established performance requirements. A workaround might be available for the impacted core functions.

Minor Impact Errors (Severity 3) A Minor Impact Error is defined as an error that affects system operation or functionality in any way but is not a Critical Error or Severe Impact Error.

Maintenance The condition of the current system where service is unavailable due to routine or unscheduled maintenance.

Source: COTA





User Classes of the Current System

Travelers, the City, COTA and the Fare System Vendor comprise the user classes of the current system as described in this section. Table 5: Current System Users describes these user classes.

Table 5: Current System Users

User Classes Description

The City The City is comprised of City of Columbus employees who wish to partner with COTA to facilitate multimodal trip planning and payment for Travelers. The City desires to collect ridership data to guide public policy decisions and make informed decisions regarding economic and transportation policy, and to be able to forecast economic changes and travel behavior in the region.

Travelers End-users of the current system (residents and visitors of Columbus) who utilize COTA's fixed-route bus service as well as disintegrated third-party apps and services to plan and pay for services in the region.

Mobility Providers Transportation service providers who offer their own single-purpose mobile apps with the common objective of offering superior transportation services to their own customers. Mobility Providers in the Columbus region who have participated in stakeholder engagement for the ConOps include Lyft, Yellow Cab, Uber, CoGo, Zipcar.

COTA COTA employees who are responsible for system management and related operations and services; and for determining policies and regulations related to the fare management system, and for managing contracts with the vendor of the system. COTA employees who are responsible for maintenance, uptime, and availability of the system; and for troubleshooting and coordinating between travelers, operational users, and the vendors of the bus and fare system.

Fare System Vendor SPX/Genfare is responsible for developing and implementing the Fare System upgrade for COTA, and for back-end functions related to fare collection and management.





Chapter 4. Justification and Nature of Changes

While COTA’s Fare System upgrade satisfies many of the needs for the CPS account-based solution, it does not currently provide for integration with other transportation companies to allow payment processing for different modes, and its planned mobile ticketing component is not integrated with other third-party trip planning apps other than its own fixed-route bus system.

Gaps in the current system may be summarized as follows:

Disintegrated mobile apps require travelers to download and install multiple apps and register multiple payment media to plan and pay for multimodal trips

Lack of a comprehensive platform to plan, book, and pay for multimodal transportation

City agencies do not control the trip data, and face obstacles when requesting trip data from Mobility Providers

Trips are not being optimized for ride-sharing

Unbanked users must rely on cash for transportation options

Lack of incentives for Mobility Providers to be part of a MaaS solution

Lack of incentives for Travelers to engage in multimodal trips

The overarching objective of the MMTPA/CPS is to provide a single convenient app where travelers can plan and pay for multimodal trips from a single convenient account. This need is especially prevalent when some portion of the trip is taken with fixed-route bus service. A fixed-route bus service is unlikely to originate at a customer’s desired point of origin, and unlikely to terminate at their preferred destination. As such, the use of fixed-route bus service creates a need for FMLM transportation, whereby a person must find suitable transportation from their origin to the beginning of a fixed-route bus trip, and from the termination of their fixed-route bus trip to their ultimate destination. Currently, it is not possible to visit a single website or application and obtain information on multiple transportation options beyond transit, walking and personal vehicle tied to pricing, payment, and scheduling services that can satisfy these needs.

Multimodal transportation is an important service that has emerged as a leading Smart City application. Columbus has committed to improving transportation options for all residents, including access to jobs and opportunities that are serviced through improved transportation options, through the Smart Columbus project in general, and the MMPTA/CPS project specifically. This section identifies the user needs developed for the MMTPA/CPS project and the justification of those user needs derived from existing city goals, working group sessions, surveys, and interviews. Refer to Appendix A and Appendix B for more information on stakeholder outreach activities.




Furthermore, the lack of a current, comprehensive system for multimodal trip planning can be a source of inconvenience for travelers. A single point of information and scheduling services could provide additional convenience and completeness.

Justification for Changes

The MMTPA will address eight primary gaps in the current system that are unmet under existing conditions. By satisfying these needs, the MMTPA/CPS will achieve its objective of supporting multimodal trip planning, and ultimately its goals of improving mobility, efficiency, opportunity and customer satisfaction. Table 6: Justification for Changes outlines the improvements the MMTPA/CPS offers above and beyond the existing system.

Table 6: Justification for Changes

User Class Current Situation Benefit of MMTPA/CPS

The City The City does not have a single point of information about how travelers are accessing and paying for transportation in Columbus and needs actionable information about transportation usage to make better policy decisions.

The City will have access to detailed travel data through integration with the Operating System. Data generated by the MMTPA/CPS and collected in the Operating System to forecast economic changes and travel behavior. Information can be used to guide public policy decisions.

Travelers Travelers do not have a single, comprehensive list of Mobility Providers available and need real-time information about what Mobility Providers are currently operating in the area. Travelers are not informed when new Mobility Providers come online or when an existing Mobility Provider suspends service or exits the market.

The MMTPA/CPS will provide Travelers with a single, comprehensive list of Mobility Provider options currently available in an around Columbus.

Travelers Travelers must pay Mobility Providers separately using multiple apps, which requires creating and maintaining separate accounts and different forms of payment. There is no single application which is integrated with a CPS to allow payment for multiple trip segments at once.

The MMTPA/CPS will allow Travelers to maintain a single account through which all Mobility Providers may be paid for all trip segments taken. The CPS will provide a single back-office, account-based system allowing users to register multiple forms of payment to pay for transportation and parking services.





User Class Current Situation Benefit of MMTPA/CPS

Travelers Travelers need to gather travel information from multiple sources, individual websites or applications, but are unable to book trips through a single application, or plan and pay for an entire multimodal trip from origin to destination using a single mobile application.

Provide Travelers with a tool to plan/reserve and book a multimodal trip through single application.

Travelers Travelers must enter preferences into multiple Mobility Provider websites or mobile applications or are limited in the number of preferences they can store to customize trip planning results.

Provide Travelers with a single tool that records their travel preferences and filters/sorts their travel options based on those configurable preferences.

Travelers Travelers must visit multiple Mobility Provider websites or applications to obtain pricing estimates, then compare and make any adjustments needed before manually comparing those estimates.

Provide Travelers with a single tool to compare costs across modes and individual Mobility Providers so they can make better informed travel decisions.

Travelers Unbanked or underbanked users must rely on cash for transportation services.

A system that can be used by residents and visitors alike who are unbanked or underbanked and wish to utilize the CPS; reduce number of cash transactions.

Mobility Providers Mobility Providers are operating in silos and not providing customers with a single convenient experience.

The ability to price journeys across multiple modes, coupled with visible and modifiable business rules for allocating revenue across Mobility Providers, which allows them to understand and support the shift to integrated management.


Description of Desired Changes

As the public transit provider in central Ohio and Columbus, whose mission is to connect neighborhoods and residents together, COTA plays a vital role in the facilitation of MaaS. Working together with Mobility Providers will allow COTA to increase coverage and attractiveness of transit services, and lead to increased ridership and fewer SOV trips. By incorporating other Mobility Providers into a common platform with transit, MaaS can resolve FMLM travel barriers preventing users of the current system from relying solely on transit services.




The MMTPA/CPS will add new capabilities over the existing system and improved mobility for users, such as ability to compare costs between Mobility Providers, integration with the CPS allowing for all segments of a multimodal trip to be paid at once, and integration with the Operating System for improved access to travel data and system performance. The desired outcome of the MMTPA/CPS for the region is to increase usage of existing transportation services in Columbus, which can potentially increase access to jobs and services for residents. Capability changes in the proposed system are summarized below.

Table 7: Major Capability Changes in the Proposed System

Gaps in the Existing System Major Capability Changes in the Proposed System

Disintegrated mobile apps and services require travelers to download and install multiple apps and register multiple payment media to plan and pay for multimodal trips

Provide travelers with a single, convenient platform to plan, book, and pay for multimodal trips through a single app; it should not be necessary to install and maintain multiple apps to get from Point A to Point B.

Provide incentives for multimodal trips which may include credit toward different modes of travel based on preferences

Lack of control of trip data; public agencies face obstacles when requesting trip data from Mobility Providers

Use the Operating System to plan trips and share trip data with third-party users; do not depend on third-party apps to provide trip planning.

Utilize deep integration tools and APIs offered by Mobility Providers to optimize trip requests in the Operating System.

Centralize data in the Operating System to forecast economic changes and travel behavior.

Trips are not optimized for ride-sharing

Use the Operating System to optimize trips for ride-sharing and provide on-demand services for paratransit; meet National Transit Database (NTD) requirements to allow for federal subsidies, reduce current paratransit costs, improve ridership, and work together with fixed-route to provide multimodal door-to-door service.

Fewer mobility options for unbanked users, and users without access to smartphones

Improve mobility for all Travelers with access to different modes of transportation, such as car-sharing, and options for door-to-door service; provide personalized trip itineraries.

Allow unbanked Travelers to fund CPS accounts using reloadable prepaid debit cards not tied to checking accounts, or by loading cash into their CPS accounts at COTA TVMs.

Allow Travelers without smartphones to access an IVR system that allows use of a touch-tone phone to request a pre-purchased trip pickup.





Gaps in the Existing System Major Capability Changes in the Proposed System

Lack of incentives for Mobility Providers

Allow for seamless payments integration.

Mobility Providers will increase “customer-centric” focus through partnership with Smart Columbus and willingness to improve mobility options for the public.

Access to comprehensive trip data captured in the Operating System may lead to better decision making and better customer service and give new insights on travel usage in the Columbus region.

Provide opportunity for Mobility Providers to grow business by linking to larger regional transit systems (COTA) through MMTPA.

Allow for potential cost reduction by integrating with the CPS to streamline payment services.


Table 8: User Needs contains user needs of the project as identified by stakeholders of the project, use cases, survey, and existing systems. Each need is given a combination of unique identifier and title for reference purposes in Chapter 6. Operational Scenarios. All user needs are grouped by class as defined in Chapter 5. Concept for the New System.

By meeting these user needs, the MMTPA/CPS will provide value beyond the current system, support multimodal trip planning, and increase mobility throughout Columbus. These claims can be objectively evaluated by focusing on indicators of application usage and customer satisfaction with the MMTPA and CPS. The Smart Columbus team will collect traveler survey data directly from MMTPA/CPS users, as well as usage information from the Operating System to better understand how customers are using the MMTPA/CPS, and how satisfied they are with the application. More detailed information on the types of information collected and the statistical analysis used to make inferences about overall application success will be forthcoming in the Smart Columbus Performance Measurement Document.




Table 8: User Needs

Identification Title Description Rationale

TRAVELER NEEDS

MMTPA/CPS-UN001-v02

Real-Time Travel Information

The MMTPA/CPS system needs to provide Travelers with access to real-time travel information. Real-time travel information will vary depending on the mode of travel. For example, fixed-route service will include real-time updates on arrival time, bike-shares will include real-time updates on availability at stations, and TNCs will include real-time updates on service availability and price. As appropriate, real-time travel information will include present and expected departure and arrival times accounting for traffic congestion and delays. Travelers need the MMTPA to provide real-time vehicle location and availability information to the Operating System, to allow trip optimization services to determine the best available trip options for Travelers based on location, destination, and user preferences.

To effectively plan routes, make connections, switch modes, and determine if services are running late.

MMTPA/CPS-UN002-v02

Personal Devices The MMTPA/CPS system needs to operate on iOS and Android devices. Travelers need to be able to download and install the MMTPA to their personal devices from public app stores.

To support a range of device operating systems.






MMTPA/CPS-UN003-v02

Compare Trip Itineraries The MMTPA/CPS system needs to provide Travelers with the ability to compare trip itineraries by mode, travel time (i.e., quickest), and cost (i.e., lowest). For services where cost information is subject to change, the MMTPA needs to update prices in near real-time so that they may adjust travel choices as needed if pricing information changes. Depending on the service, cost information may be an estimate of actual costs based on travel distance and/or other pricing factors as determined by the provider. Cost information needs to be available in near real-time to allow Travelers to adjust travel choices as needed. The MMTPA will present trip itineraries to Travelers in accordance with individual user preferences stored in the MMTPA. For example, if a user has a stored preference for trip segments below a certain cost threshold, then only trip segments meeting the preference will be considered when determining the best trip options for the Traveler.

To make informed travel decisions regarding mode, travel time, and cost, in accordance with personal preferences.





MMTPA/CPS-UN004-v02

User Preferences The MMTPA/CPS system needs to provide Travelers with the ability to store user preferences. User accounts will be password protected and the users will be able to change their passwords. Preferences include (1) preferred mode/service, (2) maximum total cost, (3) maximum number of trip segments, (4) preferred results presentation format (order by “cheapest” or quickest route), (5) car preference (for car-sharing services), (6) maximum price per mode, (7) maximum trip duration, (8) preferred maximum walking distance, (9) accessible vehicle, (10) environmental impact or “greenest” trip, (11) dedicated bike lane. User preferences should be optional configurations in the application. Price preferences should be specific to transportation mode. For example, a user should be able to specify a price preference for a specific car-sharing service not to exceed $20 for any individual trip. The system must record preferences for multiple transportation modes and recommend trip segments based on those preferences. Users also need the ability to easily view travel options that do not satisfy stored preferences, without having to change those settings within the application. This ability is important to facilitate making informed travel decisions.

To reduce or filter unwanted services and modes from the set of choices presented in the MMTPA.

MMTPA/CPS-UN005-v02

Accept Bookings/Reservations

The MMTPA/CPS system needs to provide Travelers with the ability to book/reserve trips in accordance with the policies of individual Mobility Providers and to receive confirmation that trips have been processed and accepted. For example, for trip segments using public transit the Traveler will be able to purchase an electronic ticket using the MMPTA, and for trip segments using bike-sharing the Traveler will be able to view bike availability at stations and purchase a ride code to unlock the bike.

To provide the convenience and flexibility of using a single application to book/reserve multimodal trips.






MMTPA/CPS-UN006-v02

CPS Integration The MMTPA/CPS system needs to provide Travelers with seamless integration with the CPS. Travelers will be able to view, book, and pay for multimodal services without leaving the MMTPA.

To pay for multimodal trips and to eliminate the need for multiple applications or multiple forms of payment.

MMTPA/CPS-UN007-v02

Access to Instructions and Educational Material

The MMTPA/CPS system needs to provide Travelers with access to limited instructions for use of the application. Instructions will be accessible within the application, such as help with navigation or how to access account information. Travelers will have access educational material outside of the application, such as links to educational material pertaining to each mode of service to understand how the service works. Access to instructions and educational material does not constitute training, either web-based or in-person.

To facilitate understanding and adoption of the application.

MMTPA/CPS-UN008-v02

Notifications and Alerts The MMTPA/CPS system needs to notify Travelers of service disruptions, or if a reserved trip is delayed or canceled. Travelers may configure the types of notifications they receive, including frequency, to provide for better user experience. Travelers will receive personalized traffic information including early warning in case of an increasing travel time to a specific location and possible alternative routes and/or modes. An example of this would be a notice based on predictive traffic information or a travel time forecast. Travelers will be notified when reaching an important step during travel such as an upcoming transfer point. Users also need to be informed when a reserved service is no longer available or is altered. Users need to be provided with notifications or prompts, such as departure times or stop notifications. Options for receiving notifications and alerts should include push notifications, email, and text message.

To be informed of changes to a scheduled trip and to adjust as needed.





MMTPA/CPS-UN009-v02

Trip History The MMTPA/CPS system needs to provide Travelers with the ability to view trip history. Trip history will not be stored in the Operating System.

To have a complete record of all travel

MMTPA/CPS-UN010-v02

Trip Changes The MMTPA/CPS system needs to allow Travelers to make changes to an existing trip. This includes changes or cancelations prior to the start of the trip or changes made during a trip (if applicable). Cancelations or changes will be subject to the policies of individual Mobility Providers. The MMTPA/CPS system needs to notify Mobility Providers if a reserved trip is canceled or modified by a Traveler, in order for them to process the request and make the necessary changes as allowed.

To account for unforeseen changes and allow for convenience and flexibility when traveling.

MMTPA/CPS-UN011-v02

Loyalty, Incentives and Rewards

The MMTPA system needs to provide Travelers with access to incentives and rewards for scheduling and completing multimodal trips using the CPS. Incentives and rewards may include discounted transportation, or points toward coupons that may be earned from participating Mobility Providers, local vendors and merchants. Loyalty programs can be monitored through the system. Gamification may also be used to incentivize multimodal trips. Travelers need to be able view progress towards earning an incentive or reward when logged into the MMTPA to monitor progress. Incentives and rewards will be administered through back-office functions of the CPS.

To influence user adoption of the MMTPA/CPS and to encourage multimodal trips.

MMTPA/CPS-UN012-v02

Graphical User Interface The MMTPA/CPS system needs to provide Travelers with a Graphical User Interface (GUI). The GUI needs to display maps, text and other graphical information to allow effective use of the application. Travelers also need an interface to make payments, manage account information, and register payment methods. All interfaces need to be simple to use and facilitate use on a mobile device.

To allow Travelers to interact with the app.






MMTPA/CPS-UN013-v02

User Feedback The MMTPA/CPS system needs to provide Travelers with the ability to submit feedback on the app. This information will be used by the City and COTA to determine whether the application is working as intended and to make enhancements. The MMTPA/CPS system also needs to provide Travelers with the ability to submit feedback to Mobility Providers through integration with existing feedback systems.

To communicate likes and dislikes while using the app.

MMTPA/CPS-UN014-v02

Offline Usage The MMTPA/CPS system needs to provide Travelers with the ability to continue using the application when internet connectivity is temporarily unavailable. This ability may be limited to static data or map cache for the current trip.

To allow for limited, uninterrupted use when there is no internet connectivity

MMTPA/CPS-UN015-v02

Trip Optimization The MMTPA/CPS system needs to provide Travelers with trip optimization services (routing engine) using data from Mobility Providers and Traveler's preferences. Trip optimization will consider all available travel information from Mobility Providers, including City/COTA business rules and Traveler preferences, to calculate the best route options.

To determine the best route options for Travelers based on available data from Mobility Providers and user preferences.

MMTPA/CPS-UN016-v02

IVR System The MMTPA/CPS system needs to allow Travelers without access to smartphones to utilize the system. It is envisioned that an IVR System may be available to travelers at Smart Mobility Hubs to schedule a trip. Providing access to the system for users without access to smartphones is needed to meet a Title VI provision to qualify for NTD funding. Other options, such as a Call Center, are believed to be cost prohibitive.

To allow Travelers without smartphones to utilize the MMTPA/CPS system to purchase FMLM tickets.





MMTPA/CPS-UN017-v02

Same-Day Paratransit Service

The MMTPA/CPS system needs to provide qualifying Travelers with disabilities with on-demand, same-day paratransit services through integration with ridesourcing services. The MMTPA/CPS system needs to include dynamic dispatch and routing of vehicles, with the ability to track vehicle arrival on a map.

To accommodate FMLM trips and reduced travel costs for qualifying Travelers with disabilities.

MMTPA/CPS-UN018-v02

Request Accessible Vehicles

The MMTPA/CPS system needs to provide qualifying Travelers with disabilities the ability to request accessible vehicles. The MMTPA needs to store this information to prevent having re-enter the same request for each subsequent trip.

To accommodate special vehicle needs for qualifying Travelers with disabilities.

MMTPA/CPS-UN019-v02

NFC Integration The MMTPA/CPS system needs to support Near-Field Communication (NFC) and Bluetooth mobile payments, as well as SPX/Genfare QR codes.

To allow seamless validation at COTA fareboxes via mobile devices.

MMTPA/CPS-UN020-v02

Electronic Pay Wallets The MMTPA/CPS system should have the capability to support use of electronic wallets (Apple Pay, Android Pay, Google Pay) and the capability to support contactless Europay, MasterCard, Visa (EMV) cards.

To allow for growth and expansion of payment methods.

MMTPA/CPS-UN021-v02

Mobile Ticketing The MMTPA/CPS system needs to provide Travelers with access to mobile ticketing. The MMTPA needs to be integrated with COTA’s mobile ticketing solution in order to generate COTA fare media. COTA’s Fare System may also be responsible for generating barcodes that are used to unlock car-share vehicles. Barcodes need to be transmitted to the Traveler in the same manner as COTA fare media.

To allow for purchase of mobile tickets via the app.






MMTPA/CPS-UN022-v02

CPS Account The MMTPA/CPS system needs to provide Travelers with the ability to create an account through a one-time setup process that prompts users for billing information (e.g., cash, credit/debit cards, prepaid debit cards, or other electronic payment). Account information should include the following, at a minimum: first and last name, date of birth, telephone number, email address, mailing address, and authenticating security question and answer. This information will be independent of any personal information related to connection of payment accounts. Once an account is created, the Traveler will be able to log in using an ID and password. Travelers who do not wish to create a CPS account will be able to create a temporary account for issuing a one-time payment. Travelers need to be able to recover lost passwords and have the ability to delete their CPS account if desired. Travelers need to be able to create a Guest Account to make payments using the CPS, but payment information is not stored and the account is not permanent. The Guest Account will be available for users who do not wish to create a permanent CPS account. Travelers need the CPS to provide the ability to register multiple forms of payment and to specify a default payment method to be used when paying for transportation services or parking services. Users will need to be able to set a preferred payment method. There may be times when a user's preferred payment method cannot be used, for example, if a preferred credit card has expired, in which case another payment method may be substituted. Also, the availability of certain payment methods may be limited based on a service being used to complete the transaction. For example, there may be restrictions on the types of payment for a service. Mobility Providers will be required to establish merchant accounts in the CPS to receive payment in exchange for services offered through the MMTPA.

To manage contact information, payment media, and user preferences.





MMTPA/CPS-UN023-v02

Payment Media The MMTPA/CPS system needs to accept numerous forms of payment. Payment media include cash, all major US credit/debit cards (includes all cards issued from the following US financial institutions: American Express, Discover, MasterCard, and Visa), major international cards, and debit cards (reloadable cards that are not tied to a personal checking account). Travelers who are unbanked will be able to purchase a COTA smart card with cash or use a reloadable prepaid debit card not tied to a financial institution or checking account to fund a CPS account. It is anticipated that smart cards will be available for purchase at retailers throughout Columbus.

To provide Travelers with flexible payment options in order to pay for transportation services.

MMTPA/CPS-UN024-v02

Subsidization The MMTPA/CPS system needs to provide the ability for third parties (such as an employer, a college or university, or guardian) to subsidize transportation. For example, a Traveler’s account in the CPS may be linked to an employer’s account if that employer wishes to subsidize the employee’s transportation.

To enable eligible Travelers to receive subsidized travel through their CPS account.

MMTPA/CPS-UN025-v02

Pay Once The MMTPA/CPS system needs to allow Travelers to “click once” to pay for services. For example, an MMTPA user who creates a trip involving multiple trip segments and modes of transportation, and who has a registered CPS account, will only need to pay once for all trip segments. Travelers who do not wish to register a CPS account will be able to make one-time payments. For example, when attempting to pay without a CPS account, users will have the option to “continue as guest.”

To make payment for multimodal trips convenient.






MMTPA/CPS-UN026-v02

Existing Fare Products The MMTPA/CPS system needs to allow Travelers with existing fare products, such as COTA’s C-pass program, to utilize the existing fare product when paying for associated trips. For example, existing C-pass or OSU riders who have unlimited passes to use COTA services and would need to have those passes recognized by the System when using the MMTPA/CPS to pay for travel. It is envisioned that existing fare products for any Mobility Provider will be accounted for in the Traveler’s CPS account.

To avoid charging the Traveler’s CPS account rather than existing fare products, resulting in overpayment.

MMTPA/CPS-UN027-v02

Notification of Payment and Account Status

The MMTPA/CPS system needs to alert Travelers of payment and account status. Travelers need the CPS to alert them in case of insufficient funds so they may address the situation.

To know when payment transactions are complete or if actions are required.

MMTPA/CPS-UN028-v02

Traveler Web Portal The MMTPA/CPS system needs to provide Travelers with a web portal. Travelers need the ability to manage account settings, payment products, and contact info, as well as the ability to view and export CPS transactions. Travelers should be able to perform the same trip planning functions as in the MMTPA.

To create and manage account information.

MMTPA/CPS-UN029-v02

Storage of Sensitive Data The MMTPA/CPS system needs to provide Travelers with the ability to store sensitive credit card data for processing payment requests. Travelers need the CPS to comply with the latest PCI data security standards, including all audit and compliance certification activities to ensure personal and financial safety.

To comply with the latest PCI data security standards to ensure personal and financial safety.





MMTPA/CPS-UN030-v02

Reimbursement The MMTPA/CPS system needs to reimburse Travelers if a transaction is canceled or a service that has been purchased is unavailable. The ability for the CPS to process reimbursement for Travelers will be subject to terms and conditions set forth by the Mobility Providers, not by the CPS.

To prevent Travelers from being charged for services that are not delivered or that need to be canceled due to circumstances such as change of plans.

MMTPA/CPS-UN031-v02

Security and Encryption The MMTPA/CPS system needs to encrypt communications. This applies to the transport layer.

To protect Traveler information from those not authorized to view it.

MMTPA/CPS-UN032-v02

Support for Multiple Languages

The MMTPA/CPS system needs to provide Travelers with the ability to select English or Spanish (at a minimum) as their preferred language at any point before or during any transaction and present all dynamic text and audible words (if applicable) to the Traveler in their preferred language. Training and educational material should also support the Traveler’s preferred language.

To support the Traveler’s preferred language.






CITY AND COTA NEEDS

MMTPA/CPS-UN033-v02

Access to Trip and Payment Data

The MMTPA/CPS system needs to provide the City and COTA with access to data generated by the MMTPA/CPS system. Trip and payment data consist of the following and pertain only to an executed trip in which payment is made: trip request (time, origin, destination, route), trip start time, mode, transfer (time, location, disembarked, embarked), trip end time, payment initiated, payment amount, payment complete. The trip should reference all trip activity for each mode for multi-leg trips. Trip and payment data will not contain Personally Identifiable Information (PII) that could potentially identify a specific individual.

To forecast travel behavior, economic changes, and guide public policy decisions.

MMTPA/CPS-UN034-v02

Operations and Maintenance

The MMTPA/CPS system needs to be maintained and operated external to the City.

To reduce impact on internal staff and to maximize operational efficiency.

MMTPA/CPS-UN035-v02

Future Growth and Maintainability

The MMTPA/CPS system needs to be architected to allow for incorporation of additional Mobility Providers in the future with minimal impact to the environment itself, such as need for redesign or rewrite of the application code, and minimum impact on the MMTPA/CPS, such as need to reinstall the application.

To support future growth and maintainability of the system.

MMTPA/CPS-UN036-v02

Compliance The MMTPA/CPS system needs to be responsible for compliance tasks related to the act of processing and handling payments between the Travelers and the Mobility Providers.

To ensure proper handling of payments.





MMTPA/CPS-UN037-v02

Certification and Accreditation

The City and COTA need a certification and accreditation provider to assess the quality, security, and "openness" of the System. Quality is defined as the state of being free from defects, deficiencies and significant variations, and is achieved through demonstration of the ability to satisfy user needs. Security is defined as the state of being protected against the unauthorized use or loss of information, especially electronic data, and the measures taken to achieve this. Openness refers to the adherence to open standards and design to ensure the System or aspects of the System are beneficial to other cities as part of the Smart Cities initiative.

To ensure the System meets user needs.

MMTPA/CPS-UN038-v02

Audit Capability The MMTPA/CPS system needs to provide the City and COTA with an ability to audit the system. This need includes the ability to conduct a financial audit of system.

To check for “failed” trips (e.g. trips that were not completed), compile user feedback, and supply information on overall health of system.

MOBILITY PROVIDER NEEDS

MMTPA/CPS-UN039-v02

Receive Real-Time Travel Information

The MMTPA/CPS System needs to allow Mobility Providers to provide travel information, such as real-time vehicle location, availability, schedule, route, transaction, and cost information so that it is available to Travelers.

To allow for trip optimization services (trip planning, payment, execution and modification).






MMTPA/CPS-UN040-v02

Mobility Provider Accounts The MMTPA/CPS System needs to provide Mobility Providers with the ability to manage payment preferences, and to query and view transactions related to payments. Mobility Provider Accounts will facilitate payment transactions and ensure that each Mobility Provider receives payment. The process of payout for each individual Mobility Provider will be defined in the CPS requirements document. Payout timing will be at a negotiated frequency with the Mobility Providers.

To allow for Mobility Providers to be paid for services.

MMTPA/CPS-UN041-v02

One-to-One and One-to-Many Payment Requests

The MMTPA/CPS System needs to be able to handle one-to-one and one-to-many payment requests, in which payment for multimodal trips is split between numerous Mobility Providers. For example, a Traveler using the MMTAP/CPS system to book a multimodal trip will pay once for the total trip and the Traveler’s funds will be split for each trip mode to pay each Mobility Provider separately.

To allow individual Mobility Providers to be paid as part of a multimodal trip.

MMTPA/CPS-UN042-v02

Funds in Reserve The MMTPA/CPS System needs to be able to hold Traveler funds in reserve for a period of time before being used for services. For example, a Traveler using the MMTPA/CPS to book transportation services may have funds held in reserve until the event has taken place, such as when payment is required at the end of a trip, to ensure that adequate funds are available.

To allow payment to Mobility Providers when services are rendered, which may be different from the time at which services are booked.

MMTPA/CPS-UN043-v02

End User License Agreement

The MMTPA/CPS System needs to provide Travelers with an End User License Agreement covering their responsibilities, liabilities, and limited use of the app.

To shield Mobility Providers, the City, and COTA from misuse of the app and cover grounds for account closure.




Priorities Among Changes

Table 9: Priorities Among Changes classifies the priorities among changes as essential, desirable or optional. Essential items are considered essential to the success of MMTPA/CPS and must be included as part of the final solution. Desirable items are important to the overall system but may be excluded from the final solution on a case by case basis. Optional items are nonessential and may be excluded from the final solution without impacts.

Table 9: Priorities Among Changes

Rank Title Priority Classification User Need

1 Real-Time Travel Information Essential MMTPA/CPS-UN001-v02

2 Personal Devices Essential MMTPA/CPS-UN002-v02

3 Compare Trip Itineraries Essential MMTPA/CPS-UN003-v02

4 User Preferences Essential MMTPA/CPS-UN004-v02

5 Accept Bookings/Reservations Essential MMTPA/CPS-UN005-v02

6 CPS Integration Essential MMTPA/CPS-UN006-v02

7 Access to Instructions and Educational Material

Essential MMTPA/CPS-UN007-v02

8 Notifications and Alerts Essential MMTPA/CPS-UN008-v02

9 Trip History Essential MMTPA/CPS-UN009-v02

10 Trip Changes Essential MMTPA/CPS-UN010-v02

11 Graphical User Interface Essential MMTPA/CPS-UN012-v02

12 User Feedback Essential MMTPA/CPS-UN013-v02

13 Offline Usage Essential MMTPA/CPS-UN014-v02

14 Trip Optimization Essential MMTPA/CPS-UN015-v02

15 Request Accessible Vehicles Essential MMTPA/CPS-UN018-v02

16 NFC Integration Essential MMTPA/CPS-UN019-v02

17 Mobile Ticketing Essential MMTPA/CPS-UN021-v02

18 CPS Account Essential MMTPA/CPS-UN022-v02

19 Payment Media Essential MMTPA/CPS-UN023-v02

20 Pay Once Essential MMTPA/CPS-UN025-v02

21 Existing Fare Products Essential MMTPA/CPS-UN026-v02





Rank Title Priority Classification User Need

22 Notification of Payment and Account Status Essential MMTPA/CPS-UN027-v02

23 Traveler Web Portal Essential MMTPA/CPS-UN028-v02

24 Storage of Sensitive Data Essential MMTPA/CPS-UN029-v02

25 Reimbursement Essential MMTPA/CPS-UN030-v02

26 Security and Encryption Essential MMTPA/CPS-UN031-v02

27 Support for Multiple Languages Essential MMTPA/CPS-UN032-v02

28 Access to Trip and Payment Data Essential MMTPA/CPS-UN033-v02

29 Operations and Maintenance Essential MMTPA/CPS-UN034-v02

30 Future Growth and Maintainability Essential MMTPA/CPS-UN035-v02

31 Compliance Essential MMTPA/CPS-UN036-v02

32 Receive Real-Time Travel Information Essential MMTPA/CPS-UN039-v02

33 Mobility Provider Accounts Essential MMTPA/CPS-UN040-v02

34 One-to-One and One-to-Many Payment Requests

Essential MMTPA/CPS-UN041-v02

35 Funds in Reserve Essential MMTPA/CPS-UN042-v02

36 End User License Agreement Essential MMTPA/CPS-UN043-v02

37 IVR System Desirable MMTPA/CPS-UN016-v02

38 Same-Day Paratransit Service Desirable MMTPA/CPS-UN017-v02

39 Electronic Pay Wallets Desirable MMTPA/CPS-UN020-v02

40 Subsidization Desirable MMTPA/CPS-UN024-v02

41 Certification and Accreditation Desirable MMTPA/CPS-UN037-v02

42 Audit Capability Desirable MMTPA/CPS-UN038-v02

43 Loyalty, Incentives and Rewards Desirable MMTPA/CPS-UN011-v02





Changes Considered but not Included

Connection Protection

A Connection Protection (CP) system was evaluated to improve the reliability of COTA bus transfers for users of the MMTPA. Connection protection refers to a system which will hold a bus for someone that has reserved a trip. In discussions with COTA on the practicality of implementing a CP system for Columbus, it was determined that automating such a system would be beyond the scope of the MMTPA project. Furthermore, concerns were raised by COTA over the need for constant communication with bus operators, which could cause unnecessary distractions, and the potential for creating a domino effect and negative impact on running times by holding busses for individual travelers.

Purchase First Mile/Last Mile Tickets at Central Ohio Transit Agency Ticket Vending Machines

Early conceptualization of the proposed system included COTA TVMs integrated with an IVR system to allow Travelers to purchase FMLM trips. An IVR system will be addressed under the Smart Mobility Hubs project instead.




Chapter 5. Concept for the New System

The purpose of this section is to provide an overview of the proposed MMTPA/CPS system including its relationship with data sources, Mobility Providers, and related Smart Columbus projects. This section also includes the goals for the new system, modes of operation, classes of users, and interfaces with other systems. A description of key concepts and the rationale for decisions is included. In addition to the scope of the new system, connections to the other Smart Columbus applications are described in detail.

Background, Objectives and Scope

The USDOT’s Smart City Challenge, launched in December 2015, was designed to encourage mid-sized cities to develop ideas for an integrated smart transportation system that would use data, applications, and technology to help people and goods move more quickly, cheaply, and efficiently. As part of Columbus’s overall response to the Smart City Challenge, Mayor Ginther and other City leaders focused part of their efforts on how an integrated smart transportation system would encourage the use of multimodal trips. Increasingly, citizens in urban areas view mobility as a service, and expect seamless connections as they move from mode to mode. Motivation for the MMTPA/CPS project focused around this discussion, as well as gaps that are present in the current system, such as the lack of access to coordinated multimodal options for Columbus, ability to compare prices across modes, and integration with a CPS. The MMTPA/CPS will provide this functionality and improve upon the existing functionality that is available to users of the current system.

There are three main goals for the MMTPA/CPS with respect to positive societal outcomes, which tie back to the original intent of the Smart City Challenge:

1. Enhanced Mobility

2. Enhanced Access to Opportunities and Service

3. Increased Customer Satisfaction

These goals were developed through collaboration with USDOT and address the unique needs of the Columbus region. A description of each of the goals is provided below

Goal No.1: Enhanced Mobility

Enhanced mobility within the context of the Smart Columbus program means providing citizens with improved access to transportation services, which in turn leads to an improvement in quality of life and access to economic and educational opportunities. Within the context of the MMTPA/CPS, enhanced mobility means providing travelers with convenient access to different modes of transportation through a single mobile interface, ability to create personalized trip itineraries based on user-defined travel preferences, and ability to pay for all portions of a multimodal trip from a single convenient CPS account.




With increased mobility, a focus on promoting shared-ride services, and mode choice for residents in central Columbus, fewer people need to rely on SOVs as a necessity to move around. A reduction in single passenger vehicles by as little as 10 percent in the Columbus region (54,248 vehicles) over time will result in the following positive benefits to congestion and the environment (http://calculator.sharedusemobilitycenter.org):

559,023,400 fewer miles traveled by SOVs

200,600 fewer metric tons of GHG emissions related to personal vehicle ownership

$197,081,500 saved in personal vehicle transportation costs

Goal No. 2: Enhanced Access to Opportunities and Service

Providing opportunities for improved access to transportation is of central importance to Smart Columbus and the MMPTA/CPS project. This goal aims to increase access for underserved communities to a wide variety of services through transportation solutions focused on increasing access to places of employment, education, healthcare, and other services, as well as increasing the use of transportation networks by bringing available services and users together. Opportunity is created with the implementation of services that connect people with jobs and improved quality of life. The MMTPA/CPS will create opportunity by addressing barriers to multimodal transportation that travelers face when using systems that are not designed to be comprehensive. Door to door trip planning and payment will allow multimodal trips to reach areas of employment in a cost-effective manner that were not possible with just transit service alone.

Goal No. 3: Increased Customer Satisfaction

Smart Columbus will only be successful if it provides services that are useful, easy to use and embraced by the community. Smart Columbus will improve the user experience for citizens planning for, paying for and using transportation services through the integrated exchange of data and use of advanced technologies to help travelers reach their destinations. By implementing advanced technologies, such as providing a CPS or Smart Mobility Hubs, the products or services supplied by the City will meet or surpass a traveler’s expectation.

Objectives

The objectives of the MMTPA/CPS are to facilitate access to transportation options and to make multimodal trip planning and payment more convenient. The objectives listed in Table 10: Objectives of the Proposed System address barriers to multimodal trip planning and payments integration that the MMTPA/CPS can influence. The overarching hypothesis behind these objectives is that by making multimodal trip planning and payment easier, the MMTPA/CPS can provide travel options to residents and visitors to Columbus to reduce SOV trips and gain access to jobs and services.





Table 10: Objectives of the Proposed System

Objective Hypothesis

Facilitate improved access to multimodal trip planning information

The MMTPA/CPS will encourage travelers to use alternate modes of transportation in central Ohio by providing a comprehensive trip planning and payment solution.

Increase usage of the shared-ride transportation services being provided

The MMTPA/CPS will result in increased ridership of shared-ride transportation services by affording travelers access to comprehensive information about all the transportation service options at their disposal for trips and providing convenient FMLM options.

Improve ease of multimodal planning

The MMTPA/CPS will provide a user-friendly experience that allows and encourages users to schedule multimodal trips in central Ohio.

Provide travelers with more convenient access to transportation service options

The MMTPA/CPS will provide travelers with more convenient access to mobility services that were previously out of reach to unbanked or underbanked individuals or considered to be inconvenient due having to manage multiple accounts to pay for different transportation services.

Increase access to jobs and services

The MMTPA/CPS will provide better access to jobs and services by enabling travelers to use mobility services that were previously unavailable to them due to payment restrictions.

Increase customer satisfaction The MMTPA/CPS will increase customer satisfaction by providing one account to pay for multiple transportation services.

Note: The Smart Columbus Performance Measurement Plan includes additional information to meeting objectives such as indicators, methodology and timeframe.


Strategy

The strategy to realize these objectives is to co-develop the MMTPA solution with a vendor or developer through an agile development process to mitigate risks and to ensure the system architecture components are optimized to work together and provide high performance. The City and COTA plan to issue a request for proposal (RFP) to obtain an MMTPA solution from a private sector partner that addresses all six of the primary gaps in the current system that motivate the project (Table 6: Justification for Changes). This ConOps document will support the development of MMTPA functional requirements for a minimal viable product that can be detailed in an RFP. The City will continue to develop system requirements for the CPS solution while working with a partner to develop the MMTPA.

Operational Policies and Constraints

Table 11: Operational Policies and Constraints applies to the proposed system. Operational policies are predetermined decisions regarding the operations of each component or sub-component of the current system, typically in the form of general decisions or understandings that guide development and




decision-making activities. Operational policies will inform decisions made to integrate with the MMTPA/CPS. Operational constraints are limitations placed on the operations of the current system.

Table 11: Operational Policies and Constraints

Type Description

Constraint The MMPTA/CPS system must integrate with COTA’s new Fare System. It is necessary for COTA’s new Fare System vendor to develop modules for the Operating System and adhere to open data and open architecture design principles.

Constraint Mobility Providers must be willing to integrate with the Operating System through open standards and to accept the CPS as payment method.

Constraint Mobility Providers (especially TNCs) are reluctant to share trip data or allow cost comparison with potential competitor services. Not all Mobility Providers share APIs with third-party developers or support open standards and open data exchange. Currently, TNCs will only provide trip data (origin/destination) to public agencies that are subsidizing part of the trip. To address this constraint, the City and COTA plan to adopt a phased delivery approach with Mobility Providers who are early adopters. Additional Mobility Providers may be added to the system in later releases.

Policy The City/COTA wish to pursue a single smart card system to present a consistent vision and marketing strategy to the traveling public. COTA’s smart card should be the only branded smart card for Columbus; however, if COTA’s card does not meet the needs of the Smart Columbus program, the City will pursue a separate card with a financial institution.

Policy COTA is open to adopting a sustainable rewards and incentives program that will encourage ridership and adoption of the MMTPA/CPS. Rewards and incentives programs have been discussed in relation to the COTA Fare System upgrade but are not planned as part of the initial release.

Policy All Mobility Providers must be registered with the appropriate regulatory agency.

Policy The Operating System prefers to co-develop a solution with a vendor or developer to ensure that the system architecture components are optimized to work together and provide high performance.





Type Description

Policy The MMPTA/CPS system must adhere to the policies and technical requirements put forth by the Operating System team. Specifically, a developer must do the following:

Adhere to design and development methodologies for applications deployed in the Operating System’s Microservices environment. Externally built applications need to ensure portability and best practices for building and deploying Software as a Service (SaaS) applications for the web.

Package applications into a Docker Image to ensure version control, portability, isolation and security.

Validate the interoperability of their application with other Microservices and the Operating System core in a sandbox environment and inform the Operating System architectural team when promotion from the sandbox environment to production is ready, to follow production deployment procedures.

Provide the ability to monitor the microservice health and performance of externally built applications deployed to the Operating System Microservice environment to ensure health of the Microservices environment. The Developer needs to provide application production support for failure analysis and remediation commensurate to the contracted SLA to ensure proper operation of the Microservice environment.

Policy The City is not willing to take on the risks related to overages or lost/stolen/damaged equipment. The City is not willing to take on the risks of being a cardholder on file for any transportation service that requires a card on file.


Description of Proposed System

The MMPTA/CPS system is a complete multimodal trip planning and payment solution that provides a single source for multimodal trip planning and payment for all Travelers in the Columbus region. Travelers can download and install the MMTPA from public app stores and begin using it immediately to plan trips. Travelers will be required to create a CPS account to pay for trips.

Mobility Providers will integrate with the Operating System through APIs in order to be available to travelers in the MMTPA. Providers will be paid for services immediately or at a negotiated frequency (weekly or monthly) for all rides paid for using the MMTPA/CPS. Payment for services will be deducted immediately from Traveler's accounts and credited toward the appropriate Mobility Provider’s account. Travelers will also have the option of funding their CPS accounts on a fixed schedule or when the existing balances fall below a set threshold.

The Operating System is central to tying together many transportation services, by providing open architecture components that can be consumed by Mobility Providers to exchange information needed to optimize and schedule trips. The Operating System is envisioned to contain elements of COTA's fare




management system to be well integrated with transit and paratransit services. COTA, as the region's public transportation provider, is the natural organizational entity to bring all regional transportation services together.

The CPS serves as a back-office processor to facilitate payment between Travelers and Mobility Providers. The CPS is also responsible for alerting Travelers of authorization status (i.e., payment-accepted or payment-declined status).

Figure 7: MMTPA/CPS Proposed System Context Diagram provides an overview of components and interconnections in the proposed system. Reference to external systems or procedures are included if applicable. This section describes the capabilities, functions, and features of each major component. The MMPTA/CPS will be developed to optimize throughput, response time, and availability of all major system components.


Figure 7: MMTPA/CPS Proposed System Context Diagram





Operating System (Central System)

Third-party applications (or application components) that utilize Operating System datasets and input/output (I/O) environment will be housed in a microservices environment. The microservices environment will include processes for the ingestion of third-party applications into the environment that will allow for secure integration of applications that would otherwise be entirely separate systems to be hosted directly in the Operating System. Applications that are running in the environment will be modular components that can be created and decommissioned without impact on other parts of the system. The following are examples of microservices that will reside within the Operating System.

Operating System embedded functions

o As the entire system will be built using a service-oriented architecture, each succinct function utilized in the Operating System that is not monolithic in its makeup will be built within stand-alone containers able to be added or deleted as needed

Internet of Things/Vehicle to Infrastructure (IoT/V2I)

o Includes any number of streaming data conversion, monitoring, alarming or redirecting functions

Third-party applications

o Includes any number of applications from either a commercial, university or governmental entity

It is envisioned that trip optimization will be a third-party application developed and deployed into the Operating System microservices environment. As a microservice, it will be capable of being upgraded without affecting the functional logic of the MMTPA, thus allowing for continuous improvement of the environment Third-party applications and components will need to be evaluated on a case-by-case basis as to whether the Operating System will allow non-open-source applications to be deployed within the environment.

Trip Optimization

It is envisioned that trip optimization will be a third-party application developed and deployed into the Operating System microservices environment. As a microservice, it will be capable of being upgraded without affecting the functional logic of the MMTPA, thus allowing for continuous improvement of the environment. Third-party applications and components will need to be evaluated on a case-by-case basis as to whether the Operating System will allow non-open-source applications to be deployed within the environment.

Trip optimization will utilize an algorithm to optimize the trip to encourage ride sharing and determine if the deviation from adding a pick-up/drop-off is within an acceptable threshold. A fixed-route public transit leg of the trip will be included when reasonable for a given trip. Business rules for these trips will be established in requirements and design phases. The trips will be optimized based on real-time traffic data obtained by a third-party. As a baseline, a direct trip travel time will be calculated for each trip assuming no ride-sharing or transit leg is implemented.




For ride-sharing trips, every attempt will be made to fill up vehicles and use transit legs without unduly affecting the trip time for the passengers. However, federal subsidy requires shared-ride vehicles be used as much as possible. The estimated arrival time will be longer for accessible vehicles than normal vehicles if there are fewer available. To mitigate this outcome, algorithms will be adapted to encourage more use of accessible vehicles for general public trips and promoting these trips with paratransit and non-emergency medical transport vehicles in-between their primary service functions. If an accessible vehicle has been assigned to one customer, then any additional customer requests will attempt to be paired with that vehicle before looking for the next vehicle to encourage the availability of accessible vehicles.

Machine learning services in the Operating System may assist users in making connections based on frequent travel behavior. For example, travelers who make recurring trips using a single mode may be offered travel incentives to try another mode that helps meet the project goals.

Mobility Providers

Mobility Providers will interface directly with the Operating System to allow for trip optimization and respond to requests from the MMTPA. Initial implementation of interfaces will be through partnership with selected Mobility Providers to gain a critical mass of available vehicles. Subsequent relationships with other providers will be through a standard process that will be open to other mobility providers that meet program requirements.

Mobility Providers will interface with the Back-Office Processor to manage CPS merchant accounts and receive payment for services rendered through the MMTPA.

Data Services

The Operating System Service Layer will be comprised of open APIs and an API Builder, allowing for creation of customized data feeds. City of Columbus/COTA users and third-party users will have filtered access to MMTPA/CPS trip and anonymized payment data stored in the Operating System through APIs. Information pertaining to payment and system performance, such as how frequently the CPS is used to pay for trips or parking, will be transmitted to the Operating System for analysis and common data sharing with other applications in near real-time.

Trip and Payment Data

Trip and payment data generated by the MMTPA/CPS will reside in a “big data” environment within the Operating System that is comprised of data storage and data retrieval systems and functions. Trip and payment information will be collected into the Operating System in real time as generated and periodically archived to a historical database. Trip information will consist of at a minimum the following: origin, destination, trip start time, trip end time, mode, vehicle ID, transfer (including transfer time, transfer location, disembarked location, embarked location), payment initiated, payment amount, and payment complete. Trip activity related to each leg of a multimodal trip will be recorded and provided with a common reference for analytics. Additional data will be identified as needed to allow for robust analytics. Payment information collected in the Operating System will exclude financial data or credit/debit transaction data. All payment data will be anonymous by design, meaning that the data cannot be used to





identify any individual Traveler. Privacy as it relates to Traveler information and trip and payment data is described in Security and Privacy.

Payment Broker Service

Payment requests originating from the MMTPA will be handled by the Payment Broker. When a request for payment is initiated by the Traveler, the Payment Broker queries the Payment Processor for available funds. If there are insufficient funds, the Payment Broker will direct the Traveler to add funds. If funds are available for the requested trip, the Payment Broker will activate the trip and instruct the Payment Processer to credit the Mobility Provider’s CPS Account.

Common Payment System Back-Office

The CPS back-office will be responsible for back-office functions related to payment of all non-COTA trips. The CPS back-office and COTA back-office will share a common ledger of account information to prevent users from having to sign up and register payment products with more than one account. The CPS back-office will process functions related to managing CPS accounts, payment details, invoices, transactions, and reports.

The CPS back-office will serve as a payment processor for the MMTPA and other third-party applications, capable of handling one-to-one and one-to-many payments to Mobility Providers. For example, a Traveler using the MMTPA to pay for a multimodal travel itinerary will pay once for the total trip (all trip segments) and have the funds split for each Mobility Provider for each segment of the total trip.

The CPS back-office will be able to accept funds from Travelers and hold those funds in reserve for an indeterminate number of days before paying out the Mobility Providers. The Back-Office Processor will allow Travelers to register multiple forms of payment and to specify a default payment method to be used when paying for transportation services or parking services. Users will be able to set a preferred payment method and receive travel rewards for multimodal trips in the form of discounts and benefits.

Common Payment System Payment Processor/Gateway

The CPS payment processor will be responsible for authorizing pay requests and for deducting funds from the Traveler’s Account and crediting the Mobility Provider’s account. The payment processor will provide user-initiated account funding requests as well as batch funding of accounts based on account balances. Funding requests will be made for payment against user registered payment methods and passed to the payment gateway for authorization. The payment gateway carries out an authorization process on behalf of the CPS for the Mobility Provider (COTA, TNC, etc.). The cost of these transactions will be negotiated with the Mobility Provider as part of their rates.

The CPS payment gateway sends an authorization request to the issuing entity (Traveler’s bank or credit card) with the transaction details. It receives an authorization response whether the transaction was approved or denied. If approved, the funds are issued to the Mobility Providers through a payment settlement process. In addition to payments processing, the payment processor is responsible for funds remittance to the Travelers as needed.




The payment processor is responsible for refilling a Traveler’s CPS account when the balance falls below a preset threshold. Travelers will be responsible for funding their CPS accounts manually or through an automatic reload process. Transactions against the CPS account will occur immediately to support payment for services.

Cash payments may be possible at TVMs to reload a Traveler’s CPS account.

Common Payment System Accounts

Travelers will be prompted to create a CPS account when they initiate a payment from the MMTPA and do not have a CPS account. Travelers may either create an account or continue as a guest by creating a guest account. A guest account will allow the Traveler to make a one-time payment, but the payment information will not be stored, and the account will not be permanent. To create a CPS account, Travelers will be required to register at least one payment method. Travelers may register different payment media and assign a default payment option. Travelers may link to an existing COTA account or a COTA Smart Card account. When creating a CPS account from the MMTPA, Travelers will be asked if they want to save their CPS login information with the MMTPA.

Table 12: Common Payment System Accounts – Traveler describes the main components the Traveler’s CPS account must contain.

Table 12: Common Payment System Accounts – Traveler

Sub-Component Description

Create an Account Travelers will have the option of creating a CPS account to conveniently pay for all transportation. When creating an account Travelers will be asked for contact information and payment information, both of which are required. Accounts will maintain a balance so that transactions can be implemented quickly without having to enter payment information when using the MMTPA to book trips. Accounts can be funded from automatic withdrawals from credit or debit cards when balance falls below a specified dollar amount.

Setup Auto-Fill and Service Alerts Auto-fill is an option to refresh a CPS account once it falls below a certain threshold. Travelers will have the option of receiving service alerts when their account is below a certain threshold.

Query and view transactions; Export

Ability to view all transactions through the system. If reward or financial incentives are earned for completing multimodal trips, or through other promotion, these rewards or incentives will be viewable here.

Manage Personal Information Ability to update and maintain contact information associated with the account. (CPS personal information will be separate from the MMTPA preferences information used for trip planning).






Manage Payment Products Ability to add or remove payment products registered on the account. Accounts will support funding with COTA Smart Cards, Visa, Master Card, and American Express credit or debit cards and other authorized payment sources.

Request Help Ability to submit a help request.

Request Password Reset Ability to request a password reset.


Mobility Providers will be required to establish merchant accounts in the CPS to receive payment in exchange for services offered through the MMTPA. Table 13: Common Payment System Accounts – Merchant includes the sub-components and activities that the Merchant accounts will include.

Table 13: Common Payment System Accounts – Merchant


Manage Account Info Mobility Providers will have the ability to manage their own contact and billing information through a secure login. Accounts will be maintained in the CPS vendor back-office and allow authorized users from the City/COTA to create the accounts.

Manage Reports Mobility Providers will have the ability to view all transactions through the system and detailed trip reports. Reports will be exportable in comma delimited format.

Manage Invoices Ability to query and view invoices.

Recover password Ability to request a password reset.


Central Ohio Transit Agency Fare Management System

Refer to Central Ohio Transit Agency Fare System Redesign for information on COTA’s Fare Management system.

Mobility Provider Systems

There are several different formats of Mobility Providers that will require slightly different APIs. These include fixed-route Mobility Providers like COTA and CEAV; on-demand Mobility Providers such as taxis and TNCs; shared vehicle services like car-sharing and bike-sharing companies; and ride matching services like carpools and vanpools. It is also envisioned that the parking providers for lots, garages, and on-street parking will use the CPS at a later time.




Fixed-Route Mobility Providers

Fixed-route systems provided by COTA and CEAV will provide standard General Transit Feed Specification (GTFS) and GTFS-R (real-time). COTA will provide real-time vehicle location data from its bus AVL system, which will be ingested in real-time into the Operating System and archived for use in analytics and performance metrics. This data is available in real-time GTFS format on external hosted sites. Real-time access to this data can be made directly to the COTA servers, but historical data from these sources will be required for evaluation and performance monitoring.

On-Demand Mobility Providers

Taxis and TNCs will provide an API that allows the following parameters to be passed to the Operating System for trip optimization:

Trip origin and destination

Number of travelers

Specify ride-sharing trip

Arrival window

CPS business account number

The API will return:

The available vehicles within the arrival window

The license plate of the reserved vehicle

Driver’s first name

Driver’s phone number

Vehicle lat/long

Real-time traffic-based ETA to origin of trip (will be confirmed by trip optimization microservice)

Real estimated cost valid for 5 minutes

o Base cost

o Per mile cost

o Time cost per minute

o Current surge charges

Vehicle may be reserved. If reserved:

o Selected vehicle will be dispatched once they confirm

o If they do not confirm in a specified timeframe, then another vehicle will be selected

o Trips can be canceled per the terms of the Mobility Provider

o Status updates will be sent at 30 second increments from the driver accepting the pick up until arrival at destination





o After arrival the Traveler’s CPS account will be charged for the real cost incurred based on rates above. Shared ride portions will be identified, but not double billed.

Shared Vehicle Providers

Car and bike-sharing providers will provide APIs consistent with the General Bikeshare Feed Specification (GBFS).3 Car and bike-sharing providers are similar enough that there could be some modification required but not a major change. All fields in the GBFS should be included, including those marked “Optional.”

The actual payment for the trip shall be a separate process that is initiated by the MMTPA and exchanges:

Space ID and/or location of car/bike at station

Description of vehicle/bike (color, make, model, color, plate ID, etc.)

Code to access vehicle/bike and activation method (NFC, QR, smart card, keypad entry, etc.)

Rates charged will be processed periodically (monthly, weekly) in the business account

Columbus will certify the users with agreed upon process (Credit card hold or registered user at customer service location with government ID for unbanked users)

Ride-Sharing Providers

Ride-sharing providers (car/van pooling) will provide APIs capable of connecting drivers who want to share their vehicles for commuting, and passengers who are looking to ride with others in exchange for split costs. Trip optimization will consist of two primary functions, 1) matching drivers and passengers to develop a team, and 2) determining the scheduling and order in which the driver needs to pick up all members of the team. Further, the total number of passengers cannot exceed the capacity of the driver’s vehicle, and the route must originate with the driver's specified location and terminate and the driver's specified location.

Transaction Equipment

Transaction equipment consists of smartphones and a traveler web portal, COTA fareboxes and readers, and an IVR system (touch-tone phone) to support trip planning and payment for Travelers without access to smartphones or computers.

3 https://github.com/NABSA/gbfs/blob/master/gbfs.md




Traveler Web Portal

Travelers will be able to access and manage their CPS accounts through a web portal, as well as perform trip planning functions associated with the MMTPA.

Central Ohio Transit Agency Ticket Vending Machine

COTA TVMs will allow cash to be loaded onto an existing COTA smart card to facilitate Travelers who may be unbanked or prefer to use cash. The number of TVMs that allow conversion of cash to credit will be limited. Title VI requirements will be met by allowing unbanked passengers to use cash to pre-purchase trips from TVMs or enter prepaid debit card or smart card information instead of credit or debit cards.

Central Ohio Transit Agency Farebox

Travelers who have purchased a COTA trip segment(s) will have access to an optical QR code (mobile e-ticket) on the MMTPA which can be activated at COTA fareboxes. Activating an e-ticket will cause the ticket to expire from the Travelers account. If the Traveler’s mobile device is NFC enabled, and compliant with ISO 18092/ISO 21481, the device will broadcast the same unique serial number that is encoded in the QR code. A description of COTA’s farebox technology is provided in Central Ohio Transit Agency Fare System Redesign.

Smart Mobility Hubs

Smart Mobility Hubs will be provided at fixed locations with a wide range of multimodal service features available at those locations. Most locations will include a free-standing kiosk that will have a tablet-sized touch screen that provides a user interface with the functionality of MMTPA/CPS, but it will be oriented for a tablet touch-screen interaction. For more information refer to the Smart Mobility Hubs ConOps.

Interactive Voice Response System

An Interactive Voice Response (IVR) system will allow passengers without access to a smartphone to initiate ride-sharing trips using only a touch-tone phone. Travelers will be able to dial the IVR phone number provided and request pick-up by entering a Trip ID code which can be generated at kiosks at Smart Mobility Hubs, or from the Traveler Web Portal. The Trip ID will have the pick-up and drop-off locations identified when the trip was created.

Multimodal Trip Planning App

The MMTPA is a native mobile app deployed to both iOS and Android devices. The MMTPA is supported by a back-office infrastructure provided by the Operating System which collects, stores, and aggregates the data from multiple Mobility Providers via APIs to calculate routes and provide trip planning services to Travelers. The Operating System also provides integration with the CPS for handling payment requests on behalf of Travelers and Mobility Providers.





Travelers download the MMTPA to internet-connected mobile devices from a public app store. Operational data associated with the MMTPA is accessed through a cloud-based infrastructure, as well as cached locally on a device for offline use. The MMTPA will have access to the smartphone’s Global Positioning System (GPS) location information and may also require access to other on-device features such as locomotion and sound (for alerts and push notifications). The MMTPA will not require a web-browser to operate on mobile devices. It is assumed that “rides near me” functionality will be included as part of the MMTPA solution platform if it already exists, but the focus of the MMTPA is on trip planning functionality as described in this ConOps.

The MMTPA will have the ability to display e-tickets on screen for presentation and validation and/or by optical scanning at the farebox or reader equipment. COTA purchases through the CPS will generate an e-ticket that is available within the MMTPA. E-tickets will be generated by COTA's Fare System and transmitted via the MMTPA to the Traveler, where they can be activated at fareboxes or readers. COTA’s Fare System may also be responsible for generating barcodes that are used to unlock car-share vehicles and transmitted to the Traveler in the same manner as COTA fare media. To perform a validation transaction, the Traveler will be required to represent the fare media to the reader.

Interface with Operating System

The MMTPA will interface directly with the Operating System to send and receive trip planning information. Travelers will pass location information, such as origin and destination, as well as preferences to determine how results should be weighted and returned to the user in response. Travelers will also interface with the Operating System when selecting the option to “Pay Once” for multimodal trips. The payment request will be routed through the Operating System to the CPS where it will be handled appropriate to each mode of travel.

Interface with Transaction Equipment

Electronic tickets that have been purchased using the MMTPA and are available for use within the app will be activated at COTA fareboxes.

User Preferences

The MMTPA will store user preferences to eliminate unwanted trip results. Users preferences that can be selected by the users for the various Mobility Providers are defined in Table 14: Selectable User Preferences by Mobility Providers.

Table 14: Selectable User Preferences by Mobility Providers

Preferences On-Demand Fixed-Route Car-Share

Bike-Share

Car/ Vanpool Walking

Mode preference X X X X X X

Car preference X X X

Max price X X X

Max trip duration X X X X X X




Preferences On-Demand Fixed-Route Car-Share

Bike-Share

Car/ Vanpool Walking

Walking distance X X X X X X

Cheapest or quickest

X X X X X X

Accessible Vehicle

X X X

Environmental impact or “greenest” trip

X X

Dedicated bike lane

X


Incentives/Rewards

Travelers may receive incentives and rewards for qualifying multimodal trips that are linked to their CPS account. Travel incentives may include credit toward different modes based on user preferences, or gift cards for local businesses based on existing travel patterns. Through integration with the Operating System, machine learning will assist users in finding incentives based on existing travel behavior. For example, travelers who make recurring trips using a single mode may be offered travel incentives to try a different mode that helps reduce congestion, or qualifies for discounts, or helps to promote a local business. Travelers may also qualify for rewards and incentives by demonstrating change in travel behavior, such as switching from single-occupancy vehicles to carpool. Incentives will be tied to the Traveler's CPS account and viewable as transactions. For example, multimodal transportation in the Short North of Columbus may qualify for a promotion in that area for discounted rides on a TNC or Taxi service. The Traveler's CPS account will show a promotion code in the list of transactions that may be applied to activate the discount.

Gamification may also be used to incentivize multimodal trips. Gamification is the use of game theory and game mechanics in a mobile app to encourage user adoption of the app and often to promote a certain type of behavior, such as rewards for transitioning away from single-occupancy vehicles to carpooling. It seeks to leverage aspects of social media and online competition to reward travel behavior. The MMTPA may include gamification to encourage multimodal travel behavior, in addition to financial rewards and incentives through a Traveler’s CPS account.

Modes of Operation for the Proposed System

The modes of operation for the MMTPA/CPS are defined in Table 15: Modes of Operation for the Proposed System. The MMTPA/CPS will include alert processes to make sure the problems are identified quickly, and the cause of the alert can be easily analyzed. Watchdog processes, used to detect and report failure or anomalies, will reside on separate servers from the process being analyzed.





Table 15: Modes of Operation for the Proposed System

Mode Definition

Operational (regular) Normal operating condition, the system is operating as designed and all processes are running as intended. The system is intended to function during all hours of the day. Watchdog processes are not activated when MMTPA/CPS data are within expected parameters.

Degraded Conditions Represents a situation where primary functionality is lost due to nonfunctioning process or equipment, but an alternative (though less precise) means of accomplishing the function exists. This could be from back-up servers or processes.

Failure Conditions Represents a situation where the application is not operating as designed and processes are not performing as intended. This could be from diminished communications between one or more external systems, diminished data quality, or the inability to process data in a timely manner. Failure conditions include situations that require temporary shutdown of the system. Watchdog processes will provide alerts for these failure conditions.

Diminished Communications Loss of Communication with Mobility Provider(s) – Loss of communications between MMTPA/CPS Back-Office and Mobility Providers or application users. Loss of COTA GTFS resulting in loss of real-time location information.

Loss of Communications with Operating System – Loss of communications between the MMPTA and the Operating System preventing transfer of data. Heartbeats will monitor the connection.

Deficient Data Quality Inaccurate Data – Inaccurate real-time vehicle location, cost and availability from Mobility Providers. The application depends on the accuracy of this information to effectively plan routes, make connections, switch modes, and determine if services are running late. Inaccurate service data will greatly reduce the system’s effectiveness. Actual trip data will be compared to estimates to determine data quality from each source.

Inability to Process Data in a Timely Manner – the amount of data requested to be processed in the MMTPA/CPS Back-Office is greater than its processing capability, resulting in delays and/or unacceptable performance.

System Health Monitoring API Monitoring – Diagnostic health monitoring processes to ensure proper communication with Mobility Providers. Failure messages from these processes will alert required personal.

Process monitoring – Diagnostic health monitoring processes to determine that Back-Office processes are running as intended.

Maintenance Condition in which equipment and/or systems are under repair or preventative maintenance.




Mode Definition

Offline Offline mode describes a situation where internet connection is lost and the application is unable to retrieve real-time updates or operate as intended.


User Classes and Other Involved Personnel

A user class is distinguished by the ways in which users interact with the System. The System is comprised of all components and subcomponents that make up the MMTPA/CPS, providing Travelers with the ability to plan and pay for multimodal transportation and parking services using a common payment account. Factors that distinguish a user class include common responsibilities, skill levels, work activities, and modes of interaction with the system. Different user classes may have distinct operational scenarios for their interactions with the System.





Table 16: Proposed System Users describes the user class of the proposed System.




Table 16: Proposed System Users

User Classes Definition

Travelers Travelers are end-users of the System (residents and visitors of Columbus) who interact with the System to plan and pay for multimodal trips and parking services in the defined service area (Geographic Scope).

City of Columbus (Facilitator) The City is responsible for developing needs and requirements for the MMTPA/CPS system, and for deciding the policies and rules necessary to meet the goals and objectives of the overall Smart Columbus program. The City is responsible for establishing equal partnership with COTA and for transferring the MMTPA/CPS system to COTA once design, development, and implementation is complete.

The City is comprised of governmental staff with access to performance and usage information through integration with the Operating System. These users will have access to reports and performance measurement data to make informed decisions regarding future improvements to the MMTPA/CPS system and to support broader transportation policy decisions.

The City is comprised of staff within the following departments as well as others: Department of Technology (DoT) and Department of Public Service employees.

City is responsible for ensuring the CPS meets the goals and objectives of the Fare System upgrade and seamlessly integrates with any additional third-party applications identified during the design phase of the project. It is anticipated the City will hand-over ownership of the CPS to a non-governmental organization (NGO).

COTA (Owner) COTA will assume ownership of the MMTPA during the life of the grant and will be responsible for the control of standards, regulations, and agreements between all stakeholders of the system.






Operating System The Operating System is the data platform at the heart of the Smart Columbus data environment. The Operating System is responsible for integrating data and data services from Mobility Providers, including Smart Columbus projects, traditional transportation data, and data from other community partners. The Operating System is responsible for trip optimization to support multimodal transportation planning in the MMTPA. The Operating System is also responsible for integrating with the CPS to broker payment requests between the MMTPA and CPS but is not responsible for storing PII or financial data. The Operating System will store trip and payment data (non-PII) to support analytics and performance measures by the City of Columbus and third-parties.

The Operating System will be responsible for providing tools to allow City of Columbus/COTA users and third-party users to query and report on trip and payment data generated by the MMTPA/CPS System.

The Operating System will be operated by the Smart Columbus Program Management Office (PMO). The PMO will continually monitor the operational performance and consider adjustments to the various systems to ensure that they are operating as expected. Further, the City will ensure that all performance measures and data required for an Independent Evaluator, and overall monitoring of the system, are being collected as documented and as required.

Mobility Providers Mobility Providers are companies that provide transportation services to Travelers. These companies provide vehicle route, location, schedule, availability, and fare data to the System through integration with the Operating System. Mobility Providers have the responsibility of access control on their vehicles and services. Mobility Providers include public transit (COTA), TNCs, car-sharing, bike-sharing, taxi/limo (Mobility Providers).

Payment Processor The Payment Processor interacts with the Operating System to facilitate payment requests from the Travelers. The Payment Processor facilitates clearing and settlement of transactions and may assist with fare calculation in the event of rules being applied for pricing. The Payment Processor interacts with various payment gateways which in turn interact with banks and credit card companies to pay the Mobility Providers and Parking Providers for services.

The Payment Processor interacts with banks and credit card companies serving as a payment agent to facilitate financial transactions between Travelers and Mobility Providers.





Certification and Accreditation Provider

The Certification and Accreditation role is intended to maintain the system quality, security, safety, and “openness” of the System. The Certification and Accreditation role should be fulfilled by a “vendor neutral” entity and/or by the Vendor’s own self-certification process, by providing the proper tooling and access to system information.

Third-Party Users Third-party users are members of the public, including researchers and entrepreneurs, with limited access to data that is generated by the CPS for development purposes. Third-party users access information through integration with the Operating System.


Support Environment

The MMTPA/CPS system is expected to be supported by an expansion of responsibilities of operations and maintenance staff of the Columbus Department of Technology, COTA, and the solution providers that holds maintenance and service contracts with Columbus.

The solution providers will design, test, integrate, operate, and maintain one or more aspects of the MMTPA/CPS system. These private companies will be under contract with Columbus and be responsible for providing a pre-determined level of maintenance and support in accordance with the terms of the contract. It is anticipated that the maintenance contract will include continuous agile development to update the user experience as needs are identified.

The Smart Columbus PMO will be responsible for monitoring public usage of the MMTPA/CPS system using analytics available through integration with the Operating System, to make informed decisions regarding future improvements to the application and to support broader transportation policy decisions. The PMO will be responsible for maintaining the real-time data feeds and other microservices in the Operating System, and for the operational and archived data in the system. The PMO will be responsible for controlling access to the system data and processes, and for maintaining system security.

Security and Privacy

The MMTPA/CPS system will be developed in accordance with best practices in data security and privacy. Data security refers to the tools, policies, practices, and procedures used to protect data from being accessed, manipulated or destroyed or being leveraged by those with a malicious intent or who are unauthorized to do so. Further, data security encompasses the corrective actions taken when data breaches are suspected or have been identified. Data privacy is the reasonable expectation that data of a sensitive nature will be kept confidential, sanitized and/or encrypted, and respectfully and responsibly maintained by all users, managers, and collectors of the data while adhering to applicable laws and regulations, policies, and procedures. Detailed system security as it pertains to the MMTPA/CPS system will be documented in the Data Management Plan.





Payment Card Industry Compliance

The exchange of electronic payment information is subject to PCI DSS, which defines the level of encryption and protocols that must be adhered to when information is exchanged over a wired or wireless network. The operator of the CPS must be PCI certified to ensure the security of fare transaction information that is exchanged. PCI compliance is a necessity regardless of the fare medium or fare collection technology that is deployed.

The CPS will collect financial information from users in the form of payment methods (valid credit card number, type, expiration date or other financial information); that information will be stored in the CPS User account for use by the Payment Processor. As such the CPS will be subject to PCI Data Security Standards (PCI DSS). Current PCI DSS documents can be found on the PCI Security Standards Council Website (refer to https://www.pcisecuritystandards.org/security_standards/documents.php).

The Operator of the CPS will be responsible for meeting PCI DSS requirements. Payment methods that are in-scope for PCI include any credit, debit, and prepaid cards. Use of Secure Sockets Layer (SSL) certificates to encrypt the transmission of payment information does not alone constitute compliance with PCI DSS. It is expected that the CPS developer will utilize a secure credit card vault and other necessary controls in place to ensure that payment information is kept safe.

The CPS may be considered both a payment application and a payment gateway for PCI compliance in that it is directly involved in the processing, storage, and transmission or cardholder data electronically, as well as taking inputs from MMTPA and other Smart Columbus apps to route payment requests to the appropriate banks or processors for payment. Mobility Providers are “merchants” for PCI compliance, in that they are entities which accept payment for services.

Security vulnerabilities in systems and applications may allow criminals to access personal account numbers and other cardholder data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches, which provide repair for a specific piece of programming code. All critical systems must have the most recently released software patches to prevent exploitation. Entities should apply patches to less-critical systems as soon as possible, based on a risk-based vulnerability management program. Secure coding practices for developing applications, change control procedures and other secure software development practices should always be followed.

Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Deploy critical patches within a month of release.

Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities. Risk rankings should be based on industry best practices and guidelines.

Develop software applications (internal and external and including web-based administrative access) in accordance with PCI DSS and based on industry best practices. Incorporate information security throughout the software development life cycle.

Follow change control processes and procedures for all changes to system components.

Develop applications based on secure coding guidelines and review custom application code to identify coding vulnerabilities. Follow up-to-date industry best practices to identify and manage vulnerabilities.




Ensure all public-facing web applications are protected against known attacks, either by performing code vulnerability reviews at least annually or by installing a web application firewall in front of public-facing web applications.

Personally Identifiable Information

The issue of PII security and management is critical to the CPS. The necessity to maintain data security across all components of the system is crucial its success, and so protecting the PII of travelers needs to be a key priority.

The Traveler may wish to create an account within the MMTPA to store preferences that could simplify planning subsequent multimodal trips. Account information may include user name, e-mail address, work address, school address, home address, the address of other frequented destinations, and need for accessible vehicle. The Traveler may also allow the MMTPA to know his or her current location to simplify entering their origin when planning a multimodal trip. Requirements for storing PII in the MMTPA will be addressed in subsequent requirements documentation. Traveler account information will not be distributed outside of the MMTPA. The MMTPA will utilize industry standard security mechanisms to protect the account information and the Traveler’s privacy. Account information cannot be accessed or utilized without the Traveler’s authorization.

To book a trip, Travelers will link their CPS account to their MMTPA user account with the option to remember the CPS password. The MMTPA will use the CPS account to authenticate and authorize payments to Mobility Providers utilized for multimodal trips. This information will not be stored within the MMTPA to protect the Traveler’s privacy. Account information cannot be accessed, utilized, or distributed without the Traveler’s authorization.

Trip Activity Summaries generated by the MMTPA are sent to the Operating System for performance measurement and usage monitoring, and they will not contain Traveler’s MMTPA account information or CPS account information but may contain user statistical data. These summaries will not identify individual travelers. While the City of Columbus may have access to Origin/Destination (O/D) information for internal use and federal reporting, access to this data by third-parties will be spatially anonymized to hide O/D.

Trip and payment data that is stored in the Operating System will be anonymized before releasing it to third parties for analysis. It may also be necessary to introduce some level of error in the data to prevent third parties from identifying users by analysis of repeated trips (e.g. daily commutes to/from the same address).

Operating System Security

The Operating System approach to security is to make sure that security is designed into applications, infrastructure and processes. The following standards provide guidance for that approach: the CIS standards CISecurity.org, The Open Web Application Security Project (OWASP) standards OWASP.org and the concepts of security in depth espoused by MIT. The OWASP framework is the most appropriate and recognizable reference point. http://owasp.org. Specifically, the "OWASP Proactive Controls" is a superb resource written by developers for developers (refer to https://www.owasp.org/index.php/OWASP_Proactive_Controls).





The Operating System approach to security strategy aligns with OWASP's Top 10 Proactive Controls. Throughout our software development lifecycle, we will implement these safeguards within our code:

Define Security Requirements

Leverage Security Frameworks and Libraries

Secure Database Access

Encode and Escape Data

Validate All Inputs

Implement Digital Identity

Enforce Access Controls

Protect Data Everywhere

Implement Security Logging and Monitoring

Handle All Errors and Exceptions




Chapter 6. Operational Scenarios

This section presents scenarios that capture how the system serves the needs of users when the system is operating under various modes of operation. The scenarios are grouped into use cases, which correspond to the proposed system. Scenarios for each use case describe various modes of operations that are expected: normal operating conditions and degraded and/or failure conditions, as necessary. Each use case is accompanied by a process diagram that represents the exchange of information between actors, devices, and systems.

The following operational scenarios are included in this section:

Table 17: UC1-S1: Traveler Installs and Launches the MMTPA

Table 18: UC2-S1: Traveler Adds User Preferences to the MMTPA

Table 19: UC3-S1: Traveler Gathers Information for a Multimodal Trip

Table 20: UC4-S1: Traveler Executes a Multimodal Trip (Fixed-Route and Bike-Share)

Table 21: UC4-S2: Failure Condition – Bike Not Available at Docking Station

Table 22: UC4-S3: Failure Condition – Loss of Communications

Table 23: UC5-S1: Traveler Without Smartphone Uses IVR System to Activate FMLM Trip

Table 24: UC6-S1: Traveler Creates a CPS Account

Table 25: UC6-S2: Traveler Registers a New Payment Method and Enables Auto-Fill and Automated Alerts

Table 26: UC6-S3: Traveler Updates CPS Account to Qualify for Accessibility Services for ADA-Compliant Trip Segments

Table 27: UC6-S4: Traveler Recovers Lost CPS Password

Table 28: UC6-S5: Traveler Closes CPS Account

Table 29: UC6-S6: Traveler Pays for a Trip Using a CPS Guest Account

Table 30: UC7-S1: Mobility Provider Establishes an Account in the Operating System

Table 31: UC8-S1: Mobility Provider Manages CPS Account

Table 32: UC9-S1: City of Columbus User Retrieves Data from Operating System

Table 33: UC9-S2: Third-Party User Retrieves Data from Operating System




Connect to App Store; search for MMTPA; review

features

Traveler

Initiate Download

Yes

No

Install?

End

Launch MMTPA?

No

Continue to use app

Yes


Figure 8: Traveler Installs and Launches the MMTPA

Table 17: UC1-S1: Traveler Installs and Launches the MMTPA

Use Case Traveler Installs and Launches the MMTPA

Scenario ID & Title

UC1-S1: Traveler Installs and Launches the MMTPA

Scenario Objective

Traveler connects to a public app store to download and try the app

Operational Event(s)

Install MMTPA, launch MMTPA

Actor(s) Actor Role

Traveler Application user; end user of the system

MMTPA Multimodal Trip Planning Application

App Store Public app store providing the ability to download and install the MMTPA

Pre-conditions Traveler is connected to the Internet MMTPA is available for installation through a public app store Traveler has not yet set up a CPS account

Key Actions and Flow of Events

Actor Step Key Action Comments

Traveler 1 Connects to public app store and searches for Columbus MMTPA.

Traveler has an Android phone and connects to the Google Play store. Travelers who have Apple phones would connect to the iOS App store.

App store 2 Displays list of search results.

Traveler 3 Selects MMTPA from list of search results.

App Store 4 Displays MMTPA landing page with short description of app and

Experience may vary depending






links to “Read More.” Also displayed are User Reviews, ability to “Rate this App”, and option to Install.

on which App Store is required based on device type.

Traveler 5 Clicks on the Install button and proceeds to install the app onto his/her device. When complete, the traveler is prompted to open the app.

MMTPA 6 Displays a brief loading page and Terms and Conditions for use.

Regardless of device type, experience is the same for all smartphones.

Traveler 7 Accepts the Terms and Conditions.

MMTPA 8 Displays a map centered on the Travelers location in Columbus. The Traveler is prompted to enter a destination to begin using the app, or click on a link for basic instructions.

Traveler 9 Clicks on the link and reviews helpful instructions for navigating the app. Next, the Traveler clicks a link to return to the main interface to begin planning a trip.

Traveler also has access to educational material outside of the app, such as links to educational material pertaining to each mode of service.

MMTPA 10 Displays a map and prompts the Traveler for a destination.

Post-Conditions The MMTPA is installed and the Traveler has received basic instructions in how to navigate the app and set up a CPS account.

Policies and Business Rules

The MMTPA is available on both Android and iOS devices

User Needs Traceability

MMTPA/CPS-UN002-v02 Personal Devices MMTPA/CPS-UN007-v02 Access to Instructions and Educational Material MMTPA/CPS-UN012-v02 Graphical User Interface

Inputs Summary N/A





Output Summary

N/A



Figure 9: Traveler Adds User Preferences to the MMTPA

Table 18: UC2-S1: Traveler Adds User Preferences to the MMTPA

Use Case Traveler Adds User Preferences to the MMTPA

Scenario ID & Title

UC2-S1: Traveler Adds User Preferences to the MMTPA

Scenario Objective

Traveler adds user preferences to the app to customize the search results based on those preferences


Add preferences

Actor(s) Actor Role


MMTPA Provides trip results to the Traveler; stores preferences

Operating System Provides trip optimization and results to the MMTPA

Pre-conditions Traveler has downloaded and installed the MMTPA Traveler’s mobile device has GPS capabilities Traveler has not yet set up a CPS account








Traveler 1 Opens the MMTPA to plan a route.

Log in or creating a CPS account is not a required to perform trip planning.

MMTPA 2 Displays a map image and prompts the Traveler for origin and destination.

Traveler 3 Selects current location as origin (using GPS) and enters his/her work address as the destination.

Operating System 4 The Operating System performs trip optimization using the Traveler’s origin and destination and returns a list of trip options to the MMTPA.

MMTPA 5 Displays the list of trip options by travel time in ascending order (quickest route first) by default.

Traveler 6 Reviews the list by tapping on each trip to preview on the map. Next, the Traveler decides to enter preferences to narrow the list of results. To enter preferences, the Traveler clicks on the “Configure” button.

MMTPA 7 Displays a list of modes available. For each mode, there are different options such as car preference, max. trip duration, walking distance, or child safety seat. Options vary by mode, indicating that not all choices are available for all providers. Included is the ability to turn a mode on or off, which will prevent it from being considered in trip optimization.

Non-ambulatory Paratransit riders or others may request an accessible vehicle as their preference. Each leg of the trip will be required to meet this requirement.

Traveler 8 The Traveler decides to set a max. walking distance of 0.5 miles, and a max. total trip duration of 45 minutes. The Traveler also registers a preference for lowest cost trips.

The app is configured with default settings. Users are not required to set





preferences to use the app.

MMTPA 9 Stores the user’s settings automatically as they are entered.

Operational data associated with the MMTPA will be accessed through a cloud-based infrastructure, as well as cached locally on a device for offline use.

Traveler 10 Clicks a link to return to the main screen.

Operating System 11 Automatically adjusts the trip results based on the Traveler’s saved preferences.

MMTPA 12 Displays a new list of trip options sorted by cost in ascending order (from least expensive to most expensive) under the total trip duration of 45 minutes.

Traveler 13 Selects the trip that best meets preferences.

Post-Conditions Traveler has added user preferences to the MMTPA and is able to create personalized trip itineraries


User preferences are included in trip optimization by the Operating System


MMTPA/CPS-UN003-v02 Compare Trip Itineraries MMTPA/CPS-UN004-v02 User Preferences MMTPA/CPS-UN014-v02 Offline Usage MMTPA/CPS-UN017-v02 Same-Day Paratransit Service MMTPA/CPS-UN024-v02 Subsidization

Inputs Summary User preferences

Output Summary

Personalized trip itineraries







Figure 10: UC3-S1, UC3-S2, UC3-S3: Traveler Gathers Information for a Multimodal Trip

Table 19: UC3-S1: Traveler Gathers Information for a Multimodal Trip


Scenario ID & Title

UC3-S1: Normal Operating Conditions

Scenario Objective

Traveler gathers information on possible combinations of trip segments to take them from home to work


Trip optimization, real-time updates, notifications

Actor(s) Actor Role


MMTPA Provides trip results to the Traveler; display results

Operating System Provides trip optimization and results to the MMTPA

Mobility Providers Provide information on pricing, location, and availability, and schedule to the Operating System

Pre-conditions Mobility Providers have entered into agreements with Smart Columbus and are sharing data through the Operating System

The Operating System is providing trip optimization services for the MMTPA



MMTPA 1 Prompts the Traveler for origin and destination address.





Traveler 2 Enters origin and destination to begin planning a trip.

Operating System 3 Interacts with Mobility Providers for real-time pricing, location, schedule, and availability information.

Requests and responses are handled via the Operating System.

MMTPA 4 Displays trip options from the Operating System according to user preferences.

Includes accessible vehicle if needed.

Traveler 5 Selects a route which includes fixed-route bus, TNC, and walking.

Subsidies will only apply to some options based on business rules established.

Mobility Providers 6 TNC provides updated information based on surge pricing (increase in price due to excessive demand).

MMTPA 7 Automatically updates display to include change in price due to surge pricing.

Traveler 8 Selects a different trip based on updated information.

Traveler 9 Prepares to reserve and book the trip using the CPS.

Post-Conditions Traveler has adjusted trip selection based on changes in price.


N/A


MMTPA/CPS-UN001-v02 Real-Time Travel Information MMTPA/CPS-UN003-v02 Compare Trip Itineraries MMTPA/CPS-UN008-v02 Notifications and Alerts MMTPA/CPS-UN015-v02 Trip Optimization MMTPA/CPS-UN017-v02 Same-Day Paratransit Service MMTPA/CPS-UN024-v02 Subsidization

Inputs Summary Traveler provides origin and destination information, Mobility Providers provide pricing, location, and availability data

Output Summary

MMTPA provides pricing, location, and availability data







Figure 11: UC4-S1: Traveler Executes a Multimodal Trip (Fixed-Route and Bike-Share)

Table 20: UC4-S1: Traveler Executes a Multimodal Trip (Fixed-Route and Bike-Share)

Use Case Traveler Executes a Multimodal Trip (Fixed-Route and Bike-Share)

Scenario ID & Title

UC4-S1: Traveler Executes a Multimodal Trip (Fixed-Route and Bike-Share)

Scenario Objective

Traveler executes a multimodal trip involving fixed-route bus service and bike-sharing segments


Pay once for both trip segments, authenticate at reader

Actor(s) Actor Role


MMTPA Provides trip planning services

CPS Payment processor

Operating System Provides trip optimization and interacts with CPS

Bike-Share Provides bike at docking station; unlocks bike

COTA Fixed-route bus service; validates ticket at farebox





Pre-conditions Traveler is using the MMTPA to pay for a multimodal trip involving both bike-sharing and transit



Traveler 1 Selects “Pay Now” on the selected trip involving fixed-route bus service and bike-share trip segments.

Operating System 2 Payment request for each mode is routed through the Operating System.

Subsidies will be based on use of ride-sharing and transit when available.

CPS 3 For the COTA trip segment, the CPS checks available funds in the Traveler’s CPS account and holds those funds in reserve (the transaction will occur at the farebox). For the bike segment, the CPS also checks available funds and holds those funds in reserve (the transaction will occur at the docking station). Issues an e-ticket for the COTA trip segment and a code that can be used to unlock the bike.

Canceling a trip would release the hold on the funds in the Traveler’s CPS account. The CPS is responsible for compliance tasks related to the act of processing and handling payments between the Traveler and Mobility Providers.

MMTPA 4 Both e-ticket and code are transmitted to the Traveler’s MMTPA where they are available immediately under Selected Trips.

Traveler 5 The Traveler is ready to embark and taps on the selected trip which brings up a map to the bike docking station. The Traveler follows the map to the docking station. Once at the docking station, the Traveler walks up to an available bike and enters code.

Bike-Sharing 6 The reader authenticates the payment token with the bike-

If there were NFC readers at the






share and unlocks the bike. The authentication and unlock process takes under a second.

station, the Traveler would be able to tap phone to authenticate.

Traveler 7 Next, the Traveler takes to the street on the bike after consulting the MMTPA for route information. The Traveler’s destination is a bike docking station next to the COTA bus stop that is on the second leg of the trip. The Traveler pockets the phone and rides to the docking station and docks the bike. The Traveler then walks to the COTA bus stop and checks the MMTPA to see that the COTA bus is arriving in less than two minutes.

MMTPA 8 Displays a prompt when the bus arrives.

Traveler 9 Taps the prompt which generates an electronic ticket with QR code. The Traveler holds the code to the farebox reader on the bus.

NFC enabled fareboxes would allow Travelers to authenticate by holding device near reader.

COTA 10 The farebox authenticates the code with COTA’s fare system, deducts payment from their account, and admits the Traveler.

MMTPA 11 Displays the progress of the bus on a map until the Traveler reaches the final destination.

Operating System 12 Trip details are logged in the Operating System.

Because this is a qualifying multimodal trip to receive incentives and rewards, the Traveler earns credit toward future trips





redeemable in CPS account.

Post-Conditions Traveler has completed a multimodal trip and funds have been deducted from CPS account


N/A


MMTPA/CPS-UN003-v02 Real-Time Travel Information MMTPA/CPS-UN003-v02 Compare Trip Itineraries MMTPA/CPS-UN004-v02 User Preferences MMTPA/CPS-UN005-v02 Accept Bookings/Reservations MMTPA/CPS-UN006-v02 CPS Integration MMTPA/CPS-UN008-v02 Notifications and Alerts MMTPA/CPS-UN011-v02 Loyalty, Incentives and Rewards MMTPA/CPS-UN019-v02 NFC Integration MMTPA/CPS-UN024-v02 Subsidization MMTPA/CPS-UN036-v02 Compliance MMTPA/CPS-UN041-v02 One-to-One and One-to-Many Payment Requests MMTPA/CPS-UN042-v02 Funds in Reserve

Inputs Summary N/A

Output Summary

N/A







Figure 12: UC4-S2, UC4-S3: Failure Condition – Bike Not Available at Docking Station

Table 21: UC4-S2: Failure Condition – Bike Not Available at Docking Station

Use Case Failure Condition – Bike Not Available at Docking Station

Scenario ID & Title

UC4-S2: Failure Condition – Bike Not Available at Docking Station

Scenario Objective

Traveler is unable to complete a multimodal trip involving a bike-sharing segment



Actor(s) Actor Role







Pre-conditions Scenario picks up from Step 5 of UC4-S1



MMPTA 6 MMTPA prompts the Traveler there are no available bikes at

As a policy, it is not possible to





the docking station. (A group of tourists have rented all the bikes.).

reserve bikes ahead of time at a station

Traveler 7 The Traveler acknowledges the prompt by clicking on it.

CPS 8 The reserve on Traveler’s CPS account for the cost of the bike rental is removed. The funds are available again in the Traveler’s CPS account.

MMTPA 9 The MMTPA prompts the Traveler of several options in the vicinity that will allow making the bus connection.

The Traveler’s origin (current location) and destination (bus stop) are included in the trip optimization by the Operating System.

Traveler 10 Selects a TNC vehicle which is a block away and clicks on the “Pay Now” button.

CPS 11 The payment request is authorized by the CPS. A reserve for the cost of the trip is placed on the Traveler’s CPS account.

MMTPA 12 Displays the location of the vehicle as it arrives to meet the Traveler. Information about the vehicle and driver is displayed to the Traveler.

Traveler 13 Boards the vehicle and departs for the bus stop.

CPS 14 After the short trip, the CPS credits the Mobility Provider’s Account for the trip.

MMTPA 15 Notifies the Traveler the bus is approaching and prompts to activate the ticket.

Traveler 16 Taps the prompt which displays a QR code. The Traveler holds the code to the farebox reader on the bus.






COTA 17 The farebox authenticates the code and admits the Traveler onto the bus.

MMTPA 18 Displays the progress of the bus on a map until the Traveler reaches his destination.

Operating System 19 The trip details are stored in the Operating System.

Post-Conditions A bike-share trip segment was unable to be fulfilled and the Traveler used the MMTPA to continue to destination


N/A


MMTPA/CPS-UN001-v02 Real-Time Travel Information MMTPA/CPS-UN005-v02 Accept Bookings/Reservations MMTPA/CPS-UN006-v02 CPS Integration MMTPA/CPS-UN010-v02 Changes Mid-Trip MMTPA/CPS-UN021-v02 Mobile Ticketing MMTPA/CPS-UN025-v02 Pay Once MMTPA/CPS-UN030-v02 Reimbursement MMTPA/CPS-UN041-v02 One-to-One and One-to-Many Payment Requests MMTPA/CPS-UN042-v02 Funds in Reserve

Inputs Summary N/A

Output Summary

N/A


Table 22: UC4-S3: Failure Condition – Loss of Communications

Use Case Failure Condition – Loss of Communications

Scenario ID & Title

UC4-S3: Failure Condition – Loss of Communications

Scenario Objective

Traveler experiences loss of connectivity while on route to destination



Actor(s) Actor Role











Pre-conditions Scenario picks up from Step 13 of UC4-S2



MMPTA 14 The Traveler’s cell phone suddenly loses network connectivity and the MMTPA prompts that it is running in offline mode.

TNC 15 Delivers the Traveler to the bus stop where the Traveler alights the vehicle.

MMTPA 16 The trip details are stored on the MMTPA to transit to the Operating System once the device is back online. Because the MMTPA is currently offline, it does not alert the Traveler of when the next bus is arriving.

Traveler 17 Notices the bus arriving and selects the current trip in the MMTPA to display the QR code.

Traveler 18 Holds the code to the farebox reader on the bus.

COTA 19 The farebox authenticates the code and admits the Traveler onto the bus.

MMTPA 20 The Traveler’s cell phone suddenly regains its network connectivity. The MMTPA prompts the Traveler that it is back online.

Trip details that were stored in the MMTPA while offline are transmitted to the Operating System.

MMTPA 21 The MMTPA displays the progress of the bus on a map






until the Traveler reaches his destination.

Operating System 22 The trip details are stored in the Operating System.

Traveler 23 The Traveler disembarks the bus and arrives safely at his destination. The Traveler clicks a link in the MMTPA to provide positive feedback on being able to navigate through spotty connections.

Post-Conditions N/A


N/A


MMTPA/CPS-UN006-v02 CPS Integration

MMTPA/CPS-UN013-v02 User Feedback

MMTPA/CPS-UN014-v02 Offline Usage

Inputs Summary N/A

Output Summary

N/A






Figure 13: UC5-S1: Traveler Without Smartphone Uses IVR System to Activate FMLM Trip

Table 23: UC5-S1: Traveler Without Smartphone Uses IVR System to Activate FMLM Trip

Use Case Traveler Without Smartphone Uses IVR System to Activate PMLM Trip

Scenario ID & Title

UC5-S1: Traveler Without Smartphone Uses IVR System to Activate FMLM Trip

Scenario Objective

A Traveler without smartphone uses an IVR system to activate a FMLM ticket.


Request ticket using IVR system, pay for FMLM trip using COTA smart card

Actor(s) Actor Role


SMH Smart Mobility Hub and pick-up location for ride-sharing segment

IVR System Interactive Voice Response System

Mobility Provider Ride-sharing service to complete last mile of trip






Pre-conditions N/A



Traveler 1 Purchases a multimodal trip involving COTA trip segment and ride-sharing segment to complete the last several miles of the trip. The pick-up location for the ride-sharing segment is a SMH. The Traveler has written down the phone number and Trip ID to call in order to activate the ride-sharing segment.

Trip is purchased using the Traveler web portal.

Traveler 2 Embarks on COTA trip segment and arrives at the SMH.

Traveler 3 Using a touch-tone phone available at the SMH, the Traveler calls the number provided when the trip was purchased.

IVR System 4 Plays a brief welcome message and prompts the Traveler for Trip ID to activate the trip.

Traveler 5 Enters the Trip ID and presses a button to continue.

Activating the trip via Trip ID confirms the Traveler. The TNC is notified same as any other trip booked through the MMTPA.

IVR System 6 Informs the Traveler when the vehicle will arrive at the SMH (specified pick-up location). A description of the vehicle is provided to help the Traveler identify it.

Updates via text or email can be provided to users without smartphones.

Mobility Prover 7 In a short period of time, the vehicle arrives to pick up the Traveler.

Traveler 8 Enters the vehicle to complete the trip.

Post-Conditions Traveler has purchased a FMLM trip which can be activated via a touch-tone phone






The IVR system is needed by the City to meet Title VI compliance for the MMTPA/CPS.


MMTPA/CPS-UN015-v02 Trip Optimization MMTPA/CPS-UN016-v02 IVR System MMTPA/CPS-UN024-v02 Subsidization

Inputs Summary Departure location, departure time, destination

Output Summary

FMLM Ticket



Figure 14: UC6-S1, UC6-S2, UC6-S3, UC6-S4, UC6-S5, UC6-S6: Traveler Creates a CPS Account

Table 24: UC6-S1: Traveler Creates a CPS Account

Use Case Traveler Creates a CPS Account

Scenario ID & Title

UC6-S1: Traveler Creates a CPS Account

Scenario Objective

Traveler creates a CPS account using a credit/debit card


Account creation






Actors(s) Actor Role



CPS Common Payment System

Pre-conditions Traveler is connected to the Internet

Traveler has downloaded the MMTPA to their mobile device


Source Step Key Action Comments

Traveler 1 The Traveler opens the MMTPA and selects “Manage CPS Account.”

MMTPA 2 The MMTPA redirects the Traveler to the CPS.

CPS 3 The CPS displays a list of participating Mobility Providers in the Columbus region. The CPS prompts the Traveler to log in to their existing CPS account or create a new account.

Users with existing CPS accounts will be able to store login info.

Traveler 4 The Traveler selects the option to create a new CPS account.

CPS 5 The CPS prompts the Traveler to agree to terms and conditions before creating a new CPS account.

Traveler is prompted only once to agree to terms and conditions, at time of account creation.

Traveler 6 The Traveler agrees to the terms and conditions, then selects continue.

CPS 7 The CPS prompts the Traveler for personal information including name, address, telephone number, e-mail address.





Traveler 8 The Traveler enters his/her personal information and selects continue.

CPS 9 The CPS prompts the Traveler for valid payment media to fund their CPS account.

Traveler 10 The Traveler enters a valid credit card number, name, expiration date, and CVV then selects continue.

For paratransit customers they can enter their paratransit account number and it will be cross referenced to valid accounts. They can enter additional payment information if they want to exceed their paratransit covered services.

CPS 11 The CPS processes this information and then prompts the Traveler to create a username and password to complete registration.

Traveler 12 The Traveler enters a username and password and selects continue.

CPS 13 The CPS finishes creating the account and returns the Traveler to the MMTPA.

Post-Conditions Travel has created a CPS account and linked payment media to account


None

Traceability MMTPA/CPS-UN017-v02 Same-Day Paratransit Service

MMTPA/CPS-UN022-v02 CPS Account

MMTPA/CPS-UN023-v02 Payment Media

MMTPA/CPS-UN024-v02 Subsidization






Inputs Summary User information, credit card information

Output Summary

None


Table 25: UC6-S2: Traveler Registers a New Payment Method and Enables Auto-Fill and Automated Alerts

Use Case Traveler Registers a New Payment Method and Enables Auto-Fill and Automated Alerts

Scenario ID & Title

UC6-S2: Traveler Registers a New Payment Method and Enables Auto-Fill and Automated Alerts

Scenario Objective

Traveler uses MMTPA to access CPS account and add a new method of payment, enable auto-fill, and receive automated alerts


Log in to CPS, manage CPS account, add payment method, add value, enable auto-fill, enable automated alerts

Actor(s) Actor Role




Pre-conditions Traveler has established a CPS account



Traveler 1 Using a smartphone, the Traveler taps on the MMPTA icon to open it.

Username and password are stored and the Traveler is not prompted to enter them.

Traveler 2 The Traveler taps on a link to manage CPS account.

MMTPA 3 The MMTPA redirects the Traveler to the CPS account management interface.

Redirection should be seamless to the user.

CPS 4 The CPS prompts “please verify your password to continue.”

Users will have the option of





saving password or recovering a lost password.

Traveler 5 The Traveler enters password and clicks continue.

CPS 6 The CPS displays options to view account settings, view and export transaction, update account settings, update payment products, and help.

Traveler 7 The Traveler selects the option to update payment products.

CPS 8 The CPS displays a screen showing registered methods of payment as well as CPS account balance and link to add value. There are also options to add existing fare products from Mobility Providers which can be used to pay for trips (so that the CPS account is not charged when existing fare products should be used instead).

Traveler 9 The Traveler selects the link to Add New Card.

CPS 10 The CPS prompts for Full Name, Street Address, City, State, and Zip Code. For billing information, the CPS provides the option to use the same as the Traveler’s account information to expedite entering the form.

Traveler 11 The Traveler enters the required information and clicks Save.

CPS 12 The CPS then prompts for new card information: Full Name, Card #, Expiration Date (MMYY), Zip Code, and CVV.






Traveler 13 The Traveler enters the information and click submit.

CPS 14 The CPS authorizes the card and returns the Traveler to the previous screen.

Traveler 15 The Traveler notices that his current CPS account balance is $0.00 and decides to set up auto-load using the new credit card added to the account. The Traveler clicks on the auto-load button

If auto-load.

CPS 16 The CPS prompts: If autoload is enabled, value is automatically added to the CPS account when balance dips below $10. Click OK to continue.

Traveler 17 The Traveler click OK to continue.

CPS 18 The CPS displays a screen allowing the Traveler to enter (in whole dollars) how much value should be added to the CPS account automatically when the balance dips below $10.

Traveler 19 The Traveler enters in a value of $30 and selects confirm.

CPS 20 The CPS prompts to confirm the credit card to use to set up the auto-load feature, and option to receive automated alerts (e.g. low balance or auto-fill initiated).

Traveler 21 The Traveler confirms and is returned to the main screen to manage CPS account.

The Traveler’s smartphone received a push notification alerting that account balance was low and





$30.00 was added.

Traveler 22 The Traveler clicks a button to return to the MMTA and continue using the app.

MMPTA 23 The MMTPA displays a current CPS balance of $30.00.

Post-Conditions Traveler has added a new payment method and set up CPS account to auto-fill when account balance dips below $10.00


N/A



MMTPA/CPS-UN023-v02 Payment Media

MMTPA/CPS-UN026-v02 Existing Fare Products

MMTPA/CPS-UN027-v02 Notification of Payment and Account Status

MMTPA/CPS-UN029-v02 Storage of Sensitive Data

MMTPA/CPS-UN031-v02 Security and Encryption

Inputs Summary Credit card information and option to receive automated alerts when account balance is low

Output Summary

Automated alert showing value was added to account


Table 26: UC6-S3: Traveler Updates CPS Account to Qualify for Accessibility Services for ADA-Compliant Trip Segments

Use Case Traveler Updates CPS Account to Qualify for Accessibility Services for ADA-Compliant Trip Segments

Scenario ID & Title

UC6-S3: Traveler Updates CPS Account to Qualify for Accessibility Services for ADA-Compliant Trip Segments

Scenario Objective

Traveler has a permanent or temporary physical or mental impairment that substantially limits ability to get around and is already qualified for COTA Mainstream service for ADA-compliant trip segments. The Traveler wishes to use the MMTPA to schedule trips outside of COTA's service area and pay for non-ADA segments using their CPS account.







Log into CPS, update account settings

Actor(s) Actor Role







Traveler 1 Using a smartphone, the Traveler taps on the MMPTA icon to open it.

Username and password are stored and the Traveler is not prompted to enter them.

Traveler 2 The Traveler taps on a link to manage CPS account.

MMTPA 3 The MMTPA redirects the Traveler to the CPS account management interface.

Redirection should be seamless to the user.

CPS 4 The CPS prompts “please verify your password to continue.”

Users will have the option of saving password or recovering a lost password.

Traveler 5 The Traveler enters password and clicks continue.

CPS 6 The CPS displays options to view account settings, view and export transaction, update account settings, update payment products, and help.

Traveler 7 The Traveler selects the option for help.

CPS 8 The CPS displays a list of topics organized by category.





Traveler 9 The Traveler selects the link for Accessibility for Riders with Disabilities.

CPS 10 The CPS displays a screen showing the benefits of accessibility and how users might qualify. Included is a link explaining how users who have already qualified for discounted fixed-route service may enter this information in the CPS. Also included is an explanation of Mainstream Service for those who have a disability that prevents them from using COTA’s fixed-route service, and how this information may be entered into the CPS.

Mainstream is a ride-sharing public transportation service provided throughout COTA’s fixed-route service area.

There is also a link to an external web page for additional educational material if needed.

Traveler 11 The Traveler clicks on a link to learn how to enter qualifying Mainstream service credentials into the CPS. After reviewing the instructions, the Traveler selects a menu option to return to Account Settings.

CPS 12 The CPS returns the Traveler to the Account Settings screen. Included is a link to confirm eligibility for Mainstream service as well as reduced fare fixed-route service.

The process to register for subsidized trips from an employer, college, or university, would be similar, in which the Traveler would be required to enter a code which verifies the service and links






their account to the service.

Traveler 13 The Traveler clicks on the link for Mainstream service and enters an ID number that is required to verify.

CPS 14 The CPS verifies the ID number and returns the user to the Account Settings screen.

MMTPA 15 The Traveler is now able to request Mainstream service for all ADA-compliant trip segments when using the MMTPA/CPS.

Post-Conditions Traveler can schedule accessible services for ADA-compliant trip segments and use CPS for non-ADA trip segments


N/A


MMTPA/CPS-UN017-v02 Same-Day Paratransit Service


MMTPA/CPS-UN024-v02 Subsidization

MMTPA/CPS-UN029-v02 Storage of Sensitive Data

MMTPA/CPS-UN031-v02 Security and Encryption

Inputs Summary ID Number to confirm eligibility for Mainstream service

Output Summary

N/A


Table 27: UC6-S4: Traveler Recovers Lost CPS Password

Use Case Traveler Recovers Lost CPS Password

Scenario ID & Title

UC6-S4: Traveler Recovers Lost CPS Password

Scenario Objective

Traveler has lost his CPS password and needs to recover it to be able to manage CPS account


Reset password





Actor(s) Actor Role







Traveler 1 The Traveler is using the MMTPA and wishes to update their CPS account. The Traveler clicks on the Manage CPS Account link in the MMTPA.

MMTPA 2 The MMTPA seamlessly redirects the user to the CPS login screen.

Traveler has not elected to store password.

Traveler 3 The Traveler makes a failed attempt at logging in before realizing he does not remember his password. The Traveler clicks on the link for Forgot Password.

CPS 4 The CPS prompts the Traveler to enter their registered email address and answer a series of security questions.

Traveler 5 The Traveler completes the requested information and submit the reset request.

CPS 6 The CPS sends an email to the Traveler with instructions on how to reset password.

Traveler 7 The Traveler follows the instructions and is able to reset password and log into CPS to manage account.

Post-Conditions Traveler has recovered lost password and is able to log in


N/A








Inputs Summary Email address, security questions

Output Summary

Password


Table 28: UC6-S5: Traveler Closes CPS Account

Use Case Traveler Closes CPS Account

Scenario ID & Title

UC6-S5: Traveler Closes CPS Account

Scenario Objective

Traveler closes CPS account and receives reimbursement for funds remaining in the account. Transportation benefits/rewards that may have existing on the account are no longer available.


Delete account

Actor(s) Actor Role







Traveler 1 Traveler wishes to close their CPS account. The Traveler accesses the account by clicking on the manage CPS account link in the MMTPA.

MMTPA 2 The MMTPA seamlessly redirects the user to the CPS and CPS account management screen.

Password has been stored.

Traveler 3 The Traveler clicks on Account Settings and clicks on a link to delete account.




Use Case Traveler Closes CPS Account

CPS 4 The CPS prompts the Traveler that deleting the account will remove all secure contact and payment information from the system. This action is permanent and cannot be undone. The Traveler’s remaining CPS account balance will be returned to the payment media on file. Any transportation benefits / rewards associated with the account will be lost. The CPS prompts the Traveler to continue or cancel.

Deleting CPS account does not remove anonymized trip information from the Operating System.

Traveler 5 Traveler selects option to continue and is redirected to the MMTPA main screen. CPS account balance is no longer accessible, but there is a link to set up a CPS account.

Traveler may set up a new CPS account at a later time.

Post-Conditions Traveler has deleted their CPS account but can still use the functionality of the MMTPA to plan trips.


Remaining balance on Traveler’s CPS account is returned to card on file. All contact and payment information is removed from the system. Anonymous trip and payment data remains in the Operating System.



Inputs Summary N/A

Output Summary

N/A


Table 29: UC6-S6: Traveler Pays for a Trip Using a CPS Guest Account

Use Case Traveler Pays for a Trip Using a CPS Guest Account

Scenario ID & Title

UC6-S6: Traveler Pays for a Trip Using a CPS Guest Account

Scenario Objective

Traveler pays for trip as guest instead of creating a CPS account







Continue as guest

Actors(s) Actor Role




Pre-conditions Application User is connected to the Internet

Application User has downloaded the MMTPA to their mobile device


Source Step Key Action Comments

Traveler 1 The Traveler opens the MMTPA and enters origin and destination information.

MMTPA 3 The MMTPA determines the best available trip options for the Traveler according to user preferences and displays several trip itineraries for the Traveler to select from.

Traveler 4 The Traveler selects a trip itinerary that includes a walking segment, a transit segment, and a bike-sharing segment. The Traveler click Pay Now.

MMTPA 5 The MMTPA redirects the Traveler to the CPS.

CPS 6 The Traveler does not have a CPS account and is prompted to continue as Guest or create a CPS account.

Traveler 7 The Traveler does not wish to create a CPS account now, and prefers to complete payment as a guest to see how the System works. The Traveler selects continue as guest.

Continuing as guest allows a Traveler to make payment but without the benefit of a permanent CPS account. Payment





information will have to be reentered each time.

CPS 8 The CPS prompts the Traveler for valid payment media to pay for the trip.

Traveler 9 The Traveler enters a valid credit card number, name, expiration date, and CVV then selects continue.

CPA 10 The CPS processes this information and then redirects the Traveler to the MMTPA Trip Summary view.

Traveler 11 The Traveler clicks on the trip itinerary to confirm that the trip has been processed and is ready to embark.

Post-Conditions The Traveler has paid for a trip using a CPS guest account


Travelers are not required to create a CPS account to pay for services, except a valid paratransit account must be cross referenced to the existing paratransit account.

Traceability MMTPA/CPS-UN022-v02 CPS Account

Inputs Summary Credit card information

Output Summary

N/A







Figure 15: UC7-S1: Mobility Provider Establishes an Account in the Operating System

Table 30: UC7-S1: Mobility Provider Establishes an Account in the Operating System

Use Case Mobility Provider Establishes an Account in the Operating System

Scenario ID & Title

UC7-S1: Mobility Provider Establishes an Account in the Operating System

Scenario Objective

A Mobility Provider enters into a partner agreement with Smart Columbus and is given access to the Operating System to deploy third-party apps and integrate with trip optimization services.


Deploy third-party app in Operating System, trip optimization

Actor(s) Actor Role

Mobility Provider Company that provides services to Travelers; Mobility Providers and Parking providers

The City (Owner) Facilitator of the system; responsible for agreements between all stakeholders of the system

Operating System Smart Columbus Operating System; the Smart Columbus PMO is responsible for maintaining the Operating System and integrating with Mobility Providers

Pre-conditions A local TNC with a small fleet of 10 vehicles wishes to partner with Smart Columbus and join the MMTPA/CPS





The TNC has a scheduling application that may be configured to run within a Docker container and can be deployed within the Operating System’s microservices environment



City of Columbus 1 A partner agreement is formed between Smart Columbus and the Mobility Provider to integrate with the Operating System in order to share data and services for the MMTPA/CPS.

MMTPA and CPS are maintained and operated external to the City; the Operating System is maintained by the Smart Columbus PMO.

Operating System 2 The Operating System team provides information required to deploy third-party applications in the Operating System and/or interface with the Operating System through APIs to provide real-time vehicle location, schedule, availability and cost information needed for trip optimization services.

Operating System 3 The Operating System team works with the Mobility Provider (developers) to deploy the application and ensure it meets the Operating System requirements for validation and interoperability with other services running in the environment, as well as the ability to provide monitoring to ensure health of the microservices environment.

Post-Conditions N/A


N/A


MMTPA/CPS-UN034-v02 Operations and Maintenance

MMTPA/CPS-UN035-v02 Future Growth and Maintainability






Inputs Summary N/A

Output Summary

N/A



Figure 16: UC8-S1: Mobility Provider Manages CPS Account

Table 31: UC8-S1: Mobility Provider Manages CPS Account

Use Case Mobility Provider Manages CPS Account

Scenario ID & Title

UC8-S1: Mobility Provider Manages CPS Account

Scenario Objective

Mobility Providers must establish merchant accounts in the CPS to receive payment in exchange for services. In this scenario a Mobility Provider logs into their account through a web-based portal to access account information.


Authentication





Actor(s) Actor Role

Mobility Provider Mobility Providers and Parking Providers

CPS Web-based Mobility Provider Portal to manage CPS account information

Pre-conditions Accounts have been provisioned for the Mobility Provider as part of partner agreement with Smart Columbus.



Mobility Provider 1 Using a web browser, the Mobility Provider navigates to the Mobility Provider portal and authenticates by providing username and password

Mobility Providers have the ability to manage their own contact information through the portal.

Mobility Provider 2 Once authenticated, the Mobility Provider has options to manage their account information as well as view reports and invoices.

Mobility Provider 3 Mobility Provider clicks on the link to manage reports

CPS 4 CPS web portal displays the reports view

Mobility Provider 5 Mobility Provider can view all transactions related to their service history, and view detailed trip reports as needed. The Mobility Provider creates a report in order to export transactions to view outside of the system.

Post-Conditions Mobility Provider has logged into the portal and exported a report.


N/A


MMTPA/CPS-UN006-v02 CPS Integration

MMTPA/CPS-UN040-v02 Mobility Provider Accounts

Inputs Summary N/A






Output Summary

Report export



Figure 17: UC9-S1, UC9-S2: City of Columbus and Third-Party Users Retrieve Data from Operating System

Table 32: UC9-S1: City of Columbus User Retrieves Data from Operating System

Use Case City of Columbus User Retrieves Data from Operating System

Scenario ID & Title

UC9-S1: City of Columbus User Retrieves Data from Operating System

Scenario Objective

City of Columbus user connects to the Operating System to receive data


View reports, configure reports, access data through APIs

Actor(s) Actor Role

MMTPA/CPS Responsible for creating the data




Use Case City of Columbus User Retrieves Data from Operating System

Operating System Responsible for collecting and preparing data to support analytics and performance measures by the City of Columbus and third parties.

City of Columbus Members of the City with unrestricted access to data for reporting and analytics purposes.

Pre-conditions N/A



MMTPA/CPS 1 The MMTPA/CPS creates data by providing multimodal trip planning and payment services to Travelers.

Operating System 2 The Operating System collects the data that is generated by the MMTPA/CPS and prepares it for analytics. The Operating System segments a portion of the data that will be available to third-party users and a portion of the data that will be available to City of Columbus/COTA users.

City of Columbus 3 City of Columbus/COTA users access the data through web-based dashboards which display performance metrics. City users can configure the reports that are available on the dashboards.

Data access is restricted; users must provide authentication credentials.

Post-Conditions N/A


Data does not include PII


MMTPA/CPS-UN033-v02 Access to Trip and Payment Data

Inputs Summary N/A

Output Summary

Data for development and reporting/analytics






Table 33: UC9-S2: Third-Party User Retrieves Data from Operating System

Use Case Third-Party User Retrieves Data from Operating System

Scenario ID & Title

UC9-S2: Third-Party User Retrieves Data from Operating System

Scenario Objective

Third-party users connect to the Operating System to receive data


View reports, configure reports, access data through APIs

Actor(s) Actor Role

MMTPA/CPS Responsible for creating the data

Operating System Responsible for collecting and preparing data to support analytics and performance measures by the City of Columbus and third parties.

Third-Party Users Members of the public with restricted access to data for development purposes

Pre-conditions N/A



MMTPA/CPS 1 The MMTPA/CPS creates data by providing multimodal trip planning and payment services to Travelers.

Operating System 2 The Operating System collects the data that is generated by the MMTPA/CPS and prepares it for analytics. The Operating System segments a portion of the data that will be available to third-party users and a portion of the data that will be available to City of Columbus/COTA users.

Third-party users 3 Third-party users access the data through APIs, which are developed by the Operating System team.

Refer to Section Personally Identifiable Information for information on how data will be anonymized in the Operating System.




Use Case Third-Party User Retrieves Data from Operating System

Post-Conditions N/A


Data does not include PII


MMTPA/CPS-UN033-v02 Access to Trip and Payment Data

Inputs Summary N/A

Output Summary

Data for development and reporting/analytics





Chapter 7. Summary of Impacts

This section describes the anticipated operational and organizational impacts of the proposed system on the City during all stages of the proposed system, from development through implementation and support and maintenance of the proposed system.

Challenges

The integration of multimodal services and common payment presents challenges in coordinating policy, governance, financial management, and acquisition. Some of the key challenges include: Are Mobility Providers willing to operate in a shared, single payment platform environment that utilizes their APIs in a unified multimodal application? Are Mobility Providers willing to provide real-time tracking data to the system that will be used to coordinate the notification of the arrival of a traveler to their provider? Are Mobility Providers willing to operate in a single payer environment that utilizes their API to give expected arrival information to the user though a unified multimodal application?

Operational Impacts

Changes in procedure regarding support and maintenance of the new system are anticipated, however, the solution will dictate the extent of additional support needed. Considerations include business owner(s), software development and database resources in a primary and backup capacity, server, and security concerns. Data Privacy and Data Management plans will be identified and refined during development to address operational impacts and changes in data retention requirements. This will likely fall under departmental owner data retention requirements or new requirements will be made since new services are being offered. If usage reports or historical information are identified as a requirement, retention policies will need to be reviewed and changed as needed.

Organizational Impacts

As the owner of the MMTPA/CPS system, COTA will be responsible for the control of standards, regulations, and agreements between all stakeholders, as well as Operations and Maintenance (O&M) of the system once it is operational. It is anticipated that additional responsibilities will require hiring additional staff. Support personnel and technicians will be needed to monitor various aspects of the system and analyze performance.

The Operating System will be operated by the Smart Columbus PMO. The PMO will continually monitor the operational performance of the system and consider adjustments to ensure it is operating as expected. Further, the PMO will ensure that all performance measures and data required for an Independent Evaluator, and overall monitoring of the system, are being collected and documented as required. Other organizational impacts are expected for COTA and Mobility Providers. These agencies will

Chapter 7. Summary of Impacts



be responsible for integrating with the Operating System to allow for trip planning and trip payment services through the MMPTA/CPS system.

Impacts During Development

There are several projects and coordination tasks that could affect the ability of the system to provide all the services that have been conceptualized for the system. These tasks include the development of the CPS and creation of data sharing agreements with the Mobility Providers. In addition to data sharing agreements, it will be necessary to coordinate with Mobility Providers to promote and expand usage of shared mobility services. Connectivity with the CPS is essential for trip payment and a major differentiator for the MMTPA compared with other existing systems. The ability to collect trip and payment information within the Operating System is also a major component of the MMTPA/CPS – these interfaces will need to be developed, and the parameters and expectations for integration defined through future development processes.




Chapter 8. Analysis of Multimodal Trip Planning App

An analysis of the MMTPA/CPS is summarized in Summary of Improvements.

Summary of Improvements

Table 34: Summary of Improvements provides a summary of improvements as a result of the proposed system.

Table 34: Summary of Improvements

Improvements Summary

New Capabilities A single, convenient platform to plan, reserve, and pay for multimodal trips

Integration with the Operating System for trip optimization and access to data

Enhanced Capabilities Comprehensive multimodal trip planning and payment

Ability to store user preferences and create personalized trip itinerates

Deleted Capabilities No capabilities deleted

Improved Performance Improved mobility for Travelers

Improved data for City of Columbus and third-party users


Disadvantages and Limitations

The constraints in Operational Policies and Constraints may be considered disadvantages of the proposed system in terms of needing to be overcome in order to achieve the goals and objectives for the MMTPA.

Alternatives and Trade-Offs Considered

An alternative approach was considered in which the MMTPA/CPS as a platform was responsible for only trip planning and payment scheme. The Operating System would provide trip optimization services to allow Travelers to plan routes using the MMTPA, and deep integration with the Mobility Providers to handle the bookings and subsequent trips and trip changes as necessary. Travelers would also be




required to create accounts with the participating Mobility Providers when creating a CPS account. This would be required to link accounts while using the MMTPA deeply integrated with the other apps and services. This alternative was considered but rejected as it would require too much custom development each time a Mobility Provider entered the system, as the requirements for each provider would be different. As a platform for MaaS this system would not scale well as more and more providers were added.

Table 35: Alternatives and Trade-Offs Considered summarizes the alternative approaches and trade-offs considered.

Table 35: Alternatives and Trade-Offs Considered

Trade-offs/Alternatives Description Decision Rationale

Incorporate EPM functionality

Integrate Parking Providers into the Operating System and CPS

To be determined The MMTPA may at some point include EPM system information. This integration is not proposed at this time due to the complexity of the two projects.

Leverage COTA’s Trip Planner Website

There is a web-based trip planner tool already available to the public, but it is limited to COTA’s service

Do not pursue Does not address the project needs as defined in Error! Not a valid result for table..

Leverage SPX/Genfare’s Mobile Ticketing application framework

The application is currently being developed for COTA’s system only

To be determined The framework is currently in development and may not address all of the project needs as defined in Error! Not a valid result for table..

Leverage Transit App Utilize an existing mobile app with well-established user base

Do not pursue Does not address the project needs as defined in Error! Not a valid result for table..





Trade-offs/Alternatives Description Decision Rationale

Leverage Operating System without MMTPA

The Operating System could be used to develop and serve APIs to make data available for app developers to develop an MMTPA independent of the City

Do not pursue Does not address the project needs as defined in Error! Not a valid result for table.. Does not fit into the Operating System Product Vision and operating goals. Poses financial and user privacy security risks.

Leverage COTA’s System

Leverage COTA’s account-based central system (currently in development) through separate contracts with SPX/Genfare

To be determined The account-based system is currently in development and may not address all the project needs as defined in Error! Not a valid result for table.. It needs to be determined if COTA can expand their requirements with SPX/Genfare.

Smart Columbus Branded COTA Smart Cards

Pursue an agreement with COTA in which the City registers a Smart Columbus branded COTA smart card and is invoiced directly for use of those cards on COTA’s system. This solution may be subject to further studies to assess feasibility and/or desirability.

To be determined This type of partnership is still in consideration; however, the City does not wish to handle invoicing.

Develop CPS within the Operating System

Develop the CPS as part of the Operating System environment

Do not pursue Does not fit into the Operating System Product Vision and operating goals.





Chapter 9. Notes

The following constraints4 need to be overcome to allow for ridesourcing companies to provide contracted paratransit services using federal subsidies.

FTA-required drug and alcohol testing. Such testing applies to any party contracted to provide transportation services for a public transit agency (Nelson\Nygaard Consulting Associates et al. 2007). Testing is required for operators, dispatchers, and maintenance personnel for transit agencies or contractors receiving funding under Sections 5307, 5309, and 5311, the major public transportation funding programs, including taxi companies in a contractor (rather than vendor/voucher) relationship (49 CFR Part 655 final rule effective June 25, 2013). Section 5310 organizations (which provide services specifically for the elderly and people with disabilities) are exempt from the testing requirements only if they do not provide any services for an agency funded under the other programs.

Liability and occupational safety relating to transfers and loading/unloading of non-ambulatory riders. Potential exists for injury to both drivers and passengers if drivers are not properly trained to help people with impaired mobility to load, unload, and secure their wheelchairs.

Provision of door-to-door (versus curb-to-curb) service, which is determined by individual agency policy. Even if the general practice is to provide only curb-to-curb service, however, a driver must “provide assistance to those passengers who need assistance beyond the curb in order to use the service unless such assistance would result in a fundamental alteration or direct threat” (FTA 2015). Although providers may ask passengers to request assistance in advance, the driver must provide such assistance as would actually allow the passenger to use the transportation to get from the origin to destination, even if the policy is curb-to-curb service and if the passenger fails to request assistance. Any private contractor being used to provide paratransit service would need to follow these rules.

Requirements for accepting accessible rides and for accommodating wheelchairs or service animals. Ridesourcing companies have had inconsistent results in this area, although it is of increasing interest to some companies.

Heightened vehicle safety and inspection requirements and insurance costs associated with ADA provision and the transportation of fragile individuals. These requirements and costs go beyond the already-identified questions about the applicability of non-commercial insurance in a ridesourcing provision.

Fleet-level accessibility requirements. Unlike fixed-route transit fleets, which must be 100 percent accessible, demand-responsive transit service can be delivered with a fleet that offers a mix of accessibility levels, as long as the level of access provided to riders with disabilities is equivalent to the level of service it provides to riders without disabilities (49 CFR 37.77[b]). FTA

4 TCRP RESEARCH REPORT 188: Shared Mobility and the Transformation of Public Transit

Chapter 9. Notes



guidance states that a mix that includes inaccessible vehicles may be used for provision of complementary paratransit “as long as accessible vehicles are dispatched to riders who need them” (FTA 2015).

Fleet ownership prohibitions. In some jurisdictions, questions of fleet-level accessibility may be moot — most notably, throughout the state of California, where TNCs are by definition prohibited from owning vehicles or fleets used in their operations (California Public Utility Commission, Rulemaking 12-12-011, 2013). In these situations, accessible vehicles would have to be provided by drivers under incentives from the companies (leased vehicles are permissible under the rules), or through partnerships with other providers who can own accessible fleets.

Buy America provisions. Most federally funded rolling stock procurements above $100,000 are subject to the requirement that vehicles and components be substantially manufactured and assembled in the United States. Some flexibility exists in the application of these requirements and waivers are available, but the auditing requirements can add significantly to the unit cost of the kinds of smaller vehicles used for paratransit or other demand-responsive services (Macek et al. 2007).




Appendix A. Stakeholder Engagement Summary

The following is a summary of end-user and stakeholder engagement activities to assess community interest in utilizing an online/mobile app for multimodal trip planning and payment.

End-users and stakeholders involved in the engagement process included:

Expecting moms

Older adults

Linden residents

People who work in Linden

Bicyclists

Pedestrians

Traffic manager

Transit vehicle operator

Transit manager

Heavy duty vehicle operator

Emergency vehicle operator

Easton visitors and enrollees

Columbus State

End-User Engagement Events Summary

1. Event 1: Smart Columbus Connects Linden

a. When: February 10-11, 2017

b. Where: St. Stephens Community House, Linden

c. Who participated: 160 community members volunteered to attend

d. Why: Linden residents are the target population group for recruiting participants willing to install CV equipment on private vehicles

e. Key takeaways




1) A majority of the attendees who completed the survey said that they would favor a smartphone app to make travel arrangements and pay for them, seeing it as a convenient, no-cash-needed option

2) ii. Linden residents have privacy concerns with personal information provided at kiosks

2. Event 2: Online Survey

a. When: April 2017

b. Where: Promoted online and distributed to contacts who expressed interest

c. Who participated: 34 community members volunteered to participate

d. Why: Given the volume of interest in the Smart Columbus Connects Linden event, an online survey was conducted to gain participation from those unable to attend that event

e. Key takeaways:

i. A large majority of the respondents have access to the internet via computer, smartphone, or through free access at a community center or business

ii. Over 60 percent of respondents estimate that they use one or more Gigabytes of data each month on their phones. 15.2 percent of respondents use 0-1 GB per month. The remaining respondents were not sure of their usage.

3. Event 3: Linden Older Adults Focus Group

a. When: June 21, 2017

b. Where: Northern Lights Library, Linden

c. Who participated: Four community members volunteered to attend

d. Why: Focus group of community volunteers to gain additional, more directed insight on specific user needs

e. Key takeaways:

i. Discussed the importance of being able to specify “how mobile are you” in selection of routing on an app

ii. The group felt that those aged 65-75 are more likely to have internet access, use smartphones and download apps, but that those over 75 would not be likely to use an app or have internet access

iii. Credit and debit card access and awareness of how to use them is common in this group; most older adults in the group and those they know have long-established credit cards

4. Event 4: Linden Moms2Be Focus Group

a. When: June 21, 2017

b. Where: Grace Baptist Church, Linden

c. Who participated: 11 female community members (expecting and new moms) volunteered to attend

d. Why: Focus group of community volunteers to gain additional, more directed insight on specific user needs





e. Key takeaways:

i. The large majority of participants had smartphones and access to Wi-Fi/data. None of the participants pay for apps.

ii. There is concern with putting bank/credit card information into an app because of security concerns. The preference is to have a prepaid card to put into the app for payment of transportation services.

iii. The ability to both plan the trip in the app and also pay for it in the app was attractive to most participants

5. Event 5: Cluster Sampling Field Surveys – Multimodal Trip Planning Application

a. When: March 5-23, 2018

b. Where: Surveys were administered at three Columbus regions: Linden, Easton and Columbus State Community College

c. Who participated: A sampling of residents/visitors to the three regions completed a total 171 surveys

d. Why: The information collected from the surveys will be used to inform the design of the MMTPA/CPS projects

e. Key takeaways:

i. When the community was asked to share their preferences, and select from a variety of new ideas and tools which could improve their quality of life, they responded that they would like to see as many of the options come to reality as possible

ii. The majority of respondents have access to a smartphone with a data plan

iii. Out of nine possible app features listed in the survey, three were selected by the respondents as clear-cut favorites: 1) Plan/select multiple types of travel; 2) Find the quickest way to get somewhere; 3) Find the least costly way to get somewhere

Linden Community Outreach

When Columbus engaged residents of the Linden neighborhood to share some of their experiences with the current system, their comments touched on a range of issues. Residents struggle with inconveniences of using transit, such as multiple bus route transfers, prolonged periods waiting for a bus to arrive, lengthy commutes to and from destinations, and the cost of monthly bus passes. First and last mile services are lacking in Linden and COTA bus stops are too far away from riders’ homes, jobs, and other destinations. Residents desire more convenient transit service, including more connections within Linden, a crosstown route along Cleveland Avenue to Polaris, and 24-hour service and access to light rail that can connect them with jobs outside of Linden. Polaris is a popular retail, commercial, and entertainment area on Columbus’s north side. A convenient, account-based system is needed for all forms of transportation which will address the inconvenience of having exact change to pay for bus fares in addition to other advantages. Better access to city bicycle routes and shared use paths is needed along with bicycle racks in public places. A focus on walkability within Linden is needed to serve older adults, the blind and children, along with improvements to sidewalks and lighting.




Safety is a big concern for Linden residents. This includes personal safety of single moms, children, and older adults riding COTA walking to or from a bus stop and the physical safety of residents who are afraid to ride a bicycle on congested city streets.

Survey Results

The following are the results of survey questions posed to residents in Linden about transportation services in general. These questions were meant to identify current patterns of transportation usage and obstacles preventing transportation usage in accordance with ideal outcomes envisioned by the residents. While these questions do not directly address the goals of the MMTPA project, they were meant to uncover gaps in the current condition that could possibly be overcome when considering design of the MMTPA.

Of the 68 total surveys collected, 14 participants (21 percent) did not provide an answer to any of the eight questions on the Smart Apps survey. It should be noted that some participants gave more than one response to a question and not every participant answered each question. All percentages are calculated with a denominator of 68 participants, regardless of the number of individual responses received for that question, so percentages may sum to less than, equal to, or greater than 100 percent.

SURVEY QUESTION 1: What travel services are you interested in using?

Participants were asked “what travel services are you interested in using?” Of the 109 individual responses received (multiple responses were allowed), most participants were interested in riding COTA bus services (33 percent), riding a bicycle (18 percent) and utilizing car2go (12 percent). Two proposed ideas of interest include a free Linden circulator transit service and grocery delivery, and a build your own bicycle loan program.

Table 36: What travel services are you interested in using?

Services Number of Responses % of Respondents

COTA 36 33%

Bicycle 20 18%

car2go 13 12%

Uber 11 10%

Car 9 8%

Lyft 9 8%

Taxi 3 3%

Walking 3 3%

Other 2 2%

Light rail/subway 2 2%

Carpool 1 1%






SURVEY QUESTION 2: How do you currently get information about these services if you use them today?

Correspondents were asked “how do you currently get information about these services if you use them today?” Of the 65 individual responses, most get their information from the internet/website (29 percent), smartphone/apps (15 percent), and Google Maps (15 percent).

Table 37: How do you currently get information about these services if you use them today?

Preference Number of Responses % of Respondents

Internet/website 19 29%

Smartphone/apps 10 15%

Google Maps 10 15%

COTA schedules 5 8%

Others 4 6%

Call information 4 6%

Social service agency 3 5%

Other 3 5%

COTA info center 2 3%

Public meetings 2 3%

Email 2 3%

Columbus biking page 1 2%


SURVEY QUESTION 3: How would you like to get information?

Linden residents were asked “how would you like to get information?” Of the 72 individual responses, most residents would like to get their information from a phone/app (50 percent), or a kiosk (24 percent).

Table 38: How would you like to get information?


Phone/app 36 50%

Kiosk 17 24%

Text alerts 6 8%

Paper version 5 7%





Signage 5 7%

Information center 2 3%

Other 1 1%


SURVEY QUESTION 4: What information is most important?

Correspondents were asked “what information is most important?” Of the 67 responses, the most important information included costs (22 percent), real-time alerts (20 percent), and “how-to education” (18 percent).

Table 39: What information is most important?

Information Number of Responses % of Respondents

Costs 14 22%

Real-time alerts 13 20%

“How-to” education 12 18%

Service/alternate transportation options

9 13%

Routes 5 7%

Easy to find/convenient 4 6%

Weather conditions 4 6%

Safety 3 4%

Alternate transportation options 3 4%


SURVEY QUESTION 5: What are the obstacles to getting all the information in one place?

Participants were asked “what are the obstacles to getting all information in one place?” Of the 38 individual responses, most participants mentioned that a lack of Wi-Fi access (32 percent), kiosks/information centers (16 percent), and inter-business cooperation are the highest obstacles.

As previously mentioned, internet connectivity will be a prerequisite for using the MMTPA. Other Smart Columbus projects such as Mobility Hubs and Smart Street Lighting are meant to partially alleviate the lack of internet connectivity reported by residents.





Table 40: What are the obstacles to getting all the information in one place?

Obstacles Number of Responses % of Respondents

Wi-Fi access 12 32%

No kiosks/physical info centers 6 16%

Lack on inter-company cooperation

6 16%

Fees 5 13%

Lack of multi-lingual options 3 8%

No smartphone 3 8%

Not enough options 2 5%

No app 1 2%


SURVEY QUESTION 6: How do you want to pay for these services if you use them today?

Participants were asked “how do you want to pay for these services?” Of the 48 individual responses received, most participants would like to pay for these services with a common payment method (33 percent), debit card (16 percent), or credit card (15 percent).

Table 41: How do you currently pay for these services if you use them today?

Methods Number of Responses % of Respondents

Common payment method 16 33%

Debit card 8 16%

Credit card 7 15%

Cash 7 15%

App 7 15%

Kiosk 3 6%


SURVEY QUESTION 7: How do you currently pay for these services if you use them today?

Participants were next asked about how they currently pay for these services if they use them. Of the responses received most pay with credit/debit cards (25 percent each), followed by cash (22 percent). Following in descending order were paying by app (3 percent), payroll deductions (1 percent), and other (1 percent). It should be noted that COTA requires a cash fare or a monthly pass that can be purchased with cash or credit cards, although it plans to introduce a new fare payment system later in 2017.




Table 42: How do you currently pay for these services if you use them today?

Payment Method Number of Responses % of Respondents

Credit Card 17 25%

Debit Card 17 25%

Cash 15 22%

App 2 3%

Payroll Deductions 1 1%

Other 1 1%


SURVEY QUESTION 8: How do you want to pay for these services?

Participants were asked “How do you want to pay for these services?” Of the 48 individual responses received, most participants would like to pay for these services with a common payment method (33 percent), debit card (16 percent), credit card, cash or app (15 percent each).

Table 43: How do you want to pay for these services?

Payment Method Number of Respondents % of Respondents

Common payment method 16 33%

Debit Card 8 16%

Credit Card 7 15%

Cash 7 15%

App 7 15%

Kiosk 3 6%


SURVEY QUESTION 9: What are the obstacles?

Participants were also asked “What are the obstacles?” Of the 12 responses received, obstacles include the lack of a common payment method (5 responses), lack of discounts (2 responses), lack of Wi-Fi (2 responses), education (2 responses), and lack of a loan program (1 response).





Table 44: What are the obstacles?

Obstacles Number of Respondents % of Respondents

Lack of common payment method

5 41%

Lack of discounts 2 17%

Wi-Fi 2 17%

Education 2 17%

Lack of loan programs 1 8%


Focus Groups

In June 2017, after ConOps had been drafted for several projects that would affect Linden, the Smart Columbus team conducted two focus groups to gain additional insight on specific user needs – specifically pregnant/new moms and older adults. Project concepts shared included use of a CPS to pay for transportation needs.

When participants in the pregnant/new-moms group were asked about their preferred method of payment, most of the group identified being frequent users of prepaid cards. The group noted that they feel these are safer and less prone to hacking than when using a bank-issued card. Overall sentiment and trust for banking institutions was low but use of a card for payments is common. Only one participant used cash exclusively to pay for transportation services. The entirety of the participants in the older adults focus group were banked users. Security of personal financial information was a noted concern for both focus groups.




Appendix B. Acronyms and Definitions

Table 45: Acronym List contains project specific acronyms used throughout this document.

Table 45: Acronym List

Acronym / Abbreviation Definition

ADA Americans with Disabilities Act

API Application Programming Interface

AVL Automated Vehicle Location

B2B Business to Business

BRT Bus Rapid Transit

CBUS City's free downtown Circulator bus service

CC Credit Card

CEAV Connected Electric Autonomous Vehicle

CIS Center for Internet Security

CMAX Brand for COTA Cleveland Avenue Bus Rapid Transit

ConOps Concept of Operations

COTA Central Ohio Transit Agency

CP Connection Protection

C-pass Brand for COTA downtown employee bus program


CSCC Columbus State Community College

DSS Data Security Standards

DoT Department of Technology

EAV Electric Autonomous Vehicle

EMV Europay, MasterCard, Visa

EPM Event Parking Management

FHWA Federal Highway Administration





FMLM First Mile Last Mile

FTA Federal Transit Administration

GBFS General Bikeshare Feed Specification

GHG Greenhouse Gas

GNSS Global Network Satellite System

GPS Global Positioning System

GTFS General Transit Feed Specification

GTFS-RT General Transit Feed Specification – Real-Time

GUI Graphical User Interface

I/O Input/Output

IEEE Electrical and Electronics Engineers

ISO International Organization for Standardization

ITS Intelligent Transportation Systems

IVR Interactive Voice Response

LUM Limited-Use Media

MaaS Mobility as a Service

MBTA Massachusetts Bay Transportation Authority

MMTPA Multimodal Trip Planning App

MORPC Mid-Ohio Regional Planning Commission

MOU Memorandum of Understanding

NEMT Non-Emergency Medical Transportation

NFC Near-Field Communications

NGO Non-Governmental Organization

NTD National Transit Database

O&M Operations and Maintenance

O/D Origin/Destination

ODOT Ohio Department of Transportation

OSU Ohio State University






OWASP Open Web Application Security Project

PCI Payment Card Industry

PII Personally Identifiable Information

PMO Program Management Office

POC Point of Contact

PoS Point of Sale

RFI Request for Information

RFP Request for Proposal

RFID Radio Frequency Identification

RT Real-Time

RTA Regional Transportation Authority

SaaS Software as a Service

SCMS Security Credential Management System

Operating System Smart Columbus Operating System

SDK Software Development Kit

SEMP Systems Engineering Management Plan

SLA Service Level Agreement

SMH Smart Mobility Hub

SOV Single Occupancy Vehicle

SSL Secure Sockets Layer

SUMC Shared Use Mobility Center

SoS System of Systems

TNC Transportation Network Company

TSP Transportation Service Provider

TVM Ticket Vending Machine

UI User Interface

USDOT U.S. Department of Transportation





Appendix C. Glossary

Table 46: Glossary contains project specific terms used throughout this document.

Table 46: Glossary

Term Definition

311 Columbus Call Center The City of Columbus Call Center is the single point of contact for requesting all non-emergency City services and is available to residents, City businesses, and visitors

Agile A method of project management that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans

App Software application

Application solution providers Private companies that design, test, integrate, operate, and maintain one or more aspects of the CPS

Automated vehicle A vehicle that can sense its environment and navigate without human input

Banked users Banked users have set-up a user account with funds deposited in their account or credit card information saved.

C-pass The C-pass program gives eligible downtown employees access to ride any COTA bus, anytime

Central Fare Management System

System implemented through a recently executed contract with SPX/Genfare and will accept various forms of payment including cash, magnetic cards, smart cards and mobile tickets

Commercial-off-the-shelf system (COTS)

Software or hardware product that are ready-made and available for sale to the public

Connection Protection (CP) system

A system which will hold a bus for someone that has reserved a trip

Connected vehicle A vehicle capable of communicating with other vehicles, infrastructure, and smartphones

Connected Vehicle Technology

Technology that lays the foundation for a fully interoperable, open, wireless environment for enhancing safety and mobility for vehicles, pedestrians, and cyclists




Term Definition

Data privacy The reasonable expectation that data of a sensitive nature will be kept confidential, sanitized and/or encrypted, and respectfully and responsibly maintained by all users, managers, and collectors of the data

Data retention The continued storage of data for compliance or business reasons

Data security The tools, policies, practices, and procedures used to protect data from being accessed, manipulated or destroyed or being leveraged by those with a malicious intent or without authorization, as well as the corrective actions taken when data breaches are suspected or have been identified

Data sharing policies Adopted plan around the practice of making data available to others

Dependency When one Project, agency, or entity requires data or functionality provided by another Project, agency, or entity to meet its objectives

Diminished operations When pre-determined signal timing plans are not implemented at the proper time or when traffic detection does not function properly

Enabling technologies An innovation that alone or paired with an existing solution produces a better end user solution at a rapid rate

Experience Columbus An organization whose mission is to market and promote Columbus services, attractions, and facilities to visitors, meeting planners, convention delegates, and residents

Failure operations When a complete failure of the intersection occurs, primarily due to loss of power or other malfunctions

Fare collection system A system, either automated or manual, that collects fares for Transportation Service Providers (TSPs)

Integrated traceable fare collection method

Multiple forms of payments and various media issuance such as smart cards, online payments and standard magnetic cards

Multimodal transportation Travel that is performed with more than one mode of transportation

Normal operations When a signalized intersection is cycling through its pre-planned phases correctly, servicing all approaches, including pedestrian phases

Open-data Information that is freely available for anyone to use and republish as they wish

Open-source concepts The notion of open collaboration and voluntary contribution for software development by writing and exchanging programming code





Term Definition

Payment settlement The process by which funds are sent by an issuing bank to the CPS for processing and dispersal to the Transportation Network Companies

Performance metric A measurement used to determine how a project is performing

Personally Identifiable Information (PII)

Information used in security and privacy laws that can be used to identify an individual, such as vehicle, driver, and payment information

Parking facility Land or a structure used for light-duty vehicle parking

Parking management system A system intended to aggregate location, availability, payment information, and reservation capabilities across all public and private parking options

Procurement The act of obtaining or acquiring goods, services or works, from a competitive bidding process

Push notifications Alert users to relevant information pertaining to a route or selected mode of transportation, such as the approach of a transfer location, congestion or other impediment to travel, or pricing change

Quick Response barcode Commonly referred to as a QR Code. A barcode that stores information that can be used for marketing or sharing information and can be read using a digital device such as a cell phone

Real-time data Information that is delivered immediately after collection

Sidewalk Labs A Google company and a national partner in the USDOT Smart City Challenge

System analytics or data analytics

The analysis of data, procedures or business practices to locate information which can be used to create more efficient solutions

Third-party Organizations not affiliated with the Smart Columbus Program

TransitApp A free trip planning application available to users of iPhone or Android devices

Transportation Network Companies (TNCs)

Private businesses, non-profits, and quasi-governmental agencies that offer one or more types of transportation for use in exchange for payment

Travelers End users of the MMTPA/CPS

Unbanked users Unbanked users are those who pay for each transaction separately at the time of the trip request.

Unified parking availability and reservation system

One system that would allow parking availability information and reservations for parking lots and garages without concern for lot or garage ownership


U.S. Department of Transportation ITS Joint Program Office – HOIT

1200 New Jersey Avenue, SE Washington, DC 20590

Toll-Free “Help Line” 866-367-7487

www.its.dot.gov

[FHWA-JPO-17-523]

scc-b-conops mmtpa-cps final 20180810 › legacy › uploaded...2018/08/30 · the united states...

Documents