The City Transit Authority is seeking requisition for Hosting and Maintenance of a web-based Software as a Service (SaaS) containing modeled data on origin-destination pairs, transfers, and vehicle loads by synthesizing data from sources for three years with two one-year options.

The solicitation will require the firm awarded with the contract (Contractor) to assist with the implementation of the SaaS including configuration, customization, testing, training, deployment, and post-go-live support.

Requirements include:
• Client Server applications should use Server 2016/2019 or the latest for the network operating system whenever possible;
• Client computers should utilize Microsoft Windows 10 as client application architecture;
• Microsoft Office 365 is the standard for common office applications; and
• Microsoft Edge is the standard browser.

Scope of Services
Synthesized Ridership Data
The City Transit Authority is interested in acquiring a SaaS that would provide modeled data on origin-destination pairs, paid and unpaid transfers, and vehicle loads by synthesizing data from sources including:

Automatic Vehicle Location (AVL) for bus
Supervisory Control and Data Acquisition (SCADA) for rail
General Transit Feed Specification (GTFS)
Automatic Passenger Counter (APC) for bus
Automated Fare Collection (AFC)
Geographic Information System (GIS)

The system would apply algorithms or other logic to infer and validate the details of each anonymized passenger’s movements, including the location and time of origin, transfer(s) (if applicable), and destination. The system would have a reasonable method for scaling up data to account for uninferred origins and destinations, as well as passengers who did not interact with the AFC system or other missing data. The system would process data nightly.

Detailed Specifications
Network and Schedule Unification:
The Contractor would derive a system-wide, multi-modal network and schedule to cover all the City Transit Authority bus and “L” services and fare-collection equipment and facilities, and to reflect the state of the transit system on any dates being analyzed.

Vehicle History Synthesis:
The Contractor would configure its SaaS to clean, correct, and reconstruct each of the City Transit Authority vehicle’s stop-level history in space and time, including the handling of misidentified trains and the correction of GPS errors. This entails a robust analysis of AVL, SCADA, GTFS-static, APC, schedule, GIS, and possibly other data.

Origin inference:
The SaaS would attempt to infer the time and stop of each passenger boarding. This includes boardings associated with fare transactions (such as at fareboxes) as well as those that occur within gated stations. In cases where a definite boarding location cannot be inferred, it would be approached probabilistically.

Destination inference:
The SaaS would attempt to infer the alighting stop and time of each ride. In cases where a definite alighting location cannot be inferred, it would be approached probabilistically.

Transfer and journey inference:
The SaaS would attempt to infer whether each ride was linked to the next or ended in a trip-generating activity. Rides would then be grouped into journeys.

Train assignment:
Riders who interact with the fare system at gated “L” stations would be associated with one or more trains, leading to the estimation of train loads and platform occupancy.

Disaggregate ride records:
The Contractor would make available or otherwise provide nightly (or otherwise as mutually agreed to in a processing schedule) sets of ride records, including inferred origin, destination, transfer, and journey information.

Stop-level vehicle data:
The Contractor would make available or otherwise provide nightly (or otherwise as mutually agreed to in a processing schedule) sets of vehicle visit records, where each is an instance of a vehicle serving a stop. These records would include scaled boarding, alighting, and load counts from the inferred passenger ride data.

Aggregate Ridership data:
The Contractor would make available or otherwise provide nightly (or otherwise as mutually agreed to in a processing schedule) scaled Ridership data at additional levels of aggregation beyond the stop-level data mentioned above. This would account for rides that weren’t successfully recorded or associated with a vehicle visit.

Historical data:
The Contractor would process data from 2019 and beyond to make available or otherwise, provide corresponding generated data.

Performance and Ridership analytics tools:
The accumulated generated data will power the Contractor’s analytics platform, where the City Transit Authority would have full access to a suite of Ridership, performance, and other tools, including total estimated Ridership counts, vehicle loads and crowding, origin-destination flows, on-time performance, unfilled service trips and other fully scaled passenger-flow information.

Daily data processing:
The Contractor would perform a nightly (or otherwise as set forth in a processing schedule) extract-transform-load (ETL) process to obtain data from the City Transit Authority’s Ventra, Genfare, Clever, SCADA, Hastus, and BusTools systems. Dates would be reprocessed to capture any late reporting data.

Data Storage and Access:
The service includes a Contractor-hosted data warehouse that can be accessed and queried by power users at the transit agency. Output data could be transferred to the City Transit Authority for internal use.

Documentation, support, and maintenance:
The Contractor would provide online documentation detailing the usage and theory of all UI tools, an output data dictionary, and user-friendly explanations of the models and algorithms applied to the data. The Contractor would also provide onsite training and/or meetings for up to three (3) consecutive business days per year as requested by the City Transit Authority, and up to one hundred and twenty (120) hours of remote support, meetings, and training per year. The Contractor would provide unlimited maintenance for any issues with its Services for which the Contractor is responsible.

Additional Features:
The Contractor would add new features and improvements to the SaaS and make them available to the City Transit Authority as they are developed and become generally available to the City Transit Authority.