Multimodal Trip Planning Application/Common Payment System … Trip Pla… · Multimodal Trip Planning Application/Common Payment System (MMTPA/CPS) Concept of Operations for the

Multimodal Trip Planning Application/Common Payment System (MMTPA/CPS) Concept of Operations

for the Smart Columbus Demonstration Program

FINAL REPORT | August 10, 2018

Produced by City of Columbus

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.

MMTPA/CPS Concept of Operations – Final Report | Smart Columbus Program | i

Table of Contents

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

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

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

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

1.1.3. Geographic Scope ........................................................................................................... 6

1.2. Project Relation to the System of Systems ........................................................................... 7

1.3. High-Level Components ........................................................................................................... 8

1.3.1. Travelers .......................................................................................................................... 8

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

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

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

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

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

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

1.3.8. Regional Systems .......................................................................................................... 14

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

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

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

2.1.2. Cluster Sampling Field Surveys ..................................................................................... 20

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

2.1.4. Linden Residential District ............................................................................................. 21

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

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

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

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

3.4. Operational Policies and Constraints .................................................................................. 25

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

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

3.6. Modes of Operation for the Current System ....................................................................... 29

3.7. User Classes of the Current System .................................................................................... 30

Table of Contents

ii | Smart Columbus Program | MMTPA/CPS Concept of Operations – Final Report

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

4.1. Justification for Changes ....................................................................................................... 32

4.2. Description of Desired Changes ........................................................................................... 34

4.3. Priorities Among Changes ..................................................................................................... 49

4.4. Changes Considered but not Included ................................................................................ 51

4.4.1. Connection Protection ................................................................................................... 51

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

Machines ........................................................................................................................ 51

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

5.1. Background, Objectives and Scope ..................................................................................... 53

5.1.1. Goal No.1: Enhanced Mobility ....................................................................................... 53

5.1.2. Goal No. 2: Enhanced Access to Opportunities and Service ........................................ 54

5.1.3. Goal No. 3: Increased Customer Satisfaction ............................................................... 54

5.2. Operational Policies and Constraints .................................................................................. 56

5.3. Description of Proposed System .......................................................................................... 57

5.4. Operating System (Central System) ..................................................................................... 59

5.4.1. Trip Optimization ............................................................................................................ 59

5.4.2. Mobility Providers .......................................................................................................... 60

5.4.3. Data Services................................................................................................................. 60

5.4.4. Trip and Payment Data .................................................................................................. 60

5.4.5. Payment Broker Service ................................................................................................ 60

5.5. Common Payment System Back-Office .............................................................................. 61

5.5.1. Common Payment System Payment Processor/Gateway ............................................ 61

5.5.2. Common Payment System Accounts ............................................................................ 61

5.6. Central Ohio Transit Agency Fare Management System ................................................. 63

5.7. Mobility Provider Systems ..................................................................................................... 63

5.7.1. Fixed-Route Mobility Providers ...................................................................................... 63

5.7.2. On-Demand Mobility Providers ...................................................................................... 64

5.8. Shared Vehicle Providers ....................................................................................................... 65

5.8.1. Ride-Sharing Providers .................................................................................................. 65

5.9. Transaction Equipment .......................................................................................................... 65

5.9.1. Traveler Web Portal ....................................................................................................... 65

5.9.2. Central Ohio Transit Agency Ticket Vending Machine .................................................. 65

5.9.3. Central Ohio Transit Agency Farebox ........................................................................... 66

5.9.4. Smart Mobility Hubs ....................................................................................................... 66

5.9.5. Interactive Voice Response System .............................................................................. 66

5.10. Multimodal Trip Planning App ............................................................................................... 66

Table of Contents

MMTPA/CPS Concept of Operations – Final Report | Smart Columbus Program | iii

5.10.1. Interface with Operating System.................................................................................... 67

5.10.2. Interface with Transaction Equipment ........................................................................... 67

5.10.3. User Preferences ........................................................................................................... 67

5.10.4. Incentives/Rewards ....................................................................................................... 68

5.11. Modes of Operation for the Proposed System ................................................................... 68

5.12. User Classes and Other Involved Personnel ...................................................................... 70

5.13. Support Environment ............................................................................................................. 72

5.14. Security and Privacy ............................................................................................................... 72

5.14.1. Payment Card Industry Compliance .............................................................................. 73

5.14.2. Personally Identifiable Information................................................................................. 74

5.14.3. Operating System Security ............................................................................................ 74

Chapter 6. Operational Scenarios .............................................................................................. 77

Chapter 7. Summary of Impacts ............................................................................................... 117

7.1. Challenges .............................................................................................................................. 117

7.2. Operational Impacts .............................................................................................................. 117

7.3. Organizational Impacts ......................................................................................................... 117

7.4. Impacts During Development .............................................................................................. 117

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

8.1. Summary of Improvements ................................................................................................. 119

8.2. Disadvantages and Limitations ........................................................................................... 119

8.3. Alternatives and Trade-Offs Considered ........................................................................... 119

Chapter 9. Notes ........................................................................................................................ 123

Appendix A. Stakeholder Engagement Summary ............................................................. 125

Appendix B. Acronyms and Definitions ............................................................................... 135

Appendix C. Glossary........................................................................................................... 139

Table of Contents

iv | Smart Columbus Program | MMTPA/CPS Concept of Operations – Final Report

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 ...................................................................... 29

Table 5: Current System Users ................................................................................................................... 30

Table 6: Justification for Changes ............................................................................................................... 32

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

Table 8: User Needs .................................................................................................................................... 36

Table 9: Priorities Among Changes ............................................................................................................. 49

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

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

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

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

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

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

Table 16: Proposed System Users .............................................................................................................. 70

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

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

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

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

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

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

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

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

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

Alerts ........................................................................................................................................................... 97

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

Trip Segments ........................................................................................................................................... 100

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

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

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

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

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

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

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

Table 34: Summary of Improvements ....................................................................................................... 119

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

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

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

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

Table of Contents

MMTPA/CPS Concept of Operations – Final Report | Smart Columbus Program | v

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

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

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

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

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

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

Table 45: Acronym List .............................................................................................................................. 135

Table 46: Glossary .................................................................................................................................... 139

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 .............................................................................................................. 28

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

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

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

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

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

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

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

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

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

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

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

System ...................................................................................................................................................... 113

MMTPA/CPS Concept of Operations – Final Report | Smart Columbus Program | 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 | Smart Columbus Program | MMTPA/CPS Concept of Operations – Final Report

1.1. 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



1.1.1. 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



1.1.2. 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.



1.1.3. 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



1.2. 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 environment. 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.



1.3. 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

1.3.1. 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.

1.3.2. 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.

1.3.3. Common Payment System Payment Broker

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

System.

1.3.4. 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.

1.3.5. 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).

1.3.6. 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.

1.3.6.1. 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).

1.3.6.1.1 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.

1.3.6.2. 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.

1.3.6.3. 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.

1.3.6.4. 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.

1.3.6.5. 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.



1.3.6.6. 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.

1.3.6.7. 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/).

1.3.6.7.1 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

1.3.6.7.2 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

1.3.6.7.3 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

https://www.cota.com/mobility-services/




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.

1.3.6.8. 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.

1.3.7. 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.

1.3.7.1. Relationship to Proposed System

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.



1.3.8. Regional Systems

1.3.8.1. 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.

1.3.8.2. 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/applica

tion/

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/legislati

on-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

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

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

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

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

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

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

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

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

http://www.sharedusemobilitycenter.org/wp-content/uploads/2016/10/Reference-Guide-Editsweb-version-10.24.2016.pdf





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

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

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



Meeting Title Date

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

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



Meeting Title Date

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

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


2.1. 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

2.1.1. 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.

2.1.2. 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.

2.1.3. 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.



2.1.4. 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.

3.1. 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.

3.2. 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.

3.3. 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).

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

industry.

3.4. 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.

2 Ford Greenfield Labs: Columbus Mobility Design Research Report



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.

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). Source: City of Columbus

http://www.cota.com/data



3.5. DESCRIPTION OF CURRENT SYSTEM

3.5.1. 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.

3.6. 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



3.7. 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.



4.1. 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.




4.2. 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.



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

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.

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.



4.3. 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



Rank Title Priority

Classification

User Need

20 Pay Once Essential MMTPA/CPS-UN025-v02

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

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



Rank Title Priority

Classification

User Need

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


4.4. CHANGES CONSIDERED BUT NOT INCLUDED

4.4.1. 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.

4.4.2. 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.

5.1. 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

5.1.1. 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

http://calculator.sharedusemobilitycenter.org/



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

5.1.2. 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.

5.1.3. 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.

5.1.3.1. 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.



Objective Hypothesis

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.


5.1.3.2. 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.



5.2. 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.


5.3. 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



5.4. 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.

5.4.1. 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.

5.4.2. 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.

5.4.3. 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.

5.4.4. 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.

5.4.5. 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.



5.5. 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.

5.5.1. 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.

5.5.2. 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

Sub-Component Description

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.


5.6. CENTRAL OHIO TRANSIT AGENCY FARE MANAGEMENT

SYSTEM

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

Management system.

5.7. 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.

5.7.1. 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.



5.7.2. 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.



5.8. 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)

5.8.1. 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.

5.9. 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.

5.9.1. 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.

5.9.2. 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.

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



5.9.3. 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.

5.9.4. 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.

5.9.5. 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.

5.10. 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.



5.10.1. 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.

5.10.2. 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.

5.10.3. 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

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




5.10.4. 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.

5.11. 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.



Mode Definition

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.

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.




5.12. 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.


5.13. 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.

5.14. 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.



5.14.1. 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.

https://www.pcisecuritystandards.org/security_standards/documents.php



5.14.2. 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).

5.14.3. 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

http://owasp.org/

https://www.owasp.org/index.php/OWASP_Proactive_Controls



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

DownloadYes

No

Install?

End

Launch

MMTPA?

No

Continue to use

appYes


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

links to “Read More.” Also

displayed are User Reviews,

ability to “Rate this App”, and

option to Install.

Experience may

vary depending

on which App

Store is required

based on device

type.



Use Case Traveler Installs and Launches the MMTPA

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

Operational

Event(s)

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

Key Actions and

Flow of Events


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

Policies and

Business Rules

User preferences are included in trip optimization by the Operating System

User Needs

Traceability

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

Operational

Event(s)

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

Key Actions and

Flow of Events


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.




Policies and

Business Rules

N/A

User Needs

Traceability MMTPA/CPS-UN001-v02 Real-Time Travel Information


MMTPA/CPS-UN008-v02 Notifications and Alerts

MMTPA/CPS-UN015-v02 Trip Optimization



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

Operational

Event(s)

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

Key Actions and

Flow of Events


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-

share and unlocks the bike. The

authentication and unlock

process takes under a second.

If there were NFC

readers at the

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

Policies and

Business Rules

N/A

User Needs

Traceability

MMTPA/CPS-UN003-v02 Real-Time Travel Information


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

Operational

Event(s)


Actor(s) Actor Role







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

Key Actions and

Flow of Events


MMPTA 6 MMTPA prompts the Traveler

there are no available bikes at

the docking station. (A group of

tourists have rented all the

bikes.).

As a policy, it is

not possible to

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.


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




Policies and

Business Rules

N/A

User Needs

Traceability 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

Operational

Event(s)


Actor(s) Actor Role







Pre-conditions Scenario picks up from Step 13 of UC4-S2

Key Actions and

Flow of Events


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.


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




Policies and

Business Rules

N/A

User Needs

Traceability 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.

Operational

Event(s)

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

Key Actions and

Flow of Events


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

Updates via text

or email can be

provided to users



Use Case Traveler Without Smartphone Uses IVR System to Activate PMLM Trip

provided to help the Traveler

identify it.

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

Policies and

Business Rules

The IVR system is needed by the City to meet Title VI compliance for the

MMTPA/CPS.

User Needs

Traceability MMTPA/CPS-UN015-v02 Trip Optimization

MMTPA/CPS-UN016-v02 IVR System


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

Operational

Event(s)

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

Key Actions and

Flow of Events

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.





for personal information

including name, address,

telephone number, e-mail

address.

Traveler 8 The Traveler enters his/her

personal information and selects

continue.


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

Policies and

Business Rules

None

Traceability MMTPA/CPS-UN017-v02 Same-Day Paratransit Service




MMTPA/CPS-UN022-v02 CPS Account

MMTPA/CPS-UN023-v02 Payment Media


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

Operational

Event(s)

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

Key Actions and

Flow of Events


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.


Traveler to the CPS account

management interface.

Redirection

should be




Automated Alerts

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.


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,




Automated Alerts

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.


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




Automated Alerts

$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

Policies and

Business Rules

N/A

User Needs

Traceability MMTPA/CPS-UN022-v02 CPS Account

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.

Operational

Event(s)

Log into CPS, update account settings





Actor(s) Actor Role





Key Actions and

Flow of Events


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.


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.


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.






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

Policies and

Business Rules

N/A

User Needs

Traceability


MMTPA/CPS-UN022-v02 CPS Account


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

Operational

Event(s)

Reset password

Actor(s) Actor Role






Use Case Traveler Recovers Lost CPS Password


Key Actions and

Flow of Events


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.


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

Policies and

Business Rules

N/A

User Needs


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.

Operational

Event(s)

Delete account

Actor(s) Actor Role





Key Actions and

Flow of Events


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.


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

Deleting CPS

account does not

remove

anonymized trip

information from

the Operating

System.



Use Case Traveler Closes CPS Account

prompts the Traveler to continue

or cancel.

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.

Policies and

Business Rules

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.

User Needs


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

Operational

Event(s)

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




Key Actions and

Flow of Events

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.


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.


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

Policies and

Business Rules

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.


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.

Operational

Event(s)

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

Key Actions and

Flow of Events


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



Use Case Mobility Provider Establishes an Account in the Operating System

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

Policies and

Business Rules

N/A

User Needs

Traceability

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.

Operational

Event(s)

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.




Use Case Mobility Provider Manages CPS Account

Key Actions and

Flow of Events

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.

Policies and

Business Rules

N/A

User Needs

Traceability 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

Operational

Event(s)

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.

City of Columbus Members of the City with unrestricted access to data for

reporting and analytics purposes.

Pre-conditions N/A




Use Case City of Columbus User Retrieves Data from Operating System

Key Actions and

Flow of Events

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

Policies and

Business Rules

Data does not include PII

User Needs

Traceability 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

Operational

Event(s)

View reports, configure reports, access data through APIs

Actor(s) Actor Role



Use Case Third-Party User Retrieves Data from Operating System

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

Key Actions and

Flow of Events


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.

Post-Conditions N/A

Policies and

Business Rules

Data does not include PII

User Needs

Traceability 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.

7.1. 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?

7.2. 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.

7.3. 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

be responsible for integrating with the Operating System to allow for trip planning and trip payment

services through the MMPTA/CPS system.

7.4. 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

Chapter 7. Summary of Impacts


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.

8.1. 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


8.2. 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.

8.3. 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 Priorities

Among Changes.

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


Among Changes.

Leverage Transit App Utilize an existing

mobile app with well-

established user base


project needs as


Among Changes.

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


project needs as


Among Changes.

Does not fit into the

Operating System

Product Vision and

operating goals. Poses

financial and user

privacy security risks.



Trade-offs/Alternatives Description Decision Rationale

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


Among Changes. 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

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,

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

Chapter 9. Notes


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

A.1 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

i. 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

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

A.2 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.

A.2.1 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%



Obstacles Number of Responses % of Respondents

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%


A.2.2 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


Documents

Multimodal Trip Planning Application/Common Payment System … Trip Pla… · Multimodal Trip Planning Application/Common Payment System (MMTPA/CPS) Concept of Operations for the