Review of Fare Collection Concept of Operations and High Level Data Requirements FC RSTWG Webinar May 19, :30 – 4 pm Prepared by: Paula Okunieff, ConSysTec

Use Cases / Scenarios Regional Fare Calculator (Appendix B-1) Marketing Study related to Fare Elasticity (Appendix B-2) ◦Operational Scenario #1: Service Improvements for Low Income/Welfare Populations ◦Operational Scenario #2: Ridership Improvement Study

Fare Calculator System Description Trip Plan (API) Rider Characteristics / Usage Promotion / Restrictions Transfer Rules General Cost Interagency Transfer Rules Fare Cost API (for Trip Plan) Fare Calculator Customer Data InputsData OutputsProcesses

Fare Collection: Needs [N-1] Need for a Trip Planning API. [N-2] Need for Customer Characteristics and Usage to describe Rider Characteristics and Preferences. [N-3] Need for information from Providers / Carriers on fares, fare promotions and restrictions. [N-4] Need for information from Providers / Carriers on transfer rules. [N-5] Need for information from two or more Providers / Carriers on their agreements for transfer between services. [N-6] Need for fare cost interface

[N-1] Data Needs Need for Trip Planning API w/Info Trip Planning API will trigger the request for estimated Fare Cost for a specific trip. The information in the API should include the following: Origin (first stop – locationID and related agencyID) Scheduled start time / date Destination (last stop – locationID and related agencyID) Scheduled completion time / date Number of legs Parking (enter and leave) -- optional For each Leg ◦Provider ◦Mode ◦Route, route direction ◦Trip information: tripID, service type, day type ◦Starting trip time and location ◦Ending trip time and location ◦Distance between starting and ending location

[N-2] Data Needs Need for Customer Information and Usage Info Fare information should include information on rider characteristics and usage such as: Rider class Number of riders Preference for fare products Other characteristics Number of people traveling For each person ◦Age (if a child – under 13 yrs old, then the child’s height) ◦Eligibility [disabled, student, senior, regular] ◦Preference for fare product ◦Other criteria (e.g., return trip ticket, frequent traveler, etc.)

[N-3] Data Needs Need for Fares, Fare Promotions and Restrictions The fare promotions / restrictions should be tagged to one or more of the following parameters… Note: fare structure may be flat, zone, distance and/or time based From N-1 Data ◦Carrier ◦Mode ◦Origin, destination or both ◦Route, route direction ◦Trip information ◦Departure date / time ◦Day type From N-2 Data ◦Fare product type and use ◦Number of travelers ◦Rider class ◦If available from N-2 data  Frequency of travel  Payment option  Product purchase time / location

[N-4] Data Needs Need for Transfer Rules (for each Provider) Each Provider / Carrier should provide information on Transfer Rules. Information derived from the Trip Plan API [N-1] include… Mode to mode Route direction of previous and next trips [order of trip legs] Arrival (or departure) time of previous trip and departure time of next trip Additional information (derived from fare media): ◦Shared or bundled fare product(s) for trips (trip plan)

[N-5] Data Needs Need for Transfer Rules between Providers Provide information on Transfer Rules between Carriers. Information derived from the Trip Plan API [N-1] include… Carrier to carrier Rider class definition Mode to mode Route, route direction (of previous and next trip legs) Arrival (or departure) time of previous trip and departure time of next trip Additional information (derived from fare media): ◦Shared or bundled fare product(s) for trips (trip plan)

[N-6] Data Needs Need for Fare Cost API Interface that provides information on Fare Cost Trip Plan (from N-1) Total base cost Additional information (derived from fare media): ◦Shared or bundled fare product(s) for trips (trip plan)

Moving towards Requirements Describe Data Requirements ◦Define Data Concepts, entities and attributes ◦Describe relationship model (ERD)

Fare Data Model A CUSTOMER generates a PASSENGER TRIP PLAN (PTP). The PTP is composed of one or more LEGs from the CUSTOMER’s ORIGIN to DESTINATION. Each LEG (start and end points; start and end times) is associated with a segment of an AGENCY’s TRIP. (The TRIP is also associated with a MODE-specific TRANSIT VEHICLE, trip type, and other service features.) The FARE may be based on the GEOGRAPHIC UNITs traversed (e.g., DISTANCE traveled, or number of ZONES passed through) for each LEG (ORIGIN to DESTINATION), and the TIME PERIOD (time, date, and duration) when the LEG is to occur. When the PTP has more than one LEG, the total FARE may be the sum of FAREs for each LEG, or the CUSTOMER may transfer (be granted ACCESS RIGHTs) from one TRIP to another with a DEFAULT FARE or composite FARE based on the implementation of BUSINESS RULEs including DISCOUNTs and USAGE FACTORs. The CUSTOMER may purchase one or more FARE PRODUCTs that allow the CUSTOMER a variety of ACCESS RIGHTS to travel and transfer over different GEOGRAHPIC UNITs (Distance/Zones), TIME PERIODs (day type, length of days, time interval during a day*, date*, month*), and between AGENCYs, SERVICE TYPEs (i.e., express vs. local) and MODEs, sometimes governed by the ORDER OF TRAVEL. A BUSINESS RULE may be applied to the FARE COST based on the FARE PRODUCT used, or different USAGE FACTORS such as round trip fares, restricted geographic region, FARE TRANSACTION LOCATION, or the CHARGING METHOD applied to purchase the FARE. Additionally, a DISCOUNT may be applied based on number of people traveling (group and family “tickets”), rider class type, or marketing campaign. * Associated with a “named” period of time, e.g., 7am-10am, , September

Fare Cost… is the intersection of Passenger Trip Plan (N-1), Fare Structure (N-3) and Access Rights (Business Rules) (N-2 to N-5) and how it applies to the Customer(s) (N-2)

Fare Structure [N-3] Each trip has a “default fare” based on an Agency’s Fare Structure for different classes of riders.

Trip Plan [N-1] Description

Access Rights / Business Rules [N-2, N-3, N-4, N-5] Access rights are one or more business rules

Customer Description One or more customers may be associated with the PTP or the FARE

Next Steps Augment model to map to needs Refine language in ConOps to better express data concepts in Data Requirements Publish Systems Engineering Documents (due late June) ◦Final Concept of Operations ◦Draft Data Requirements for Fare Collection