PT04: Transit Fare Collection Management
This service package manages transit fare collection on-board transit vehicles and at transit stops using electronic means. It allows transit users to use a traveler card or other electronic payment device such as a smart phone. Readers located either in the infrastructure or on-board the transit vehicles enable electronic fare payment. Data is processed, stored, and displayed on the transit vehicle and communicated as needed to the Transit Management Center. This service supports ad-hoc payments to the transport provider (typically through the 'payment' and 'fare' flows), payments using a transport provider's account system using account-based tokens or integrated multi-provider account systems (typically through the 'account', 'secureID' and 'authorization' flows).
Relevant Regions: Australia, Canada, European Union, and United States
- Enterprise
- Functional
- Physical
- Goals and Objectives
- Needs and Requirements
- Sources
- Security
- Standards
- System Requirements
Enterprise
Development Stage Roles and Relationships
Installation Stage Roles and Relationships
Operations and Maintenance Stage Roles and Relationships
(hide)
Source | Destination | Role/Relationship |
---|---|---|
Enforcement Center Maintainer | Enforcement Center | Maintains |
Enforcement Center Manager | Enforcement Center | Manages |
Enforcement Center Owner | Enforcement Center Maintainer | System Maintenance Agreement |
Enforcement Center Owner | Enforcement Center Manager | Operations Agreement |
Enforcement Center Supplier | Enforcement Center Owner | Warranty |
Financial Center Maintainer | Financial Center | Maintains |
Financial Center Manager | Financial Center | Manages |
Financial Center Owner | Financial Center Maintainer | System Maintenance Agreement |
Financial Center Owner | Financial Center Manager | Operations Agreement |
Financial Center Owner | Payment Administration Center Owner | Information Provision Agreement |
Financial Center Owner | Transit Management Center Owner | Information Exchange Agreement |
Financial Center Supplier | Financial Center Owner | Warranty |
Other Transit Management Centers Maintainer | Other Transit Management Centers | Maintains |
Other Transit Management Centers Manager | Other Transit Management Centers | Manages |
Other Transit Management Centers Owner | Other Transit Management Centers Maintainer | System Maintenance Agreement |
Other Transit Management Centers Owner | Other Transit Management Centers Manager | Operations Agreement |
Other Transit Management Centers Owner | Transit Management Center Owner | Information Exchange Agreement |
Other Transit Management Centers Supplier | Other Transit Management Centers Owner | Warranty |
Payment Administration Center Maintainer | Payment Administration Center | Maintains |
Payment Administration Center Manager | Payment Administration Center | Manages |
Payment Administration Center Owner | Payment Administration Center Maintainer | System Maintenance Agreement |
Payment Administration Center Owner | Payment Administration Center Manager | Operations Agreement |
Payment Administration Center Owner | Personal Information Device Owner | Information Exchange Agreement |
Payment Administration Center Owner | Transit Management Center Owner | Information Exchange Agreement |
Payment Administration Center Supplier | Payment Administration Center Owner | Warranty |
Payment Device Maintainer | Payment Device | Maintains |
Payment Device Manager | Payment Device | Manages |
Payment Device Manager | Traveler | System Usage Agreement |
Payment Device Owner | Payment Device Maintainer | System Maintenance Agreement |
Payment Device Owner | Payment Device Manager | Operations Agreement |
Payment Device Owner | Transit Vehicle OBE Owner | Expectation of Data Provision |
Payment Device Owner | Transit Vehicle OBE Owner | Information Exchange and Action Agreement |
Payment Device Owner | Traveler Support Equipment Owner | Expectation of Data Provision |
Payment Device Supplier | Payment Device Owner | Warranty |
Personal Information Device Maintainer | Personal Information Device | Maintains |
Personal Information Device Manager | Personal Information Device | Manages |
Personal Information Device Manager | Traveler | System Usage Agreement |
Personal Information Device Owner | Payment Administration Center Owner | Information Exchange and Action Agreement |
Personal Information Device Owner | Personal Information Device Maintainer | System Maintenance Agreement |
Personal Information Device Owner | Personal Information Device Manager | Operations Agreement |
Personal Information Device Owner | Transit Management Center Owner | Information Exchange and Action Agreement |
Personal Information Device Supplier | Personal Information Device Owner | Warranty |
Transit Management Center Maintainer | Transit Management Center | Maintains |
Transit Management Center Manager | Transit Management Center | Manages |
Transit Management Center Manager | Transit Operations Personnel | System Usage Agreement |
Transit Management Center Owner | Enforcement Center Owner | Information Provision Agreement |
Transit Management Center Owner | Financial Center Owner | Information Exchange Agreement |
Transit Management Center Owner | Other Transit Management Centers Owner | Information Exchange Agreement |
Transit Management Center Owner | Payment Administration Center Owner | Information Exchange Agreement |
Transit Management Center Owner | Personal Information Device Owner | Information Exchange Agreement |
Transit Management Center Owner | Transit Management Center Maintainer | System Maintenance Agreement |
Transit Management Center Owner | Transit Management Center Manager | Operations Agreement |
Transit Management Center Owner | Transit Vehicle OBE Owner | Information Exchange Agreement |
Transit Management Center Owner | Transportation Information Center Owner | Information Exchange Agreement |
Transit Management Center Owner | Traveler Support Equipment Owner | Information Exchange Agreement |
Transit Management Center Supplier | Transit Management Center Owner | Warranty |
Transit Operations Personnel | Transit Management Center | Operates |
Transit Vehicle OBE Maintainer | Transit Vehicle OBE | Maintains |
Transit Vehicle OBE Manager | Transit Vehicle OBE | Manages |
Transit Vehicle OBE Manager | Transit Vehicle Operator | System Usage Agreement |
Transit Vehicle OBE Owner | Payment Device Owner | Expectation of Data Provision |
Transit Vehicle OBE Owner | Transit Management Center Owner | Information Exchange Agreement |
Transit Vehicle OBE Owner | Transit Vehicle OBE Maintainer | System Maintenance Agreement |
Transit Vehicle OBE Owner | Transit Vehicle OBE Manager | Operations Agreement |
Transit Vehicle OBE Supplier | Transit Vehicle OBE Owner | Warranty |
Transit Vehicle Operator | Transit Vehicle OBE | Operates |
Transportation Information Center Maintainer | Transportation Information Center | Maintains |
Transportation Information Center Manager | Transportation Information Center | Manages |
Transportation Information Center Owner | Transit Management Center Owner | Information Exchange Agreement |
Transportation Information Center Owner | Transportation Information Center Maintainer | System Maintenance Agreement |
Transportation Information Center Owner | Transportation Information Center Manager | Operations Agreement |
Transportation Information Center Supplier | Transportation Information Center Owner | Warranty |
Traveler | Payment Device | Operates |
Traveler | Personal Information Device | Operates |
Traveler | Traveler Support Equipment | Operates |
Traveler Support Equipment Maintainer | Traveler Support Equipment | Maintains |
Traveler Support Equipment Manager | Traveler | System Usage Agreement |
Traveler Support Equipment Manager | Traveler Support Equipment | Manages |
Traveler Support Equipment Owner | Payment Device Owner | Expectation of Information Provision |
Traveler Support Equipment Owner | Transit Management Center Owner | Information Exchange Agreement |
Traveler Support Equipment Owner | Traveler Support Equipment Maintainer | System Maintenance Agreement |
Traveler Support Equipment Owner | Traveler Support Equipment Manager | Operations Agreement |
Traveler Support Equipment Supplier | Traveler Support Equipment Owner | Warranty |
Functional
This service package includes the following Functional View PSpecs:
Physical
The physical diagram can be viewed in SVG or PNG format and the current format is SVG.SVG Diagram
PNG Diagram
Includes Physical Objects:
Physical Object | Class | Description |
---|---|---|
Enforcement Center | Center | The 'Enforcement Center' represents the systems that receive reports of violations detected by various ITS facilities including individual vehicle emissions, lane violations, toll violations, CVO violations, etc. |
Financial Center | Center | The 'Financial Center' represents the organization that handles electronic fund transfer requests to enable the transfer of funds from the user of the service to the provider of the service. The functions and activities of financial clearinghouses are covered by this physical object. |
Other Transit Management Centers | Center | Representing another transit operations center, 'Other Transit Management Centers' is intended to provide a source and destination for information flows between peer transit management centers. It enables transit management activities to be coordinated across geographic boundaries or jurisdictions. |
Payment Administration Center | Center | The 'Payment Administration Center' provides general payment administration capabilities and supports the electronic transfer of funds from the customer to the transportation system operator or other service provider. Charges can be recorded for tolls, vehicle-mileage charging, congestion charging, or other goods and services. It supports traveler enrollment and collection of both pre-payment and post-payment transportation fees in coordination with the financial infrastructure supporting electronic payment transactions. The system may establish and administer escrow accounts depending on the clearinghouse scheme and the type of payments involved. It may post a transaction to the customer account, generate a bill (for post-payment accounts), debit an escrow account, or interface to a financial infrastructure to debit a customer designated account. It supports communications with the ITS Roadway Payment Equipment to support fee collection operations. As an alternative, a wide-area wireless interface can be used to communicate directly with vehicle equipment. It also sets and administers the pricing structures and may implement road pricing policies in coordination with the Traffic Management Center. |
Payment Device | Personal | The 'Payment Device' enables the electronic transfer of funds from the user of a service (I.e. a traveler) to the provider of the service. Potential implementations include smart cards that support payment for products and services, including transportation services and general purpose devices like smart phones that support a broad array of services, including electronic payment. In addition to user account information, the payment device may also hold and update associated user information such as personal profiles, preferences, and trip histories. |
Personal Information Device | Personal | The 'Personal Information Device' provides the capability for travelers to receive formatted traveler information wherever they are. Capabilities include traveler information, trip planning, and route guidance. Frequently a smart phone, the Personal Information Device provides travelers with the capability to receive route planning and other personally focused transportation services from the infrastructure in the field, at home, at work, or while en-route. Personal Information Devices may operate independently or may be linked with vehicle on-board equipment. This subsystem also supports safety related services with the capability to broadcast safety messages and initiate a distress signal or request for help. |
Transit Management Center | Center | The 'Transit Management Center' manages transit vehicle fleets and coordinates with other modes and transportation services. It provides operations, maintenance, customer information, planning and management functions for the transit property. It spans distinct central dispatch and garage management systems and supports the spectrum of fixed route, flexible route, paratransit services, transit rail, and bus rapid transit (BRT) service. The physical object's interfaces support communication between transit departments and with other operating entities such as emergency response services and traffic management systems. |
Transit Operations Personnel | Center | 'Transit Operations Personnel' represents the people that are responsible for fleet management, maintenance operations, and scheduling activities of the transit system. These different roles represent a variety of individuals in the transit industry. Within the transit industry the person responsible for fleet management is known by many names: Street Supervisor, Starter, Dispatcher, Supervisor, Traffic Controller, Transportation Coordinator. This person actively monitors, controls, and modifies the transit fleet routes and schedules on a day to day basis (dynamic scheduling). The modifications will take account of abnormal situations such as vehicle breakdown, vehicle delay, detours around work zones or incidents (detour management, connection protection, and service restoration), and other causes of route or schedule deviations. Transit operations personnel are also responsible for demand responsive transit operation and for managing emergency situations within the transit network such as silent alarms on board transit vehicles, or the remote disabling of the vehicle. In addition the Transit Operations Personnel may be responsible for assigning vehicle operators to routes, checking vehicle operators in and out, and managing transit stop issues. This object also represents the personnel in the transit garage that are responsible for maintenance of the transit fleets, including monitoring vehicle status, matching vehicles with operators, and maintenance checking of transit vehicles. Finally, it represents the people responsible for planning, development, and management of transit routes and schedules. |
Transit Vehicle OBE | Vehicle | The Transit Vehicle On-Board equipment (OBE) resides in a transit vehicle and provides the sensory, processing, storage, and communications functions necessary to support safe and efficient movement of passengers. The types of transit vehicles containing this physical object include buses, paratransit vehicles, light rail vehicles, other vehicles designed to carry passengers, and supervisory vehicles. It collects ridership levels and supports electronic fare collection. It supports a traffic signal prioritization function that communicates with the roadside physical object to improve on-schedule performance. Automated vehicle location enhances the information available to the transit operator enabling more efficient operations. On-board sensors support transit vehicle maintenance. The physical object supports on-board security and safety monitoring. This monitoring includes transit user or vehicle operator activated alarms (silent or audible), as well as surveillance and sensor equipment. The surveillance equipment includes video (e.g. CCTV cameras), audio systems and/or event recorder systems. It also furnishes travelers with real-time travel information, continuously updated schedules, transfer options, routes, and fares. A separate 'Vehicle OBE' physical object supports the general vehicle safety and driver information capabilities that apply to all vehicles, including transit vehicles. The Transit Vehicle OBE supplements these general capabilities with capabilities that are specific to transit vehicles. |
Transit Vehicle Operator | Vehicle | The 'Transit Vehicle Operator' represents the person that receives and provides additional information that is specific to operating the ITS functions in all types of transit vehicles. The information received by the operator would include status of on-board systems. Additional information received depends upon the type of transit vehicle. In the case of fixed route transit vehicles, the Transit Vehicle Operator would receive operator instructions that might include actions to take to correct schedule deviations. In the case of flexible fixed routes and demand response routes the information would also include dynamic routing or passenger pickup information. |
Transportation Information Center | Center | The 'Transportation Information Center' collects, processes, stores, and disseminates transportation information to system operators and the traveling public. The physical object can play several different roles in an integrated ITS. In one role, the TIC provides a data collection, fusing, and repackaging function, collecting information from transportation system operators and redistributing this information to other system operators in the region and other TICs. In this information redistribution role, the TIC provides a bridge between the various transportation systems that produce the information and the other TICs and their subscribers that use the information. The second role of a TIC is focused on delivery of traveler information to subscribers and the public at large. Information provided includes basic advisories, traffic and road conditions, transit schedule information, yellow pages information, ride matching information, and parking information. The TIC is commonly implemented as a website or a web-based application service, but it represents any traveler information distribution service. |
Traveler | Personal | The 'Traveler' represents any individual who uses transportation services. The interfaces to the traveler provide general pre-trip and en-route information supporting trip planning, personal guidance, and requests for assistance in an emergency that are relevant to all transportation system users. It also represents users of a public transportation system and addresses interfaces these users have within a transit vehicle or at transit facilities such as roadside stops and transit centers. |
Traveler Support Equipment | Field | 'Traveler Support Equipment' provides access to traveler information at transit stations, transit stops, other fixed sites along travel routes (e.g., rest stops, merchant locations), and major trip generation locations such as special event centers, hotels, office complexes, amusement parks, and theaters. Traveler information access points include kiosks and informational displays supporting varied levels of interaction and information access. At transit stops this might be simple displays providing schedule information and imminent arrival signals. This may be extended to include multi-modal information including traffic conditions and transit schedules to support mode and route selection at major trip generation sites. Personalized route planning and route guidance information can also be provided based on criteria supplied by the traveler. It also supports service enrollment and electronic payment of transit fares. In addition to the traveler information provision, it also enhances security in public areas by supporting traveler activated silent alarms. |
Includes Functional Objects:
Functional Object | Description | Physical Object |
---|---|---|
PAC Payment Administration | 'PAC Payment Administration' provides administration and management of payments associated with electronic toll collection, parking payments, and other e-payments. It provides the back office functions that support enrollment, pricing, reduced fare eligibility, payment reconciliation with financial institutions, and violation notification to enforcement agencies. It also supports dynamic pricing to support demand management. | Payment Administration Center |
Personal Interactive Traveler Information | 'Personal Interactive Traveler Information' provides traffic information, road conditions, transit information, yellow pages (traveler services) information, special event information, and other traveler information that is specifically tailored based on the traveler's request and/or previously submitted traveler profile information. It also supports interactive services that support enrollment, account management, and payments for transportation services. The interactive traveler information capability is provided by personal devices including personal computers and personal portable devices such as smart phones. | Personal Information Device |
TIC Data Collection | 'TIC Data Collection' collects transportation-related data from other centers, performs data quality checks on the collected data and then consolidates, verifies, and refines the data and makes it available in a consistent format to applications that support operational data sharing between centers and deliver traveler information to end-users. A broad range of data is collected including traffic and road conditions, transit data, emergency information and advisories, weather data, special event information, traveler services, parking, multimodal data, and toll/pricing data. It also shares data with other transportation information centers. | Transportation Information Center |
Transit Center Fare Management | 'Transit Center Fare Management' manages fare collection and passenger load management at the transit center. It provides the back office functions that support transit fare collection, supporting payment reconciliation with links to financial institutions and enforcement agencies for fare violations. It collects data required to determine accurate ridership levels, establish fares, and distribute fare information. It loads fare data into the vehicle prior to the beginning of normal operations and unloads fare collection data from the vehicle at the close out of normal operations. | Transit Management Center |
Transit Vehicle On-Board Fare Management | 'Transit Vehicle On-board Fare Management' supports fare collection using a standard fare card or other non-monetary fare medium and detects payment violations. Collected fare data are made available to the center. | Transit Vehicle OBE |
Traveler Fare Management | 'Traveler Fare Management' provides the capability for the traveler to access and use a common fare medium for transit fares, tolls, shared use, and/or parking lot charges using a public device at or near the point of service. It accepts a service request and means of payment or smart card, verifies eligibility, calculates the amount due, collects payment (or deducts balance if smart card), and identifies payment problems. It may be implemented using a card reader/dispenser in a point of sale device that includes a communications interface to the financial infrastructure to support payment collection and reconciliation. | Traveler Support Equipment |
Includes Information Flows:
Information Flow | Description |
---|---|
account updates | Updates to an account, such as purchases, uses, cancellation, secureID changes or similar material changes to account information. |
actuate secure payment | Initiation of a payment action, ideally based on an encrypted token or biometric marker. |
authorization request | Request to determine if a transportation user is authorized to use a particular transportation resource. |
authorization response | Notification of status of authorization request. |
fare collection data | Fare collection information including the summary of fare system data and financial payment transaction data. |
fare management information | Transit fare information and transaction data used to manage transit fare processing. |
payment device information | Traveler payment information such as card number and previous transactions. |
payment device update | Information updated concerning traveler's personal data including name, address, user account information, trip records, and profile data. |
payment methods | A list of valid payment methods. |
payment methods financial institution | A list of valid payment methods accepted by a financial center. |
payment request | Request for payment from financial institution or related financial service requests (e.g., balance inquiry) |
payment violation notification | Notification to enforcement agency of a toll, parking, or transit fare payment violation. |
registered secureIDs | Cryptographically protected identifier indicating that the user associated with the identifier is entitled to use a particular service. |
request for payment | Request to deduct cost of service from user's payment account. |
service registry | Catalogue of products and values, access rights and related information. |
settlement | Information exchanged to settle charges and distribute or debit accounts appropriate to the authorized charges. |
transit fare coordination | Fare and pricing information shared between local/regional transit organizations. |
transit fare information | Information provided by transit management that supports fare payment transactions. |
transit fare request | Request for fare information and transit fare payment. |
transit operations personnel input | User input from transit operations personnel including instructions governing service availability, schedules, emergency response plans, transit personnel assignments, transit maintenance requirements, and other inputs that establish general system operating requirements and procedures. |
transit operations status | Presentation of information to transit operations personnel including accumulated schedule and fare information, ridership and on-time performance information, emergency response plans, transit personnel information, maintenance records, and other information intended to support overall planning and management of a transit property. |
transit vehicle operator display | Visual, audible, and tactile outputs to the transit vehicle operator including vehicle surveillance information, alarm information, vehicle system status, information from the operations center, and information indicating the status of all other on-board ITS services. |
transit vehicle operator input | Transit vehicle operator inputs to on-board ITS equipment, including tactile and verbal inputs. Includes authentication information, on-board system control, emergency requests, and fare transaction data. |
traveler input | User input from a traveler to summon assistance, request travel information, make a reservation, or request any other traveler service. |
traveler interface updates | Visual or audio information (e.g., routes, messages, guidance, emergency information) that is provided to the traveler. |
traveler payment information | Information provided for payment of road use charges, tolls or parking fees including identification that can be used to identify the payment account or source and related vehicle and service information that are used to determine the type and price of service requested. The information exchange normally supports an account debit to pay fees, but an account credit may be initiated where pricing strategies include incentives. |
traveler payment request | Request for information supporting payments. For fee structures that include incentives, the request may support either an account debit or an account credit or reimbursement. |
user account reports | Reports on services offered/provided and associated charges. |
user account setup | Billing information, vehicle information (or registration information), and requests for reports. Also includes subsequent account changes. |
Goals and Objectives
Associated Planning Factors and Goals
Planning Factor | Goal |
---|---|
D. Increase the accessibility and mobility of people and for freight; | Reduce congestion |
F. Enhance the integration and connectivity of the transportation system, across and between modes, for people and freight; | Enhance integration and connectivity |
G. Promote efficient system management and operation; | Improve efficiency |
I. Improve the resiliency and reliability of the transportation system and reduce or mitigate stormwater impacts of surface transportation; | Improve resiliency and reliability |
J. Enhance travel and tourism. | Support travel and tourism |
Associated Objective Categories
Associated Objectives and Performance Measures
Needs and Requirements
Need | Functional Object | Requirement | ||
---|---|---|---|---|
01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. | PAC Payment Administration | 03 | The center shall provide secure user account management, providing user access to rules and policies, current billing status, invoices, payments, and mechanisms for review and challenge of the collected data. |
Personal Interactive Traveler Information | 08 | The personal traveler interface shall support payment for services, such as confirmed trip plans, tolls, transit fares, parking lot charges, map updates, and advanced payment for tolls. | ||
09 | The personal traveler interface shall provide an interface through which credit identity, stored credit value, or traveler information may be collected from a traveler card being used by a traveler with a personal device. | |||
18 | The personal traveler interface shall provide an interface to establish and manage user road pricing accounts, process road pricing payments, and access road pricing reports under user control. | |||
Transit Center Fare Management | 01 | The center shall manage the actual value of transit fares for each segment of each regular transit route, including the transmission of the information to transit vehicles and transit stops or stations. | ||
02 | The center shall provide the capability for a system operator to manage the transit fares and control the exchange of transit fare information. | |||
03 | The center shall process the financial requests from the transit vehicles or roadside and manage an interface to a Financial Institution. | |||
05 | The center shall collect data on fare payment violations and send the data, including images of the violator, to the appropriate enforcement agency. | |||
06 | The center shall process requests for transit fares to be paid in advance. | |||
07 | The center shall maintain a list of invalid traveler credit identities or bad tag lists that can be forwarded to transit vehicles and transit stops or stations. | |||
Transit Vehicle On-Board Fare Management | 01 | The transit vehicle shall read data from the traveler card / payment instrument presented by boarding passengers. | ||
02 | The transit vehicle shall provide an image of all travelers which shall be used for violation processing of those who do not have a traveler card / payment instrument or whose transit fare transaction fails. | |||
03 | The transit vehicle shall determine the traveler's travel routing based on the transit vehicle's current location and the traveler's destination. | |||
04 | The transit vehicle shall calculate the traveler's fare based on the origin and destination provided by the traveler as well as factors such as the transit routing, transit fare category, traveler history, and route-specific information. | |||
05 | The transit vehicle shall have access to the complete range of transit services (routes and schedules) that are available to the traveler. | |||
06 | The transit vehicle shall provide a transit fare payment interface that is suitable for travelers with physical disabilities. | |||
07 | The transit vehicle shall include a database on-board the transit vehicle for use in fare processing from which the fares for all possible trips within the transit operational network can be determined. | |||
08 | The transit vehicle shall support the support advanced payments for tolls, and/or parking lot charges, and/or transit fares via the traveler card / payment instrument. | |||
02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. | Transit Center Fare Management | 01 | The center shall manage the actual value of transit fares for each segment of each regular transit route, including the transmission of the information to transit vehicles and transit stops or stations. |
02 | The center shall provide the capability for a system operator to manage the transit fares and control the exchange of transit fare information. | |||
03 | The center shall process the financial requests from the transit vehicles or roadside and manage an interface to a Financial Institution. | |||
05 | The center shall collect data on fare payment violations and send the data, including images of the violator, to the appropriate enforcement agency. | |||
07 | The center shall maintain a list of invalid traveler credit identities or bad tag lists that can be forwarded to transit vehicles and transit stops or stations. | |||
Traveler Fare Management | 01 | The public interface for travelers shall accept and process current transit passenger fare collection information. | ||
02 | The public interface for travelers shall calculate a fare based on the origin and destination provided by the traveler, in conjunction with transit routing, transit fare category, and transit user history. | |||
03 | The public interface for travelers shall provide an interface to a transit user traveler card in support of payment for transit fares, tolls, and/or parking lot charges. The stored credit value data from the card shall be collected and updated based on the fare or other charges, or the credit identity shall be collected. | |||
04 | The public interface for travelers shall provide information to the center for financial authorization and transaction processing. | |||
05 | The public interface for travelers shall provide an image of all travelers purchasing rides or services to be used for violation processing. | |||
06 | The public interface for travelers shall determine the routing based on the traveler's destination and the location of the closest transit stop from which a route request is being made. | |||
08 | The public interface for travelers shall present information to the traveler in a form suitable for travelers with physical disabilities. | |||
03 | Transit Operations needs to be able to download transit fare collection information from transit vehicles or transit fare gates at stations in order to manage the fare collection operations. | Transit Center Fare Management | 04 | The center shall support the payment of transit fare transactions using data provided by the traveler cards / payment instruments. |
08 | The center shall collect fare statistics data to implement variable and flexible fare structures. | |||
Transit Vehicle On-Board Fare Management | 09 | The transit vehicle shall provide fare statistics data to the center. | ||
Traveler Fare Management | 07 | The public interface for travelers shall create fare statistics data based upon data collected at a transit stop. | ||
04 | Travelers need to be able to add value to payment instruments in order to use them as part of fare collection systems. | Personal Interactive Traveler Information | 05 | The personal traveler interface shall receive evacuation information from a center and present it to the traveler. |
Traveler Fare Management | 03 | The public interface for travelers shall provide an interface to a transit user traveler card in support of payment for transit fares, tolls, and/or parking lot charges. The stored credit value data from the card shall be collected and updated based on the fare or other charges, or the credit identity shall be collected. | ||
05 | Transit Operations needs to be able to support transit fare reconciliation with other transit agencies participating in a regional fare collection system. | Transit Center Fare Management | 09 | The center shall exchange fare and load information with other transit management centers, including potential Centralized Payments facilities. |
06 | Transit operations needs to be able to share fare information with traveler information systems and other transit operations. | TIC Data Collection | 04 | The center shall collect, process, and store transit routes and schedules, transit transfer options, transit fares, and real-time schedule adherence information. |
Transit Center Fare Management | 09 | The center shall exchange fare and load information with other transit management centers, including potential Centralized Payments facilities. | ||
10 | The center shall provide transit fare information to traveler information providers upon request. |
Security
In order to participate in this service package, each physical object should meet or exceed the following security levels.
Physical Object Security | ||||
---|---|---|---|---|
Physical Object | Confidentiality | Integrity | Availability | Security Class |
Enforcement Center | Moderate | Moderate | Moderate | Class 2 |
Financial Center | Moderate | Moderate | Moderate | Class 2 |
Other Transit Management Centers | Low | Moderate | Moderate | Class 1 |
Payment Administration Center | High | High | Moderate | Class 4 |
Payment Device | Moderate | Moderate | High | Class 5 |
Personal Information Device | High | High | High | Class 5 |
Transit Management Center | High | High | High | Class 5 |
Transit Vehicle OBE | High | High | High | Class 5 |
Transportation Information Center | Low | Moderate | Moderate | Class 1 |
Traveler Support Equipment | High | High | High | Class 5 |
In order to participate in this service package, each information flow triple should meet or exceed the following security levels.
Information Flow Security | |||||
---|---|---|---|---|---|
Source | Destination | Information Flow | Confidentiality | Integrity | Availability |
Basis | Basis | Basis | |||
Financial Center | Payment Administration Center | payment methods financial institution | Moderate | Moderate | Low |
Payment methods should be widely disseminated and contain no information that could cause harm if exposed. | Payment methods need to be correct so payment information can be exchanged. Could be LOW, as this should have redundancies and be able to tolerate significant latency. | Payment methods need to be correct so payment information can be exchanged. Could be LOW, as this should have redundancies and be able to tolerate significant latency. | |||
Financial Center | Transit Management Center | settlement | Moderate | Moderate | Moderate |
This may include PII and will include status information about a payment that could be used by a criminal for a variety of purposes, including identity theft, financial theft, or location-based activities, as the status is predictivie of what the account holder is doing and where they are doing it. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | |||
Other Transit Management Centers | Transit Management Center | transit fare coordination | Low | Moderate | Moderate |
Does not contain any personal or confidential information. | While accuracy of this data is important for decision making purposes, the greatest impact if manipulated or incorrect data would be financial and likely limited in scope. For example, making all options appear less expensive than an attacker's route of fiduciary interest, driving revenue to his route. This is undesireable and significant, but not catastrophic. Thus MODERATE generally. | While accuracy of this data is important for decision making purposes, applications should be able to function without frequent updates. Thus MODERATE generally. | |||
Payment Administration Center | Personal Information Device | registered secureIDs | High | High | Moderate |
These IDs are used to secure individual user's rights to use transportation assets. Compromising one of these would be a significant inconvenience but only for the user of that secureID. However, compromise of the algorithm securing all IDs would be catastrophic to the system that uses this mechanism as a means to pay for transportation services. | Individual tokens should be correct or the user will not be able to use this method to pay for transport. A systemic integrity flaw would compromise the system similar to how an encryption flaw would however, which justifies HIGH. | Should be relatively infrequently used by any one user, but over the sum of all transport users sees significant use. If the flow is not available, new or re-applying users will not be able to use this method to pay for transport. | |||
Payment Administration Center | Personal Information Device | user account reports | High | High | Moderate |
Contains user identification and transaction history, which if compromised could lead to identity or financial theft. | Payment history information, if corrupted, could lead the user to take action he or she should not take. If intercepted by a malicious actor, this could be manipulated to trick the user into taking action not in his own best interest. | There should be other mechanisms to retrieve this information, but if the flow has low reliability users will lose confidence and not use it. MODERATE for that reason only. | |||
Payment Administration Center | Transit Management Center | payment methods | Moderate | Moderate | Low |
Payment methods should be widely disseminated and contain no information that could cause harm if exposed. | Payment methods need to be correct so payment information can be exchanged. Could be LOW, as this should have redundancies and be able to tolerate significant latency. | Payment methods need to be correct so payment information can be exchanged. Could be LOW, as this should have redundancies and be able to tolerate significant latency. | |||
Payment Device | Transit Vehicle OBE | actuate secure payment | Moderate | Moderate | High |
Contains an identifier linked to an individual or specific device, and thus PII by definition. Compromise of one secureID would likely impact only one user, but the nature of this flow requires that the same algorithm be used for every user; algorithm compromise would harm every user, which would have widespread impact. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Payment Device | Transit Vehicle OBE | payment device information | Moderate | Moderate | High |
Contains charges and possibly balance or personal information. Charge information may or may not be public, and balance and personal information is not, though it may be displayed visually. Could be LOW if no personal or balance information and no identifier is not included in the flow. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Payment Device | Traveler Support Equipment | actuate secure payment | Moderate | Moderate | High |
Contains an identifier linked to an individual or specific device, and thus PII by definition. Compromise of one secureID would likely impact only one user, but the nature of this flow requires that the same algorithm be used for every user; algorithm compromise would harm every user, which would have widespread impact. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Payment Device | Traveler Support Equipment | payment device information | Moderate | Moderate | High |
Contains charges and possibly balance or personal information. Charge information may or may not be public, and balance and personal information is not, though it may be displayed visually. Could be LOW if no personal or balance information and no identifier is not included in the flow. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Personal Information Device | Payment Administration Center | user account setup | High | High | Moderate |
Contains user identification and matching vehicle information, which if compromised could lead to identity theft or remote tracking. | Payment setup information, if corrupted, could lead the user to not properly pay for his trips or perhaps pay for others. If intercepted by a malicious actor, this could be manipulated to trick the user into taking action not in his own best interest. | There should be other mechanisms to provide this information, but if the flow has low reliability users will lose confidence and not use it. MODERATE for that reason only. | |||
Personal Information Device | Transit Management Center | actuate secure payment | Moderate | Moderate | High |
Contains an identifier linked to an individual or specific device, and thus PII by definition. Compromise of one secureID would likely impact only one user, but the nature of this flow requires that the same algorithm be used for every user; algorithm compromise would harm every user, which would have widespread impact. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Personal Information Device | Transit Management Center | traveler payment information | High | High | Moderate |
Contains personal information, potentially including identity, payment information such as account numbers and location. All of this information is personal in nature and acceptable only for the intended destination to receive, as any 3rd party observation could lead to identity theft/compromise and/or payment method theft/compromise. | This is information is used to process payment and/or detect fraud. Any losses, corruption or forgery has a direct impact on revenue collection, charges assessed and potentially legal action. | This is information is used to process payment . Any losses, corruption or forgery has a direct impact on revenue collection, charges assessed and potentially legal action. Availability constrained to MODERATE the fact that alternative mechanisms and compromises exist to ameliorate not completing the flow. | |||
Personal Information Device | Transit Management Center | user account setup | High | High | Moderate |
Contains user identification and transaction history, which if compromised could lead to identity or financial theft. | Payment setup information, if corrupted, could lead the user to not properly pay for his trips or perhaps pay for others. If intercepted by a malicious actor, this could be manipulated to trick the user into taking action not in his own best interest. | These exchanges can be delayed but eventually have to go through or accounts will not be properly updated, mostly impacting revenue collection. | |||
Personal Information Device | Traveler | traveler interface updates | Not Applicable | Moderate | Moderate |
Personalized data that includes directions and guidance for an individual, but eventually evident anyway. | Should be accurate as the Traveler will be relying on this information for routing and related choices. Lack of accuracy will result in lack of confidence from the traveler as well as an unsatisfactory trip, leading to a negative feedback spiral. | Users expect their devices to work. If information is not presented to the operator, the relevant applications simply won't be used. | |||
Transit Management Center | Enforcement Center | payment violation notification | Moderate | Moderate | Moderate |
Contains PII and intended to be used for enforcement. Thus privacy implications that, while they may affect only a single individual at a time, could yield significant negative consequences to that individual. | Violation information needs to be correct or the commercial vehicle may be improperly penalized, or not when it should be. This is probably not a severe consequence however, so MODERATE. | More or less important depending on the context. Could even be LOW if areas of minimal import, depending on local policies. | |||
Transit Management Center | Financial Center | payment request | Moderate | Moderate | Moderate |
Contains account and related information that is personal and if compromised could financially impact the owner of the account. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | |||
Transit Management Center | Other Transit Management Centers | transit fare coordination | Low | Moderate | Moderate |
Does not contain any personal or confidential information. | While accuracy of this data is important for decision making purposes, the greatest impact if manipulated or incorrect data would be financial and likely limited in scope. For example, making all options appear less expensive than an attacker's route of fiduciary interest, driving revenue to his route. This is undesireable and significant, but not catastrophic. Thus MODERATE generally. | While accuracy of this data is important for decision making purposes, applications should be able to function without frequent updates. Thus MODERATE generally. | |||
Transit Management Center | Payment Administration Center | account updates | Moderate | Moderate | Moderate |
Contains an identifier that can be linked to an account which is in turn likely linked to a person, and thus PII that should be protected. | Payment charge and similar information should be correct or it could lead to abuse or incorrect charges. Impact limited to individual accounts however. | These exchanges can be delayed but eventually have to go through or accounts will not be properly updated, mostly impacting revenue collection. | |||
Transit Management Center | Payment Administration Center | service registry | Low | Moderate | Moderate |
Much of this information will eventually be widely disseminated to transport users, though there seems little good reason to not obfuscate it. | Could inconvience travelers if incorrect, and would hamper the operation of payment methods if incorrect or unavailable, which could have widespread network effect. | Could inconvience travelers if incorrect, and would hamper the operation of payment methods if incorrect or unavailable, which could have widespread network effect. | |||
Transit Management Center | Personal Information Device | registered secureIDs | High | High | Moderate |
These IDs are used to secure individual user's rights to use transportation assets. Compromising one of these would be a significant inconvenience but only for the user of that secureID. However, compromise of the algorithm securing all IDs would be catastrophic to the system that uses this mechanism as a means to pay for transportation services. | Individual tokens should be correct or the user will not be able to use this method to pay for transport. A systemic integrity flaw would compromise the system similar to how an encryption flaw would however, which justifies HIGH. | Should be relatively infrequently used by any one user, but over the sum of all transport users sees significant use. If the flow is not available, new or re-applying users will not be able to use this method to pay for transport. | |||
Transit Management Center | Personal Information Device | traveler payment request | Moderate | Moderate | Moderate |
While this may not contain any PII, it does expose behavior. While an observer in place may assume payment activity, there is no sound reason to not conceal this information. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | |||
Transit Management Center | Personal Information Device | user account reports | High | High | Moderate |
Contains user identification and transaction history, which if compromised could lead to identity or financial theft. | Payment setup information, if corrupted, could lead the user to not properly pay for his trips or perhaps pay for others. If intercepted by a malicious actor, this could be manipulated to trick the user into taking action not in his own best interest. | These exchanges can be delayed but eventually have to go through or accounts will not be properly updated, mostly impacting revenue collection. | |||
Transit Management Center | Transit Operations Personnel | transit operations status | Moderate | High | High |
Backoffice operations flows should have minimal protection from casual viewing, as otherwise imposters could gain illicit control or information that should not be generally available. | Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. | Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. | |||
Transit Management Center | Transit Vehicle OBE | authorization response | Moderate | Moderate | Moderate |
While this may not contain any PII, it does expose behavior. While an observer in place may assume payment activity, there is no sound reason to not conceal this information. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | |||
Transit Management Center | Transit Vehicle OBE | fare management information | High | Moderate | Moderate |
May contain PII of the originator, including possible special needs and identity, which should be readable only by the intended recepient lest the originator's privacy be violated. | If this is compromised or corrupted, the user's needs may not be properly communicated or met. If this is forged, the transit provider may not collect the appropriate fare or provide the proper services. | If this is not available, the user may not receive transit services offered, and as with other transit services may ceases using the system. While the immediate impact is LOW, long term impact is MODERATE due to user confidence issues. | |||
Transit Management Center | Transportation Information Center | transit fare information | Low | High | Moderate |
Intended to be distributed to the traveling public. | Accuracy of this data is important for decision making purposes. Corruption of this data could lead to revenue loss and confusion. | While availability of this data is important for decision making, and there are usually multiple avenues for determining transit costs, the TIC may serve a great many users, so it should have higher priority for fare information than individual traveler equipment. | |||
Transit Management Center | Traveler Support Equipment | authorization response | Moderate | Moderate | Moderate |
While this may not contain any PII, it does expose behavior. While an observer in place may assume payment activity, there is no sound reason to not conceal this information. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | |||
Transit Management Center | Traveler Support Equipment | fare management information | High | Moderate | Moderate |
May contain PII of the originator, including possible special needs and identity, which should be readable only by the intended recepient lest the originator's privacy be violated. | If this is compromised or corrupted, the user's needs may not be properly communicated or met. If this is forged, the transit provider may not collect the appropriate fare or provide the proper services. | If this is not available, the user may not receive transit services offered, and as with other transit services may ceases using the system. While the immediate impact is LOW, long term impact is MODERATE due to user confidence issues. | |||
Transit Operations Personnel | Transit Management Center | transit operations personnel input | Moderate | High | High |
Backoffice operations flows should have minimal protection from casual viewing, as otherwise imposters could gain illicit control or information that should not be generally available. | Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. | Backoffice operations flows should generally be correct and available as these are the primary interface between operators and system. | |||
Transit Vehicle OBE | Payment Device | payment device update | Moderate | Moderate | High |
Contains charges and possibly balance or personal information. Charge information may or may not be public, and balance and personal information is not, though it may be displayed visually. Could be LOW if no personal or balance information and no identifier is not included in the flow. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Transit Vehicle OBE | Payment Device | request for payment | Moderate | Moderate | High |
Contains charges and possibly balance or personal information. Charge information may or may not be public, and balance and personal information is not, though it may be displayed visually. Could be LOW if no personal or balance information and no identifier is not included in the flow. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Transit Vehicle OBE | Transit Management Center | authorization request | Moderate | Moderate | Moderate |
Contains an identifier linked to an individual or specific device, and thus PII by definition. Compromise of one secureID would likely impact only one user, but the nature of this flow requires that the same algorithm be used for every user; algorithm compromise would harm every user, which would have widespread impact. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | |||
Transit Vehicle OBE | Transit Management Center | fare collection data | Moderate | Moderate | Moderate |
Imagery of a traveler that has ostensibly violated a transit fare. If captured by an observer, could be used against the individual. | If corrupted, could make it difficult to identify the offender, costing money. | If unavailable, could probably be buffered until such time as the OBE is in a place with consistent connectivity, such as the transit yard. Might decrease to LOW for this reason. | |||
Transit Vehicle OBE | Transit Vehicle Operator | transit vehicle operator display | Low | Moderate | Low |
This should not include any sensitive information. It would be possible for a person standing behind the driver to observe the information transmitted. | Some minimal guarantee of data integrity is necessary for all C-ITS flows. This entire application should not directly affect the drivers driving habits. The operator should still be slowing and stopping at yellow or red lights, along with observing all other driving regulations. DISC: Original V2I analysis classified this as LOW. | Even if the operator is not made aware of the signal preemption, the system should still operate correctly. The operator should be using the traffic lights to influence their decision about whether or not to stop, not the display. | |||
Transit Vehicle OBE | Traveler | traveler interface updates | Not Applicable | Moderate | Moderate |
This data is informing the vehicle of operational information that is relevant to the operation of the vehicle. It should not contain anything sensitive, and does not matter if another person can observe it. | Should be accurate as the Traveler will be relying on this information for routing and related choices. Lack of accuracy will result in lack of confidence from the traveler as well as an unsatisfactory trip, leading to a negative feedback spiral. | Users expect their devices to work. If information is not presented to the operator, the relevant applications simply won't be used. | |||
Transit Vehicle Operator | Transit Vehicle OBE | transit vehicle operator input | Low | Moderate | Low |
This information is transmitted through systems on board the Transit Vehicle. Even if the vehicle were compromised and these communications monitored, most of this information is directly observable. | Some minimal guarantee of data integrity is necessary for all C-ITS flows. If this is compromised, it could result in an incorrect signal priority request, which has minimal impact. DISC: Original V2I analysis classified this as LOW. | A delay in reporting this may result in a signal priority request not going through, which has minimal impact. | |||
Transportation Information Center | Transit Management Center | transit fare request | Low | Moderate | Low |
Response information will all be public eventually and the request flow betrays no intent not already implicit in the sender. | This information will be propagated to travelers. This will set their expectations and may be used to drive their decision making. Incorrect data will reduce confidence in the overall transportation system and could negatively impact individual travelers' transportation experience. | Most likely this flow will not need to operate often; as long as it does operate within a reasonable update time from when fares change, LOW is acceptable. | |||
Traveler | Personal Information Device | traveler input | Not Applicable | Moderate | Low |
This data is informing the vehicle of operational information that is relevant to the operation of the vehicle. It should not contain anything sensitive, and does not matter if another person can observe it. | While public, information must be correct or travelers may make incorrect decisions with regard to their travel plans. | Information is available through other means, though depending on the location this might not always be the case, in which case this would be MODERATE. | |||
Traveler | Transit Vehicle OBE | traveler input | Not Applicable | Moderate | Low |
This data is informing the vehicle of operational information that is relevant to the operation of the vehicle. It should not contain anything sensitive, and does not matter if another person can observe it. | While public, information must be correct or travelers may make incorrect decisions with regard to their travel plans. | Information is available through other means, though depending on the location this might not always be the case, in which case this would be MODERATE. | |||
Traveler | Traveler Support Equipment | traveler input | Not Applicable | Moderate | Low |
Publicly available information, while not directly observable, is intended for widespread distribution | While public, information must be correct or travelers may make incorrect decisions with regard to their travel plans. | Information is available through other means, though depending on the location this might not always be the case, in which case this would be MODERATE. | |||
Traveler Support Equipment | Payment Device | payment device update | Moderate | Moderate | High |
Contains charges and possibly balance or personal information. Charge information may or may not be public, and balance and personal information is not, though it may be displayed visually. Could be LOW if no personal or balance information and no identifier is not included in the flow. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Traveler Support Equipment | Payment Device | request for payment | Moderate | Moderate | High |
Contains charges and possibly balance or personal information. Charge information may or may not be public, and balance and personal information is not, though it may be displayed visually. Could be LOW if no personal or balance information and no identifier is not included in the flow. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. | |||
Traveler Support Equipment | Transit Management Center | authorization request | Moderate | Moderate | Moderate |
Contains an identifier linked to an individual or specific device, and thus PII by definition. Compromise of one secureID would likely impact only one user, but the nature of this flow requires that the same algorithm be used for every user; algorithm compromise would harm every user, which would have widespread impact. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | Payment flows must all have some integrity protection and consistent availability to prohibit forgery and instill confidence in the payment process. Repurcussions of roadway payment are individually fairly small, collectiviely significant but probably never catastrophic. Thus MODERATE for both integrity and availability. | |||
Traveler Support Equipment | Transit Management Center | fare collection data | Moderate | Moderate | Moderate |
Imagery of a traveler that has ostensibly violated a transit fare. If captured by an observer, could be used against the individual. | If corrupted, could make it difficult to identify the offender, costing money. | If unavailable, other mechanisms could still exist to provide payment. If no other mechanisms exist this would have to be HIGH. | |||
Traveler Support Equipment | Traveler | traveler interface updates | Not Applicable | Moderate | Moderate |
Publicly available information, while not directly observable, is intended for widespread distribution | Should be accurate as the Traveler will be relying on this information for routing and related choices. Lack of accuracy will result in lack of confidence from the traveler as well as an unsatisfactory trip, leading to a negative feedback spiral. | Users expect their devices to work. If information is not presented to the operator, the relevant applications simply won't be used. |
Standards
The following table lists the standards associated with physical objects in this service package. For standards related to interfaces, see the specific information flow triple pages.
Name | Title | Physical Object |
---|---|---|
NEMA TS 8 Cyber and Physical Security | Cyber and Physical Security for Intelligent Transportation Systems | Payment Administration Center |
System Requirements
System Requirement | Need | ||
---|---|---|---|
001 | The system shall provide secure user account management, providing user access to rules and policies, current billing status, invoices, payments, and mechanisms for review and challenge of the collected data. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
002 | The system shall collect, process, and store transit routes and schedules, transit transfer options, transit fares, and real-time schedule adherence information. | 06 | Transit operations needs to be able to share fare information with traveler information systems and other transit operations. |
003 | The system shall manage the actual value of transit fares for each segment of each regular transit route, including the transmission of the information to transit vehicles and transit stops or stations. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. | ||
004 | The system shall provide the capability for a system operator to manage the transit fares and control the exchange of transit fare information. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. | ||
005 | The system shall process the financial requests from the transit vehicles or roadside and manage an interface to a Financial Institution. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. | ||
006 | The system shall support the payment of transit fare transactions using data provided by the traveler cards / payment instruments. | 03 | Transit Operations needs to be able to download transit fare collection information from transit vehicles or transit fare gates at stations in order to manage the fare collection operations. |
007 | The system shall collect data on fare payment violations and send the data, including images of the violator, to the appropriate enforcement agency. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. | ||
008 | The system shall process requests for transit fares to be paid in advance. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
009 | The system shall maintain a list of invalid traveler credit identities or bad tag lists that can be forwarded to transit vehicles and transit stops or stations. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. | ||
010 | The system shall collect fare statistics data to implement variable and flexible fare structures. | 03 | Transit Operations needs to be able to download transit fare collection information from transit vehicles or transit fare gates at stations in order to manage the fare collection operations. |
011 | The system shall exchange fare and load information with other transit management centers, including potential Centralized Payments facilities. | 05 | Transit Operations needs to be able to support transit fare reconciliation with other transit agencies participating in a regional fare collection system. |
06 | Transit operations needs to be able to share fare information with traveler information systems and other transit operations. | ||
012 | The system shall provide transit fare information to traveler information providers upon request. | 06 | Transit operations needs to be able to share fare information with traveler information systems and other transit operations. |
013 | The system shall accept and process current transit passenger fare collection information. | 02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. |
014 | The system shall calculate a fare based on the origin and destination provided by the traveler, in conjunction with transit routing, transit fare category, and transit user history. | 02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. |
015 | The system shall provide an interface to a transit user traveler card in support of payment for transit fares, tolls, and/or parking lot charges. The stored credit value data from the card shall be collected and updated based on the fare or other charges | 02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. |
04 | Travelers need to be able to add value to payment instruments in order to use them as part of fare collection systems. | ||
016 | The system shall provide information to the center for financial authorization and transaction processing. | 02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. |
017 | The system shall provide an image of all travelers purchasing rides or services to be used for violation processing. | 02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. |
018 | The system shall determine the routing based on the traveler's destination and the location of the closest transit stop from which a route request is being made. | 02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. |
019 | The system shall create fare statistics data based upon data collected at a transit stop. | 03 | Transit Operations needs to be able to download transit fare collection information from transit vehicles or transit fare gates at stations in order to manage the fare collection operations. |
020 | The system shall present information to the traveler in a form suitable for travelers with physical disabilities. | 02 | Transit Operations needs to be able to collect transit fares at transit stations using electronic payment methods in or der to support bus rapid transit or train systems. |
021 | The system shall support payment for services, such as confirmed trip plans, tolls, transit fares, parking lot charges, map updates, and advanced payment for tolls. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
022 | The system shall provide an interface through which credit identity, stored credit value, or traveler information may be collected from a traveler card being used by a traveler with a personal device. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
023 | The system shall read data from the traveler card / payment instrument presented by boarding passengers. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
024 | The system shall provide an image of all travelers which shall be used for violation processing of those who do not have a traveler card / payment instrument or whose transit fare transaction fails. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
025 | The system shall determine the traveler's travel routing based on the transit vehicle's current location and the traveler's destination. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
026 | The system shall calculate the traveler's fare based on the origin and destination provided by the traveler as well as factors such as the transit routing, transit fare category, traveler history, and route-specific information. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
027 | The system shall have access to the complete range of transit services (routes and schedules) that are available to the traveler. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
028 | The system shall provide a transit fare payment interface that is suitable for travelers with physical disabilities. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
029 | The system shall include a database on-board the transit vehicle for use in fare processing from which the fares for all possible trips within the transit operational network can be determined. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
030 | The system shall support the support advanced payments for tolls, and/or parking lot charges, and/or transit fares via the traveler card / payment instrument. | 01 | Transit Operations needs to be able to collect transit fares on-board transit vehicles using electronic payment methods in order to improve transit operation. |
031 | The system shall provide fare statistics data to the center. | 03 | Transit Operations needs to be able to download transit fare collection information from transit vehicles or transit fare gates at stations in order to manage the fare collection operations. |