Fare Collection Data Profile ConOps AddendumMarch 18, 2010

Next Generation Transit Service Information Portal (TSIP):

Concept of Operations Addendum for Fare Collection

March 25, 2010

First Draft

by

Prepared for:

New York State Department of Transportation

1

Fare Collection Data Profile ConOps AddendumMarch 18, 2010

Revision Control Table
Filename / Version / Date / Changed by / Changes
TSIP_FC ConOps Addendum_v002 / v002 / 3-18-2010 / PXC / Initial Draft
TSIP_FC_ConOps_Addendum_v003 / v003 / 3-25-2010 / PEO / First Draft: Updated and edited

1

Fare Collection Data Profile ConOps AddendumMarch 18, 2010

Table of Contents

1.Introduction

1.1Identification

1.2Background

1.3Purpose of This Document

1.4Audience

2.Current System

2.1.Operational Constraints

2.2.Current Environment

2.3.Stakeholder Descriptions

2.4.Use of Fare Data by Stakeholders

2.5.Future Tools

3.Fare Collection Data Profile Concept

3.1.System Overview

4.Use Case Descriptions

4.1.Use Case Methodology

4.2.Use Case #1 – Regional Fare Calculator

4.3.Use Case #2 – Fare Policy Study

5.Enumeration of Needs

6.Roles and Responsibilities

Appendices

Appendix A: Glossary

Acronyms

Terms

Appendix B: Use Case #1: Regional Fare Calculator

Appendix C: Use Case #2: Fare Policy Study

Appendix D: Additional Operational Scenarios

Appendix E: White Paper

List of Tables

Table 1. Stakeholder Description

Table 2: Stakeholder - Actor Associations

Table 3: Actor Roles & Responsibilities

1

Fare Collection Data Profile ConOps AddendumMarch 18, 2010

1.Introduction

1.1Identification

This document is an addendum to the Concept of Operations (ConOps) for the Transit Service Information Portal (TSIP) that describes the needs and issues related to the TSIP Fare Collection Data Profile (FCDP). The purpose of this ConOps is to communicate the proposed data needs to support calculating fare costs as well as dissemination of fare cost to regional transit planners for their planning studies.

With the building blocks of TRIPS123, Schedule Data Profile (SDP), and Web Data Maintenance System (WDMS), and the commitment to develop and provide a state-of-the-art statewide multi-modal 511 service that appropriately showcases the unparalleled levels of transit service available in New York State, the New York State Department of Transportation (NYSDOT) is leading the development of a multi-agency Transit Service Information Portal (TSIP) to support a robust and flexible range of options for providing key stakeholder groups with comprehensive, high quality and useful information about transit service and travel choices. This portal will also provide operators with an efficient and economical means of supplying standardized transit service data, in published open formats, to each other for coordination of services; to vendors deploying ITS applications that require transit service data such as AVL; to regional planning organizations; and to multiple downstream information outlets for marketing the use of transit. This document explores and focuses exclusively on the needs of disseminating fare collection data for downstream fare calculations for regional transit planners and trip planning applications.

1.2Background

This TSIP Fare Collection ConOps Addendum builds upon the work already completed for the Transit Schedule Data Exchange Architecture (TSDEA) and the SDP. The TSDEA was designed as a framework for publishing regional transit data in a consistent format to enable the seamless exchange of information and launch regional and agency applications. The focus of the TSDEA project was to reach consensus among downstate New York operators on the requirements and preliminary implementation of common requirements to describe schedule and related transit service information. The effort resulted in a robust set of requirements and business rules that described the Schedule Data Profile (SDP). The SDP, a specification that describes the abstract data model for transit schedule and related data, included rules for its implementation into three exchange formats: XML document (using XML Schema and XML standards), comma separated version (CSV) files, and a physical data model. The New York operators are currently using the XML document version of the SDP to submit their schedule data to 511NY. The SDP will be leveraged to meet the data requirements of the Fare Collection Data Profile (FCDP).

The TSDEA project ConOps described an approach for registering, submitting and updating SDP data in the Data Exchange repository. The SDP implementation methods, particularly the SDP XML document submissions, validation procedures, naming practices and metadata issues were explored in some depth during that process. Incorporating the discussions, concerns and lessons learned from the TSDEA project, this project will extend the ConOps operational scenarios, needs and stakeholders and later the requirements, into a fully described “system” that supports the vision initially articulated for the TSDEA framework.

1.3Purpose of This Document

This document focuses on the user needs for the data requirements for the FCDP. Similar to the SDP, the FCDP will be a reference model that describes regional fare collection data needs for critical downstream studies and applications, such as a fare calculator. This document examines issues, processes and applications related to describing the data needs for fare collection within the context of operational scenarios. A white paper wasdeveloped describingthe existing standards development efforts that attempt to depict fare and transfer policies. While primarily focused on fare collection data standards, the white paper includes a discussion on a standard for describing a fare collection system architecture that helps categorize fare collection subsystems, and some discussion is on a few of the problems and issues related to developing a fare calculator. Many of the terms and subsystem descriptions are used in this document. For example, instead of using the term fare media, this document will use fare product which incorporates media and applications that are stored in mobile devices. These terms are included in the Glossary (see Appendix A: Glossary).

The primary sources of the user needs are:

  • Meetings with NYSDOT and with the Fare Collection Regional Stakeholder Technical Working Group (FC RSTWG).
  • White Paper on Fare Collection Standards Related to Fare Calculation and Pricing
  • Operational Scenarios that have been developed and revised by the stakeholders.

1.4Audience

This ConOps document aims to address two diverse audiences: (1) the stakeholders who would be the users and beneficiaries from the exchange of fare structure data; and (2) the systems and data technology specialists who will be taking the data needs and turning them into data requirements.

In the end result,this ConOps document should clearly describe to the stakeholders the data needsof the FCDP. In addition, the ConOps should articulate to the technical audience the needs, expectations and issues of the end uses of the data.

2.Current System

This section describes the current problems facing transit agencies and transportation planners who have need for transit fare information. The section also describes the operating environment, stakeholders, and existing infrastructure in which the FCDP will be deployed.

2.1.Operational Constraints

Transit agencies use transit fare structure data for a variety of reasons, particularly for trip planning purposes, and also, transportation network modeling and travel forecasting. Each is an analysis process that contributes significantly towards an agency’s and a region’s transportation planning.

There is currently no farestructure model for the collection and exchange of fare structure data for the region because of the diverse set of fare and transfer policies in the region. The lack of this model restricts how fartransit agencies and transportation authorities can exchange fare and transfer structures with each other, perform well-informed analysis for regional planning studies such as the impact of fares on a target audience, and provide regional transit tools, such as a fare calculator or clear transfer information for potential transit users.

A regional fare calculator is probably the most useful downstream application for developing a fare structure data model. With a regional fare calculator, travelers using trip planning functions can get accurate fare costs about their desired trips, even when the trip includes transfers between different agencies.

Some of the differences in fare structures for transit agencies in the region, and thus barriers to a regional fare calculator, include:

  • Different rider classes (seniors, students, children) and different definitions (seniors – above age 59, 62, or 65; children – below age 3, 6 or 12);
  • Different fare products (smart card, Metrocard, single-use card, passes)
  • Different service definitions (e.g., definition of peak hours, when holiday fares are in effect)

Some examples of how the absence of a plan and tools to support data exchange can impact an organization are included below:

  • Extra time is spent on repetitive redesign or customization of data and systems in response to each new application (within the organization and to support regional systems) that requires fare structure data.
  • Transportation models use incomplete or inaccurate fare structure data, resulting in inaccurate and poor forecasts and outputs.
  • Higher expenses can occur that are associated with the ongoing development and maintenance of custom data interfaces to support the exchange of data between different agencies and transportation models.

These organizational impacts constrain the effectiveness of initiatives intended to improve mobility, reliability and efficiency of the transit system. These internal constraints and problems become exponentially more complex and challenging when transit agencies must provide services in a regional and multi-modal context.

2.2.Current Environment

This documentconsiders the existing systems that drive or use transit fare structure data. An effort was undertaken to collect the fare structures published to customers on Operator web sites. A crude model of a fare structure was developed in an Access database (see Figure 1), fare structures were “scraped” from agency web sites and keyed into the database[1].

The data model for the inventory includes a list of each agency and their respective mode(s). This included sixteen agencies (some agencies had more than one mode). The list of agencies and their respective modes include:

  • CoachUSA
  • Dutchess County
  • Long Beach Transit (Nassau)
  • MTA Long Island Bus
  • MTA Long Island Rail Road
  • MTA Metro North Railroad
  • MTA New York Bus
  • MTA NYC Transit Bus
  • MTA NYC Transit Subway
  • New Jersey Transit Bus
  • New Jersey Transit Commuter Rail
  • New Jersey Transit Light Rail
  • Orange County
  • PATH
  • Putnam Area Rapid Transit
  • Suffolk County Transit
  • Tappen Zee Express
  • Transport of Rockland
  • Westchester Bee-Line Bus
  • Connecticut Transit

The model captures five rider classes – young child (or free), child, youth, disabled and senior. Each entry includes fields that describe the agency, their rider class name, the type of discount and any comment about the discount. The “age” related classes include a minimum or maximum age (or both), proof, and a comment about the eligibility. In some cases, the height of the child is needed. The requirements for ridership are diverse and inconsistent throughout the region, as is well known.

The data model (Figure 1) is described as follows:

A transit operator (Agency) has one or more fares (FC_Fare) for different types of services and modes it offers to the public. The fares are driven by the customer’s trip based on when he/she travels (FC_TimePeriod),origin-destination and path of travel (FC_Geographic_Fare_Structure), and one or more general rules (BR_BusinessRule_general) such as transfers (BR_Transfer) and eligible rider discounts (BR_Discount). The cost (BR_Discount) depends on the rider (RiderClass) or the group of people who are traveling (RC_Group).

1

Fare Collection Data Profile ConOps AddendumMarch 18, 2010

Figure 1: NY Regional Fare Structure Data Inventory

1

Fare Collection Data Profile ConOps AddendumMarch 18, 2010

In addition, a white paper, White Paper on Fare Collection Standards Related to Fare Calculation and Pricing, describes some of the existing standards that attempt to describe fare and transfer structures. While primarily focused on fare collection data standards, a discussion is included on a standard for describing a fare collection system architecture that helps categorize fare collection subsystems, and some of the problems and issues related to developing a regional fare calculator.

Although agreements exist to exchange transit fare structure dataand policies between agencies in the region, no standard format or process for exchanging this information currently exists. Data is generally exchanged on an ad-hoc basis and there is no standard updating process. Each transit organization uses paper, different references, and providesdifferent levels of detail when exchanging fare structures. This lack of a standard format for exchanging fare structure data is a barrierpreventing frequent updates of the transit fare structure databetween organizations.

One of the objectives of the FCDP is to describe and create a practical fare structure data model for New York. The model used for the inventory is limited, and doesn’t necessarily represent the comprehensive need to represents the diverse set of fare structure and transfer in the State. The model (which will be documented in the Requirements document) will be used to develop a schema wherein transit operators may describe their fare structure and transfer (internal and with each other) for use in a fare calculator and for regional planning studies.

2.3.Stakeholder Descriptions

The key stakeholders for the project are the transit agencies and oversight organizations that offer transit service in New York. These stakeholders are described in Table 1.

Table 1. Stakeholder Description

Agency / Description
New York State Department of Transportation (NYSDOT) / NYSDOT is a statewide agency which is divided into regions. The primary involvement of NYSDOT in the TSIP project comes from the Public Transportation Bureau and the organization that operates 511NY.
Transit Agencies / Represents all the individual transit operating agencies in the State of New York. Note, although the data inventory only included 16 agencies (some of whom were out of state, by reference, this category includes all the state public transit operators (including contracted services).
Regional Planning Agencies and Authorities / Represents all the regional planning agencies and regional authorities (e.g., MTA) included in the Planning ConOps[2] stakeholder table.
TRANSCOM / Provides support and incident management services for the NYC Metropolitan region.

Table 2 describes the actors who are involved in the fare collection process. For the purposes of this Concept of Operations, these Actors will be used to describe the players in the operational scenarios and high level requirements. In particular the use of the term “product” will serve to describe the fare media such as ticket or MetroCard. Value will be used to describe the cost including charge, money, etc. Application Contract refers to the implicit agreement between Customer and Service Operator for the value of a product, and its use.

Table 2. IFMS Actor Descriptions[3]

Actor / Description
Product Owner / The Product Owner is responsible for his Products.
Product Retailer / The Product Retailer sells and terminates Products, collects and refunds value to a customer as authorised by a Product Owner. The Product Retailer is the only financial interface between the customer and the IFMS related to Products.
Application Retailer / The Application Retailer sells and terminates Applications, collects and refunds value to a customer as authorised by an Application Owner. The Application Retailer is the only financial interface between the customer and the IFMS related to Applications.
Collection and Forwarding / The role of Collection and Forwarding is the facilitation of data interchanges of the IFMS. The general functions are data collection and forwarding.
Service Operator / The Service Operator provides a service to the customer against the use of a Product.
Application Owner / The Application Owner holds the Application Contract for the use of the Application with the customer.
Customer Service / Subject to commercial agreements, Customer Service may provide “helpline” and any similar facilities, including replacement of stolen and damaged Customer Medium and consequent Product reinstalling.
Customer / The Customer holds an Application and acquires Products in order to use the public transport services.

3.Fare CollectionData Profile Concept

The vision for the Fare Collection Data Profile is to represent a reference model for unambiguously describing transit fare collection data that ensures the semantic and syntactic interoperability of the data, thereby enabling the seamless exchange of high quality, reliable service information among regional planners, transit agency staff, and other regional/statewide stakeholders. The TSIP provides a framework in which transit fare structure data represented in the FCDP format may be accessed by authorized downstream applications, users, and systems.

3.1.System Overview

The vision for the Fare Collection Data Profile is to represent a reference model for unambiguously describing transit fare collection data that ensures the semantic and syntactic interoperability of the data, thereby enabling the seamless exchange of high quality, reliable fare structure and transfer data among stakeholders The TSIP provides a framework in which this fare structure information represented in the FCDP format may be accessed by authorized downstream applications, users, and systems.

This Concept of Operations describes the types of fare structure data supported by the FCDP. It communicates the users’ needs for and expectations for the FCDP. The types of data are described in the Use Cases, and enumerated in Section 5.

4.Use Case Descriptions

The FCDP needs will be driven by the data needs of the downstream applications. To this end, a series of Use Cases were developed with the participation of the stakeholders to identify the key data requirements for the FCDP.