Transit Signal Priority (TSP) System

Q (Program Goals & Success Criteria): Will local traffic engineering and signal operations staff be involved in the evaluation and final decision-making process?

A: No, NEORide and the three (3) listed transit agencies, Akron METRO RTA, Butler County RTA (BCRTA), and Toledo Area RTA (TARTA) will participate in the evaluation and vendor selection.

Q (Program Goals & Success Criteria): Can the Agency clarify whether participating agencies operate across multiple jurisdictions (city, county, or regional transit systems)?

A: Please see Attachment A – TSP Intersection Data Table to review the applicable municipal jurisdiction (in Column E) for each agency’s prioritized TSP intersections. All three (3) participating agencies are all Regional Transit Authorities (RTAs) and operate in multiple cities. I would advise vendors to review fixed route service maps on each agency’s website to better understand geographical operating conditions.

Q (Program Goals & Success Criteria): Does the Agency anticipate expanding the system in the future to support additional use cases such as emergency vehicle preemption or fleet priority?

A: This is a joint procurement opportunity between multiple agencies, thus the responses will vary by each individual agency, as well as each applicable jurisdictional traffic management entity. However, this project does not explicitly include emergency vehicle preemption integration, nor any plans to include emergency vehicle preemption.

Q (Program Goals & Success Criteria): Please confirm the desired deployment schedule, including any critical milestones, funding deadlines, or grant-related requirements.

A: This is a joint procurement opportunity between multiple transit agencies, thus the desired TSP deployment schedule is solely dependent on each individual transit agency, including any critical milestones, funding deadlines, and grant-related requirements.

Q (Program Goals & Success Criteria): Are there any specific funding deadline associated with the project funding?

A: This is a joint procurement opportunity between multiple transit agencies, thus any funding deadline associated with project funding is variable and dependent on each individual participating transit agency.

Q (Program Goals & Success Criteria): Page 11 references cross jurisdictional coordination. Can you please define expectations/ use cases?

A: Please see Attachment A – TSP Intersection Data Table to review the applicable municipal traffic jurisdiction (in Column E) for each agency. All expectations and TSP solution use cases are well-defined and detailed in Section 4: Scope of Work and specific to public transit operations and fixed route services. Below is a brief summary of the TSP solution expectations: • Integrate with the Agency's CAD/AVL system • Use a cloud-hosted, centralized decision engine • Support conditional priority request generation (PRG) logic and priority request server (PRS) granting logic capabilities • Support real-time transit vehicle position and schedule adherence analysis • Provide standards-based communications to traffic signal controllers (e.g., NTCIP where supported/required by the jurisdiction) and provide documented APIs for reporting, dashboards, and integrations • Minimize roadside hardware requirements • Provide real-time monitoring and dashboard interface platform/portal • Meet standardized cybersecurity and data privacy requirements • Provide documentation, training, and warranty support • Support cross-jurisdictional coordination across all participating agencies

Q (Cloud Architecture & Hosting Requirements): Cybersecurity is mentioned in RFP however there is no specific requirement. We strongly recommend adding a requirement that the vendors software, particularly in a cloud hosted system, minimally meet SOC2 as verified through an independent annual audit, and include a copy of SOC3 certificate.

A: During the process of drafting an RFP for this procurement opportunity, the three (3) participating transit agencies do not have any formalized, nor Board-adopted cybersecurity policies and/or requirements related to cloud-hosting TSP. The industry standard of SOC2 compliance for traffic communication data protection is encouraged (though not required) to be provided and supported with documentation, such as a certificate, in submitted proposals.

Q (Cloud Architecture & Hosting Requirements): Can the Agency confirm that communications are currently established and operational at all intersections included in the initial deployment? Can you provide detail on the type?

A: All information related to current intersection signal controllers is provided in Attachment A – TSP Intersection Data Table. At this time, it cannot be confirmed if all are operational and communication-capable since this is listed as task in the Scope of Work for the project. The task in Section 4.1 outlines that the vendor “shall review and evaluate compatibility with all existing Agency’s components and current operations that are relevant to implementing a cloud-based, centralized TSP system”. And, Section 4.5 TSP System Interfaces requires the vendor to provide “an assessment of the traffic signals along identified corridors to inventory the current hardware and software at each intersection and determine the need for any additional hardware” in order to determine the communication capabilities of the existing signal controllers.

Q (CAD/AVL Integration): What interface standards or protocols are required for CAD/AVL system integration?

A: The TSP solution must be capable of integrating the agency's CAD/AVL system, which is outlined for each agency in Attachment A – TSP Intersection Data Table, as the primary mechanism for detecting approaching vehicles and generating priority requests. The TSP solution is required to support the standards-based NTCIP (1202 and 1211) and SAE J2735 protocols for signal request communications, signal status, and priority request messages with traffic controllers.

Q (CAD/AVL Integration): Are there defined data quality requirements or known limitations associated with the AVL system(s)?

A: It is currently unknown if there are any existing data quality limitations associated with each transit agency’s AVL system. This is a critical task outlined in Section 3: Proposal & Service Requirements and Section 4: Scope of Work. The vendor will need to assess and identify any existing AVL software components that are incompatible with a cloud-hosted TSP operating system and provide recommendations and/or planning framework to upgrade the existing equipment.

Q (CAD/AVL Integration): Please confirm the GPS update (ping) rate for each AVL system included in the project.

A: The available information for vendors related to AVL ping/refresh rate is listed in in Attachment A – TSP Intersection Data Table.

Q (CAD/AVL Integration): For vehicles without reliable AVL feeds, is there existing onboard hardware capable of supporting GPS-based tracking integration?

A: These factors are currently unknown and listed as tasks in Section 3: Proposal & Service Requirements and Section 4: Scope of Work as part of this project. The vendor will need to explicitly identify any existing transit agency hardware and/or software (this includes on-board bus units) that would be incompatible with a TSP solution and operability. If any existing on-board hardware is identified as incompatible with the vendor’s TSP solution, the vendor will need to provide a customized list of services, equipment, software, and additional fees (if applicable) required to install, configure, test, and deploy all hardware and software products for the vendor’s TSP solution.

Q (CAD/AVL Integration): Will vendors be permitted to review and validate AVL data quality prior to final proposal submission?

A: The available AVL data for vendors is listed in Attachment A – TSP Intersection Data Table.

Q (CAD/AVL Integration): Please provide the anticipated procurement and implementation schedule for Akron’s CAD/AVL system.

A: Akron METRO’s CAD/AVL RFP submission closed on 1/15/2026 and is currently in the process of proposal evaluation. An implementation schedule/deadline has not been provided, but there is an expectation for a CAD/AVL to be selected soon.

Q (Signal System & Controller Environment): Are agencies open to controller firmware upgrades or standardization efforts if they improve priority performance and system integration?

A: Potentially yes, though it is dependent on each individual agency’s available funding and programming schedule. As part of this project, the vendor will need to identify any existing transit agency hardware and/or software that would be incompatible with cloud-based TSP operability.

Q (Signal System & Controller Environment): Can the Agency provide a complete and current inventory of traffic signal controller hardware and firmware for all included intersections? The provided inventory appears incomplete.

A: The available traffic signal controller data for vendors is listed in Attachment A – TSP Intersection Data Table.

Q (Signal System & Controller Environment): For BCRTA locations referencing Opticom Phase Selector, can the Agency confirm the underlying traffic signal controller make, model, and firmware?

A: The information provided by BCRTA is as follows: Opticom 3100 GPS Radio Unit, Opticom 764 Multimode Phase Selector, and Opticom 2101 Low Priority Radio/GPS Control Unit.

Q (Deleted): Deleted

A: NA

Q (Signal System & Controller Environment): Please provide a detailed list of all controller makes, models, and firmware versions currently deployed at each intersection included in the project.

A: The available traffic signal controller data for vendors is listed in Attachment A – TSP Intersection Data Table. This was all the information provided by the three (3) participating transit agencies.

Q (Deleted): Deleted

A: NA

Q (Priority Strategy & Decision Logic): Should priority decision-making consider real-time traffic conditions, active signal timing plans, and downstream corridor impacts?

A: Yes, as much as compatibly feasible in relation to the existing hardware and software components available for each agency. Though, it may be necessary for transit agencies to upgrade existing hardware, signal controllers, and/or firmware in order to utilize real-time traffic conditions and signal timing plans, if these TSP decision-making factors are desired.

Q (Priority Strategy & Decision Logic): Should the solution that dynamically conditions or adjusts priority requests based on corridor performance (e.g., maintaining progression, minimizing queue spillback), rather than granting priority solely based on request hierarchy?

A: This is a joint procurement opportunity between multiple transit agencies, including multiple municipal jurisdictions, which will require cross-functional coordination with the relevant traffic management jurisdictions. Thus, signal priority requests and conditions will need to be determined when working with each individual agency and municipal traffic management system.

Q (Data, Reporting & Performance Measures): Beyond standard TSP reporting, does the Agency expect the system to correlate priority events with signal performance metrics (e.g., ATSPM measures) and corridor travel time data?

A: Section 4.9: TSP Reporting, outlines the project requirements for signal performance measures that shall be generated from the TSP solution, see bulleted list below. The TSP solution shall also be scalable and support reporting of additional SPMs identified by each individual transit agency, including general traffic SPMs and intersection health (detection and priority signal status). • Speed and travel time (such as signal-to-signal, stop-to-stop, or time point-to-time point) • Intersection transit delay • Schedule or headway adherence at each intersection • Arrival on green • Green light success rate • Bus speed on arrival • Intersection delays vs. TSP requests

Q (Data, Reporting & Performance Measures): Are there specific reporting formats, dashboards, or performance KPIs that must be supported?

A: This is a joint procurement opportunity between multiple transit agencies, thus any performance KPIs shall be identified when working with each individual agency. In regards to reporting formats and dashboards. However please refer to Sections 4.7: TSP Access and User Interface and 4.9: TSP Reporting, which outline the standard requirements and configuration for reporting and dashboard functionality including both accessible real-time and archived data.

Q (Testing, Validation & Acceptance): What criteria will define successful system performance during the required 30-day burn-in period?

A: Though the criteria specifications for determining a successful system performance during the 30-day burn-in period are not well-defined in the Scope of Work. It should be assumed that the system performance during the 30-day burn-in period (and after the testing period) is operating with high reliability, accurate detection, and consistent signal performance without significant failures. The over-arching goal is that the TSP solution should quantitatively improve transit schedule adherence and travel times without negatively impacting general traffic or violating the operational constraints of the traffic signal management system.

Q (Testing, Validation & Acceptance): How will the latency requirement (≤ 5 seconds) be measured, tested, and validated?

A: This is a task for the vendor to perform, meaning it is the vendor’s obligation to assess, test, and validate the TSP latency requirement for compatibility and operability with a cloud-hosted TSP solution. As outlined in the Scope of Work, the vendor shall provide a complete centralized, cloud-based TSP solution including software and hardware assessment, engineering plans, integration method, implementation, testing, validation, performance tracking, and ongoing technical support.

Q (Testing, Validation & Acceptance): What documentation, reporting, and performance verification deliverables are required for final system acceptance?

A: Section 5.4: Testing and Verification Documentation outlines all documentation, reporting, and performance verification deliverables, which includes but is not limited to written test procedures, reports/results, waivers, inspection and test reports, and reporting documentation of final system acceptance. However, this is a joint procurement opportunity between multiple agencies, thus individual agencies could require additional specific reporting documentation for final system acceptance.

Q (Contract): The RFP, page 29, indicates that the contract term is two years, with up to 3 options to renew. The sample MSA, page 2, indicates that the term is three years, with up to 2 options to renew. Is the initial term 2 years or 3 years? Are the newel terms one year?

A: The draft MSA is correct in that the contract is three years with two (single) options to renew. The RFP has been updated to reflect that.

Q (Contract): The RFP (page 28) states that the Contractor’s indemnification obligation includes losses “arising out of, or resulting in whole or in part, directly or indirectly, from work or operations under the contract . . ..” By contrast, the sample MSA (page 8) provides that the successful bidder’s indemnification obligation applies only “to the extent such damage, such losses, costs, liability, and expenses arise out of or result directly or indirectly from work or operations under the Agreement . . ..” Will the successful proposer’s indemnification obligation include a clear allocation of responsibility through use of the limiting phrase “to the extent” as stated in the sample MSA?

A: The MSA language is the accurate indemnification language. The successful proposer should expect that an indemnification provision will be included in the final agreement that outlines the proposer's indemnification obligations. The successful proposer should anticipate that it will owe an indemnification obligation to NEORide to the extent such obligations occur under the awarded contract.

Q (Contract): The sample MSA reflects that “Customers own all rights to all non-algorithmic data . . ..” The RFP (at page 9) states that the solution should securely store, maintain, and make agency-accessible “all data collected from third party or other integrated platforms, traffic signal controllers, and relevant connected vehicle sources.” In addition, page 10 of the RFP requests that proposals describe, among other things, the TSP solution’s approach to “Agency data ownership and retention.” Could NeoRide please provide additional clarification regarding the specific information it is seeking with respect to data ownership and retention?

A: Each individual transit agency shall maintain accessibility, ownership, and retention of their applicable real-time and archived TSP data. Section 4.8 outlines that the vendor shall describe their data archiving functionality, as well as how archived data is stored, identified, and/or annotated for each agency.

Q (Contract): The RFP indicates that the resulting contract can be utilized by other NEORide entities. At the same time, this RFP requires Proposers to be familiar with each work site identified in the RFP, to specify a fixed cost for each line item on the pricing sheet, and states that no claims for additional compensation will be allowed based on a lack of knowledge about the work site. Should Proposers expect to have an opportunity to adjust pricing for NEORide members’ sites that are not identified on the TSP Agency Intersection Data Table?

A: Yes, the vendor will have an opportunity to adjust and negotiate pricing for any additional NEORide member(s) that are interested in utilizing an existing TSP vendor contract and services.

Q (Contract): Please confirm that the terms “participating Agency,” “participating agencies,” “existing Agency,” and “Agency-specific” on pages 10 -12 of the RFP refer to the agencies participating in the evaluation process and listed on page 9 of the RFP, i.e., Akron METRO RTA, Toledo Area RTA-TARTA and Butler County RTA- BCRTA.

A: Yes, there are three (3) transit agencies participating in this TSP joint procurement opportunity: 1) Akron METRO RTA, 2) Butler County RTA (BCRTA), and 3) Toledo Area RTA (TARTA).

Q (Contract): Please clarify the warranty requirement at page 18 for a “minimum of 3-year warranty period.” Specifically, does this refer to a 3-year term for the cloud hosted software?

A: Yes, this warranty requirement is specific to the TSP cloud-hosted software provided by the vendor.

Q (Contract): Please clarify whether payment for the deliverables will be made by NEORide or the Customer. The sample MSA details that the successful proposer will invoice the Customer; however, the RFP suggests that NEORide will make payments (page 30). Similarly, the sample MSA and RFP have conflicting provisions on the party entering into a contract with the successful proposer. Please clarify the contracting parties and who will have responsibility for acceptance of, and payment for, the solution.

A: Payments will be made by the customer.

Q (Contract): Do Akron METRO RTA, Toledo Area RTA-TARTA and Butler County RTA- BCRTA each have a proposed implementation timeline?

A: No, not at this time. A TSP implementation timeline will need to be determined when working with each individual transit agency.

Q (Priority Strategy & Decision Logic): Can the Agency describe how transit signal priority requests should be handled when multiple or competing requests occur?

A: No, not at this time. That will need to be determined when working with each individual agency, as well as require cross-functional coordination with the jurisdictional traffic management entity. Shown in Section 4.2 of the Scope of Work, the TSP solution should be capable of a) Green extension; b) Early green/truncated red; c) Phase rotation/insertion; and/or d) Conditional priority.

Q (NTCIP Traffic Signal Controllers): 1. Is the project going to update the controllers that are not NTCIP capable on this project. NTCIP 1211 is needed to perform TSP and not all the listed existing controllers are capable.

A: Potentially yes, the vendor will need to assess and identify any signal controllers and firmware that are incompatible with a cloud-based TSP solution and NTCIP 1211 communication standards. However, any traffic controller upgrades will be dependent on each individual agency’s funding availability and timeline for implementation.

Q (Evidence of Insurability): The RFP requests a Bureau of Workers' Compensation Certificate under Evidence of Insurability. If field work will be performed by an identified Ohio-based subcontractor, may the subcontractor's workers' compensation documentation be used to satisfy this requirement? Alternatively, may evidence of the prime contractor's worker's compensation insurance be provided from an equivalent state agency?

A: yes

Q (No subject): Many of the traffic signal controllers listed in the agency intersection data table are older technology that would not support the full functionality of cloud-based TSP. Should proposers provide prices for both Econolite and Yunex controllers? Specifically for Toledo, which has a mix of both controller types, should controllers be upgraded with the same brand already in place at an intersection, or is one brand preferred?

A: Yes, it would be helpful for the vendor to include additional pricing to upgrade any incompatible traffic signal controllers since assessing and identifying any equipment that could not function with a cloud-based TSP solution is listed as a task in the Scope of Work. However, please note that any hardware and/or firmware upgrades will be dependent on each individual transit agency’s funding availability and timeline for implementation.

Q (No subject): The agency intersection data table lists legacy hardware TSP equipment instead of traffic signal controller types for Oxford. Is there any additional information about existing traffic signal control equipment available?

A: Yes, the City of Oxford intersections for BCRTA include Opticom 3100 GPS Radio Unit, Opticom 764 Multimode Phase Selector, and Opticom 2101 Low Priority Radio/GPS Control Unit.

Q (No subject): Where should the pricing (separated from the technical proposal) be uploaded? Under section 4 as a separate file, or in a different section?

A: Yes, please upload any supplemental pricing proposals under Section 4 as a separate file.

Q (No subject): Can additional narrative information about pricing structure be submitted to supplement the proposal pricing sheet?

A: Yes, you can include any additional narrative information related to pricing structures and additional pricing proposals.

Q ( Section 3.3 / 3.4 — Corridors and Intersections — Scope Clarification): The Project Overview states the solution will be deployed "across three (3) Agency priority corridors and intersections." Does NEORide intend for TSP to be activated at every listed intersection within each corridor, or only at select priority intersections within those corridors?

A: This is a joint procurement opportunity between three (3) transit agencies, thus this will need to be determined when working with each individual agency. However please note that the identified priority intersections listed in Attachment A – TSP Intersection Data Table could change based on necessary equipment upgrades, available funding, implementation timelines, and cross-functional coordination with traffic management jurisdictions.

Q (Section 3.6.4 — Robust Cellular Connectivity — Definition and Responsibility): Section 3.6.4 references "robust cellular connectivity" as an exception to the software-first architecture requirement and directs Proposers to describe their proposed communications approach, including whether field communications hardware, SIMs, data plans, and carrier management are Proposer-provided or Agency-provided. Can NEORide clarify the minimum performance threshold intended by "robust" — specifically in terms of latency, uptime, and redundancy — beyond the priority call latency target of three seconds and the 99.9% system availability requirement stated in Section 3.6.6?

A: NEORide is requesting vendors to use the generalized industry guidelines to ensure an effective and reliable TSP system (i.e. “robust”) for communication performance thresholds. This includes a target of three (3) seconds or less for transmission and a centralized network (cellular/GPS communication) detection for both latency and redundancy performance.

Q ( Section 7.3 — Governing Law and Multi-State Members): Section 7.3 states that the rights and duties of the parties shall be governed by the laws of the State of Ohio, with venue in Medina County. NEORide has member agencies in 12 states. If agencies outside Ohio execute a Participation Agreement under the resulting Master Services Agreement, would those agencies and their participating jurisdictions also be subject to Ohio law, or would their local laws and regulations govern their individual participation agreements?

A: Transit agencies outside of Ohio will have the ability to specific local jurisdiction under the participation agreement.

Q ( Appendix A / Section 3.5 — CAD/AVL Procurement Status and Integration Dependency): Appendix A indicates that Akron METRO is currently in procurement for its CAD/AVL system. Section 3.5 requires Proposers to identify incompatibilities with existing Agency hardware and software. Will the TSP contract award or Notice to Proceed be contingent on Akron METRO's CAD/AVL selection?

A: NEORide is requesting vendors to use the generalized industry guidelines to ensure an effective and reliable TSP system (i.e. “robust”) for communication performance thresholds. This includes a target of three (3) seconds or less for transmission and a centralized network (cellular/GPS communication) detection for both latency and redundancy performance.

Q (Appendix A / Section 3.6.2 — Non-Functional Detection Infrastructure): Appendix A lists several intersections with "None" or "Removed" as the detection type, and at least one (Monroe & Midwood) where the controller is also listed as "Removed." Section 3.6.2 states the Project seeks a hardware-minimal solution that leverages existing AVL data as the primary vehicle detection mechanism. Does NEORide intend for non-functional or removed detection infrastructure to be remediated as part of this project scope?

A: There is no expectation, nor requirement, for a full infrastructure and/or equipment remediation for this project, but rather the vendor will need to assess and identify any existing hardware and/or software that is incompatible with a cloud-based TSP solution and provide recommendations and planning framework to upgrade the existing components. Any equipment and/or software upgrades will be dependent on and determined by each individual transit agency’s funding availability.

Q (Section 3.6.4 — VPN Topology): Section 3.6.4 requires the TSP solution to support VPN-based communications and directs Proposers to describe the proposed VPN approach, including site-to-site or client-based topology. For the three participating agencies — Akron METRO, TARTA, and BCRTA — each operating within different municipalities and traffic management jurisdictions: should Proposers assume a separate site-to-site VPN is required for each participating municipality's Traffic Management Center (Barberton, Akron, Toledo, Oxford, etc.), or will a single agency-level VPN connection suffice for each transit agency?

A: This is a joint procurement opportunity between three (3) transit agencies, thus this will need to be determined when working with each individual agency.

Q ( Section 1.2 — NEORide Administrative Fee Scope): Section 1.2 states that NEORide's procurement is funded through an administrative fee of 0.75% based on "actual vendor project sales." Does this fee apply only to the initial implementation and one-time costs, or does it also apply to recurring annual SaaS fees, hosted services, and maintenance fees for the duration of the contract and any renewal options?

A: It applies to the entire contract including recurring annual SaaS fees, hosted services, and maintenance fees for the duration of the contract.

Q (8. Section 3.7.6 / Section 7.5 — Warranty Term vs. Contract Term): Section 3.7.6 requires a minimum 3-year warranty. Section 7.5 establishes a base contract term of two years. Should the pricing proposal reflect the cost of a 3-year warranty within the 2-year base term — meaning warranty coverage extends beyond the base term regardless of renewal — or should the third warranty year be tied to the first option-to-renew period?

A: The RFP has been updated to clarify that the contract is for three years with two options to renew.

Q (Appendix A / Sections 3.5, 3.6.1, 3.6.3 — Signal Controller Compatibility and Upgrade Responsibility): Where controller upgrades are required to achieve NTCIP 1211 compliance within the Proposer's scope of work, or the responsibility of the participating municipalities?

A: The vendor will need to assess and identify any existing equipment that is incompatible with a cloud-based TSP solution and provide recommendations and planning framework to upgrade the existing incompatible controllers. Any equipment and/or software upgrades will be dependent on and determined by each individual transit agency’s funding availability.

Q (Section 3.7.2 / Appendix A — Available Documentation for TSP Corridor Planning): What documentation is available for TSP planning on the identified study corridors (e.g., existing signal timing plans, traffic counts, coordination plans, or prior studies)?

A: This is a joint procurement opportunity between three (3) agencies, thus the any previous studies, reports, traffic counts, etc. will vary by each individual agency. I would suggest exploring each transit agency and MPO websites for archived planning and engineering study/report documentation.

Q (Section 3.6.4 / 3.6.5 — Traffic Agency Remote Monitoring and Central Management Capabilities): What are the capabilities of the participating traffic jurisdictions to remotely monitor and manage traffic signals? If a central traffic management system is in use, please provide details on the platform and its integration interfaces.

A: This is currently unknown and will need to be determined when working with each individual transit agency, as well as cross jurisdictional coordination with municipal traffic management systems to understand the existing capabilities.

Q (Section 3.6.10 / 3.7.3 — Signal Timing Plan Requirements): Can NEORide specify how many time-of-day signal timing plans are desired for any signal timing modifications developed as part of this project?

A: No, not at this time. This is joint procurement opportunity between multiple agencies, thus the responses will vary by each individual agency, as well as each jurisdictional traffic management system.

Q (Section 1.1 — Billing Structure): Section 1.1 notes that billing may be directed to individual NEORide agencies or to NEORide directly depending on the terms of the agreement. For the three primary participating agencies — Akron METRO, BCRTA, and TARTA — does NEORide have a preference for consolidated invoicing or individual billing per agency at this stage?

A: Individual billing per agency.

Q (10. Section 3.6.10 / Section 3.7.3 — Phased Implementation Timeline): Section 3.6.10 references a phased approach to testing and implementation, and Section 3.7.3 requires the Proposer to coordinate signal timing modifications with each jurisdictional municipality. Are there target go-live dates for each of the three agencies, or is the expectation that all three agencies will be onboarded concurrently? Any known constraints — such as municipal signal timing freeze windows, construction projects, or coordination dependencies — that affect implementation sequencing would be helpful context.

A: There are currently no identified TSP deployment timelines/deadlines for each participating transit agency, nor do the agencies need to be on-boarded concurrently. Each transit agency will be working independently of each other and have their own phased approaches for TSP configuration, testing, implementation, etc. Any current and future constraints related to municipal signal timing freeze windows, construction projects, or coordination dependencies are also currently unknown and will need to be determined when working each individual transit agency.

Q (11. Appendix A / Section 3.6.3 — Unit Pricing for Future Intersections): Appendix A notes that additional intersections may be added beyond the initial list. Section 3.6.3 requires the solution to be scalable. Should the Proposal Pricing Sheet (Attachment D) include a unit price per intersection for future additions, to allow participating agencies to expand via the Master Services Agreement without re-soliciting?

A: Yes, that would be a constructive proposal approach in order to facilitate a scalable methodology to potentially add intersections in the future for the three (3) participating agencies, if individual agencies desire to do so.

Q (Bid Bond): Can you please confirm if a bid bond would be required for the work done under this contract?

A: No bid bond would be required.

Q (Data Collection): Will any intersections require counting?

A: This question needs further clarification. It’s unclear what are you asking that should be counted.

Q (Modeling ): Is a Synchro model required to determine TSP timings?

A: The RFP and Scope of Work do not require a specific type/brand of traffic management modeling simulation software.

Q (Refresh Rate): The data table shows a refresh rate of 5s at most intersections. What data is being refreshed?

A: The refresh rate is in reference to the transit agency’s AVL software. AVL is the automatic vehicle location. This software is used by transit agencies to track vehicles in real-time using GPS.

Q (Controllers): Is there a special provision or any specification defining the work required to replace a traffic signal controller?

A: There is no special provision to replace traffic signal controllers. However, there are tasks outlined in Section 4: Scope of Work specifying that the vendor will need to assess and identify any existing signal controller equipment that are incompatible with a cloud-hosted TSP system and provide recommendations and/or planning framework to upgrade the existing equipment. However, any traffic signal controller upgrades will be contingent on each individual agency’s funding availability and timeline for implementation.

Q (Controller Software): Is there a special provision or any specification defining the work required to upgrade the software of a traffic signal controller?

A: There is no special provision to replace traffic signal controller software. However, there are tasks outlined in Section 4: Scope of Work specifying that the vendor will need to assess and identify any existing signal controller software and components that are incompatible with a cloud-hosted TSP system and provide recommendations and/or planning framework to upgrade the existing software. However, any traffic signal controller software upgrades will be contingent on each individual agency’s funding availability and timeline for implementation.

Q (Network Port): Is there a network port available in each traffic signal cabinet to accommodate a PRS if required?

A: The traffic signal cabinets for the participating agencies have not been examined for this RFP, so it is unknown if network ports are available. However, as outlined, in the Project Overview, this TSP project shall implement a cloud-based TSP solution using real-time vehicle data by utilizing existing transit agency Automatic Vehicle Location (AVL) data as the primary mechanism for detecting approaching vehicles and generating priority requests, minimizing reliance on additional on-vehicle emitters or roadside detection hardware, such as in signal cabinets.

Q (GPS): What is the refresh rate for the GPS position of each bus?Typically, we expect vehicle position updates at a maximum interval of 2 seconds.

A: The available information for vendors related to the AVL refresh rate is listed in in Attachment A – TSP Intersection Data Table.

Q (TSP Parameters): We don’t see any indication that you are requesting the design of TSP parameters. The FRP points to the need for a central TSP solution only. Are you looking for TSP parameter design as part of this project?

A: Yes, TSP parameter design is a component of this project. Please reference Sections 4.2: TSP Solution, 4.6: TSP Operations, and 4.10: TSP Implementation in the Scope of Work to better understand the TSP configuration and signal controller design parameters.

Q (Process): The RFP notes that NEORide’s procurement is funded through a 0.75 % administration fee paid by the awarded contractor on actual project sales. Could you clarify how frequently this fee must be reported and remitted (e.g., monthly or quarterly), what supporting documentation will be required and whether any caps or exemptions apply?

A: Quarterly remittance will be required or the vendor can make a one-time for the total cost of the contract. A copy of a PO and participation agreement with full budget will be required.

Q (Onboard Hardware): Since the RFP emphasizes a cloud based solution that minimizes roadside hardware and leverages existing transit systems, could NEORide specify the types of on board AVL units, radios and communication networks currently used by Akron METRO RTA, TARTA and BCRTA? Should vendors assume responsibility for supplying new on board hardware if incompatibilities are identified?

A: All available information for vendors related to the AVL software and traffic signal controllers is listed in in Attachment A – TSP Intersection Data Table. As outlined in Section 4: Scope of Work, the vendor will need to assess and identify any existing equipment that is incompatible with a cloud-hosted TSP operating system and provide recommendations and/or planning framework to upgrade the existing equipment, which could include the vendor supplying new on-board hardware, if desired by the transit agency.

Q (Bus Schedules and Headway): The description calls for integrating with agency CAD/AVL systems and providing real time monitoring and dashboard functions. Will participating agencies provide baseline schedules and headway information in machine readable formats, or is it expected that vendors will derive schedule adherence metrics from the AVL feeds?

A: The project is requesting that AVL feeds and data be the primary mechanism for ensuring schedule adherence. It is unknown if the participating transit agency’s CAD/AVL systems can currently provide schedules and headway information in machine readable formats.

Q (TSP Treatments ): The RFP requires support for multiple TSP treatments (green extension, early green/red truncation, phase rotation/insertion and conditional strategies) and corridor level coordination. Are there jurisdictions among the participating agencies that prohibit or restrict certain priority treatments? If so, how should the system accommodate different policies when buses traverse multiple jurisdictions?

A: This is a joint procurement opportunity between multiple transit agencies, including multiple municipal traffic jurisdictions, which will require cross-functional coordination for this project. The vendor will be required to work with each participating transit agency, as well as the municipal traffic jurisdictions to determine how to accommodate varying policies across city/county limits.

Q (Regional Traffic Data): The summary mentions the need for real time monitoring and predictive, corridor level strategies that consider downstream intersections and network conditions. Does NEORide anticipate providing access to regional traffic data (e.g., from TMCs or connected vehicle infrastructure), and are there specific data formats or APIs that vendors should plan to support?

A: NEORide will not be providing access to regional traffic data. Instead, the vendor will be required to work with each participating transit agency, as well as the municipal traffic jurisdictions, and potentially MPOs to request access to regional traffic data.

Q (Dashboard): The RFP envisions a browser agnostic dashboard that supports multiple accounts and configurable reporting. Could you describe the expected user roles (transit operations staff, traffic engineers, municipal administrators, etc.) and any requirements for role based access control, single sign on or multifactor authentication?

A: This is a joint procurement opportunity between multiple transit agencies, including multiple municipal traffic jurisdictions, as such this will need to be determined when working with each agency in order to identify user roles, accessibility control, and authentication.

Q (Section 8.1 ACCESS TO RECORDS AND REPORTS): Please clarify whether or not a bid guarantee is required, and if so, how is the amount determined?

A: No bid guarantee is required.

Q (Section 3.6 Scope of Work): Which CAD/AVL providers do NEORide agencies utilize?

A: Please reference Attachment A – TSP Intersection Data Table to review which the CAD/AVL providers utilized for each participating transit agency. However, please note that Akron METRO is currently procuring a new CAD/AVL provider. Their RFP submission closed on 1/15/2026 and is currently in the process of evaluation. It should be assumed that Akron METRO’s new CAD/AVL software selection will be fully updated and compatible with a cloud-hosted TSP solution.

Q (Section 3.6.4 TSP Architecture): The TSP solution shall adhere to Agency-specific network, cybersecurity, and IT requirements, including the use of VPNs for TSP-related communications and data exchanges (if applicable). Is this documentation available, and can it be provided for responding to the RFP?

A: During the process of drafting an RFP for this procurement opportunity, the three (3) participating transit agencies do not have any formalized, nor Board-adopted cybersecurity policies and/or VPN requirements related to cloud-hosting TSP. Thus, the expectation is to use the industry standard of SOC2 compliance for traffic communication data protection is encouraged to be provided and supported with documentation in submitted proposals.

Q (Signal System & Controller Environment): Can the Agency confirm that all traffic signal controllers included in the project are compliant with applicable NTCIP standards (including, but not limited to, NTCIP 1202 and NTCIP 1211)? If not, please identify which intersections and controllers are not compliant.

A: No, not at this time. Instead, this is a task outlined in Section 4: Scope of Work for the vendor to assess and identify any signal controllers and firmware that are incompatible with a cloud-based TSP solution and NTCIP 1211 communication standards. However, any traffic controller upgrades will be dependent on each individual agency’s funding availability and timeline for implementation.

Q (Signal System & Controller Environment): In the event that controller upgrades (hardware and/or firmware) are required to support the proposed Transit Signal Priority solution, please clarify which party (Agency, participating jurisdictions, or Contractor) will be responsible for the associated costs.

A: This is a joint procurement opportunity between multiple transit agencies, including multiple municipal traffic jurisdictions, as such this will need to be determined when working with each agency in order to identify which public entity will be responsible for the associated costs to potentially upgrade signal controllers. Though, the most likely scenario is the transit agency will be liable for any costs to upgrade signal controller equipment related to TSP implementation.

Q (Deleted): Deleted

A: NA