Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
140 Request for Proposals (RFP) Language A P P E N D I X H SCOPE OF SERVICES: Service Provider Moving into the digital age requires that the software used by transit agencies be able to seamlessly exchange data. Agencies procuring software are the ones that must require this capability, opening up the future for an array of technological solutions. There are costs for a vendor to adapt its software to a standardized data format, but once incurred this cost can be amortized across all agencies that procure software. This means that the costs for an individual agency will be small but it will open up many possibilities for sharing data across platforms. This appendix contains two sets of text that could be edited and used in a request for proposal (RFP) that would adhere to or support the use of the proposed DRT transactional data specification in procuring paratransit/DRT/microtransit scheduling software. The first part is language for use by a transit agency and/or other DRT service providers in a request for proposal for procuring a paratransit or DRT/microtransit service provider where the provider will include a paratransit/DRT/microtransit scheduling system as part of the services provided. The second part is language that could be used by an agency that is procuring DRT software and/or a technology vendor. [Brackets] indicate text that should be inserted prior to use. The following RFP language can be adapted based on what the transit agency has in place, intends to implement over the period of the service contract, and is purchasing through the RFP. One year is suggested for when the software adaptations are required to be in place but this may be adjusted to reflect the needs of the transit agency. CASE 1-A: Transit/Paratransit agency does not provide software and requires service provider to bring a scheduling/dispatch solution as part of the service proposal. CASE 1-B: Transit/Paratransit agency has software licenses for their directly operated services but allows the proposer to bring a different dispatch platform for the contracted services.
Request for Proposals (RFP) Language 141 CASE 1-A: The trip data in the [TCRP G-16 transactional data specification] includes all data elements needed for a provider to successfully schedule and dispatch a trip (e.g., rider name, scheduled pickup/drop-off times and locations, fare to be collected, vehicle type needed, notes, phone number). The scheduling system proposed must be capable of sharing such data electronically via an export file (e.g.,.xls or.csv format) or through an application programming interface (API). Proposers are strongly encouraged to present solutions that use the [TCRP G-16 transactional data specification] to enable integrated trip data sharing. This must be in place by the beginning of year 2 of the contract. The [Transit agency name] also requires (1) proposers to retain independent trip records for backup and auditing purposes and (2) for the successful proposer to use terminology consistent with the [TCRP G-16 transactional data specification] data descriptions in all reporting and forms. CASE 1-B: The trip data in [transit agencyâs existing paratransit software] includes all data elements needed for a provider to successfully schedule and dispatch a trip (e.g., rider name, scheduled pickup/drop-off times and locations, fare to be collected, vehicle type needed, notes, phone number). This data can be shared electronically via an export file (e.g.,.xls or.csv format) or through an application programming interface (API). However, proposers may also bring in their own dispatch platform. If a separate dispatch platform, proposers are strongly encouraged to present solutions that use the [TCRP G-16 transactional data specification] to enable integrated trip data sharing between [transit agencyâs existing paratransit software] and the proposerâs dispatch platform, including the capacity to share vehicle locations, estimated time of arrivals, and trip performance status (e.g., scheduled, completed, canceled, no show). The [Transit agency name] also requires (1) proposers to retain independent trip records for backup and auditing purposes and (2) for the successful proposer to use terminology consistent with the [TCRP G-16 transactional data specification] data descriptions in all reporting and forms. Proposers that do not currently use any dispatch software to accomplish the above data integration may still respond to this RFP but should indicate how they will ensure that trip data provided by [Transit agency name] will be dispatched accurately and in a timely manner, as well as how they will communicate trip status updates, report on historical performance, and generate/audit invoices. Proposers that do not have sufficient dispatch technology are also encouraged to partner with other potential service providers to leverage a common dispatch platform that can accomplish the above data integration. All proposers are strongly encouraged to format the data and data transactions used for this service such that the data are readable and usable by any other software that also makes use of the [TCRP G-16 transactional data specification]. and to readily share data between our agency and the service contractor and with other agencies such as grant or funding partners or coordination partners. Over the term of the agreement resulting from this RFP, [Transit agency name] may begin reporting such data to the state or may use a mobile app to support first- or last-mile trips. [Transit agency name] is adopting the [TCRP G-16 transactional data specification] for demand-responsive transportation service trip reservations, scheduling, and dispatching. Over time this will enable [Transit agency name] to use the data in a variety of technology applications
142 Development of Transactional Data Specifications for Demand-Responsive Transportation SCOPE OF SERVICES: Software/Technology Vendor The following language can be included in an RFP for procuring DRT trip scheduling and dispatch software. How this language is adapted for your RFP will be determined by what the transit agency has in place, intends to implement over the period of the service contract, and is purchasing through the RFP. One year is suggested for when the software adaptations are required to be in place but this should be adjusted to reflect the needs of the transit agency. For example, if the procuring agency intends to use the data immediately as part of a coordination project, the RFP language should specify both the timing and form in which data needs to be exported. If the agency intends to, at a later time or an unspecified time, undertake a project that requires shared data (e.g. developing a mobile app that will allow riders to identify if any DRT vehicles could be used for a first-mile or last-mile trip or sending data directly to a grant funding partner such as the state), this too should be stated and may result in allowing a longer time to adapt the software. [Transit agency name] is adopting the [TCRP G-16 transactional data specification] for DRT trip reservations, scheduling, and dispatching. Over time this will enable [Transit agency name] to use the data in a variety of technology applications and to readily share data between our agency and the service contractor and with other agencies such as grant or funding partners or coordination partners. Over the period the [Transit agency name] intends to use the dispatch software being procured through this RFP, [Transit agency name] may begin reporting such data to the state or may use a mobile app to support first- or last-mile trips. The trip data in the [TCRP G-16 transactional data specification] includes all data elements needed for a provider to successfully schedule and dispatch a trip (e.g., customer name, scheduled pickup/drop-off times and locations, fare to be collected, vehicle type needed, phone number). This data can be shared electronically via an export file (e.g.,.xls or.csv format) or an application programming interface (API). Proposers are strongly encouraged to present solutions that use the [TCRP G-16 transactional data specification] to enable integrated trip data sharing among dispatch platforms, including the capacity to share vehicle locations, estimated time of arrivals, and trip performance status (e.g., scheduled, completed, canceled, no show). Proposers that do not currently use any dispatch software to accomplish the above data integration may still respond to this RFP. If this is the case, the proposer shall indicate how it will ensure that trip data provided by [transit agency name] will lead to trips that will be dispatched accurately and in a timely manner, as well as how it will communicate trip status updates, report on historical performance, and generate/audit invoices. A proposer that does not have sufficient dispatch technology is also encouraged to partner with other potential service providers to leverage a common dispatch platform that can accomplish the above data integration. Proposers must retain independent trip records for backup and auditing purposes. Separate trip records and reports must also be maintained for premium service trips (if applicable), as these trips may be reserved directly with the provider and may not be scheduled by [transit agency name].
Abbreviations and acronyms used without definitions in TRB publications: A4A Airlines for America AAAE American Association of Airport Executives AASHO American Association of State Highway Officials AASHTO American Association of State Highway and Transportation Officials ACIâNA Airports Council InternationalâNorth America ACRP Airport Cooperative Research Program ADA Americans with Disabilities Act APTA American Public Transportation Association ASCE American Society of Civil Engineers ASME American Society of Mechanical Engineers ASTM American Society for Testing and Materials ATA American Trucking Associations CTAA Community Transportation Association of America CTBSSP Commercial Truck and Bus Safety Synthesis Program DHS Department of Homeland Security DOE Department of Energy EPA Environmental Protection Agency FAA Federal Aviation Administration FAST Fixing Americaâs Surface Transportation Act (2015) FHWA Federal Highway Administration FMCSA Federal Motor Carrier Safety Administration FRA Federal Railroad Administration FTA Federal Transit Administration HMCRP Hazardous Materials Cooperative Research Program IEEE Institute of Electrical and Electronics Engineers ISTEA Intermodal Surface Transportation Efficiency Act of 1991 ITE Institute of Transportation Engineers MAP-21 Moving Ahead for Progress in the 21st Century Act (2012) NASA National Aeronautics and Space Administration NASAO National Association of State Aviation Officials NCFRP National Cooperative Freight Research Program NCHRP National Cooperative Highway Research Program NHTSA National Highway Traffic Safety Administration NTSB National Transportation Safety Board PHMSA Pipeline and Hazardous Materials Safety Administration RITA Research and Innovative Technology Administration SAE Society of Automotive Engineers SAFETEA-LU Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (2005) TCRP Transit Cooperative Research Program TDC Transit Development Corporation TEA-21 Transportation Equity Act for the 21st Century (1998) TRB Transportation Research Board TSA Transportation Security Administration U.S. DOT United States Department of Transportation
D evelopm ent of Transactional D ata Specifications for D em and-Responsive Transportation TCRP Research Report 210 TRB TRA N SPO RTATIO N RESEA RCH BO A RD 500 Fifth Street, N W W ashington, D C 20001 A D D RESS SERV ICE REQ U ESTED ISBN 978-0-309-48135-9 9 7 8 0 3 0 9 4 8 1 3 5 9 9 0 0 0 0
