RFP 2384785615 Info Packet.pdf

RFP # 2384785615 1 of 25 RFP Information Packet

RFP Number 2384785615 Technology Services September 4, 2026

Request for Proposals (RFP) for

Multimodal Automated Traffic Signal Performance Measure (ATSPM) System

Project Information Packet Section 1: Opportunity Overview

Section 2: How Your Proposal Will Be Evaluated

Section 3: Scope of Work

Section 4: Exhibits

Section 5: Sample Contract

Section 6: RFP Terms and Conditions

RFP # 2384785615 2 of 25 RFP Information Packet

RFP at a Glance Proposals Due:

September 21st, 2026 by 5:00 p.m. Pacific Time

Summary:

The purpose of this RFP is to find qualified proposers who will install the latest version of Open Source Automated Traffic Signal Performance Measure (ATSPM) software. Qualified proposers will also develop custom dashboards and metrics focused on multimodal users, technology recommendations, and acceptance testing as well as conduct training for PBOT staff.

Optional Pre-Proposal Meeting:

September 10th, 10:30 a.m. Pacific Time

Join: https://teams.microsoft.com/meet/23336343933575?p=i8PyPjdsMchLIeqFqs

Meeting ID: 233 363 439 335 75

Passcode: XB9pe2ww

Refer to Section 1.6: Optional Pre-Proposal Meeting for details.

Submit Your Proposal:

Submit Your Proposal via City of Portland Bid Portal.

Refer to the Proposal Response Packet: Section 4: Exhibit A Submission Instructions for details.

Have Questions or Need Help? Single Point of Contact:

Send questions, requests for clarification, or requests for assistance by September 14th, 2026 by 5:00 p.m. Pacific Time. Any questions received after may not be answered. Only the Single Point of Contact can answer questions about this RFP.

Patrick O’Quinn Procurement Specialist Procurement Services

(971) 678-6326 Patrick.OQuinn@portlandoregon.gov https://teams.microsoft.com/meet/23336343933575?p=i8PyPjdsMchLIeqFqs https://service.ariba.com/Discovery.aw/ad/profile?key=AN11181807487 mailto:Patrick.OQuinn@portlandoregon.gov

RFP # 2384785615 3 of 25 RFP Information Packet

Section 1: Opportunity Overview

1.1 Background

Portland Bureau of Transportation Overview The purpose of this RFP is to find qualified proposers who will install the latest version of Open Source Automated Traffic Signal Performance Measure (ATSPM) software. Qualified proposers will also develop custom dashboards and metrics focused on multimodal users, technology recommendations, and acceptance testing as well as conduct training for PBOT staff.

Automated Traffic Signal Performance Measures (ATSPMs) Overview Automated Traffic Signal Performance Measures (ATSPMs) support a data-driven approach to traffic signal management. PBOT Signals, Street Lighting, and Intelligent Transportation Systems (SSL) has invested in ATSPMs as part of our central traffic signal system. The data provides detailed information about traffic signal operations and equipment health that engineers and electricians can use for troubleshooting, signal timing adjustments, and before/after assessments.

Needs Statement Most available ATSPMs report conditions for vehicular traffic – estimating delay, stops, and volumes for vehicles. PBOT is committed to increasing transportation options and helping all modes move around Portland. PBOT SSL Leadership, Engineering, and Maintenance staff need information about all modes traveling through signalized intersections to make informed decisions about operations, safety, and maintenance. This project will replace the existing ATSPM system with a new one that includes custom multimodal performance measures and dashboards.

The new ATSPM system will provide engineers and electricians information such as locations and times of day where people are experiencing long delays so signal timing settings can be adjusted, locations and times of day where drivers are traveling at high speeds so safety strategies can be applied, and locations where detection is broken so it can be fixed quickly.

See the Scope of Work below for a complete list of the City’s product specifications, technical and required services, and deliverables. Additional supplementary information can be found in Exhibit B System Requirements and Exhibit C Concept of Operations.

Information contained within Exhibit B and Exhibit C are only to be used for reference and information purposes.

RFP # 2384785615 4 of 25 RFP Information Packet

Applicable Sustainability Practices This section serves to provide an overview of sustainability practices that will apply to this RFP.

Deliverables

Whenever possible, deliverables shall be submitted electronically. Any paper-based deliverables shall be printed double-sided and in bindings or report covers that are fully recyclable, using materials containing post-consumer waste (PCW) recycled content.

Green Meeting Practices

Unless otherwise indicated, video conferencing and/or audio conferencing shall be maximized in lieu of in-person meetings that would require long-distance travel for any participants. If in person meetings are to be conducted the following best practices shall apply:

1. Reducing paper waste through online communications and/or meeting apps, double-sided printing, electronic signage, reusable name tags, etc.

2. Reducing food waste by utilizing reusable food serviceware (coffee carafes, durable dishware, etc.) getting accurate attendee head counts for meals, utilizing water pitchers/dispensers (no bottled water), serve food family-style or via buffet (avoid boxed lunches), etc.

3. Offering healthy, low-carbon foods.

4. Select meeting/event locations that are easily accessible by public transit and/or biking/walking.

5. Select meeting venues that follow sustainable practices, such as comprehensive recycling and composting programs.

6. Any paper meeting/event materials utilize paper made with high percentages of post-consumer waste (PCW) recycled content and are fully recyclable.

1.2 Outcome Goals

1. Improve ability to monitor operations, safety, and maintenance for transit, pedestrians, and bicyclists at signalized intersections in Portland.

2. Simplify monitoring into the least number of software platforms while still meeting needs.

3. Aggregate new and existing metrics that will help PBOT SSL Leadership, Engineering, and Maintenance staff make decisions about signalized intersections.

4. Develop metrics that can be shared with other PBOT Groups (e.g., Planning, Safety, Design, and Operations).

RFP # 2384785615 5 of 25 RFP Information Packet

5. Document methodologies that can be shared with other public agencies and academic partners.

1.3 Contract Details

The City intends to award a single Time & Materials Contract from this solicitation. Said Contract will carry a five (5) year initial term with three (3) years being allotted for work on implementing the ATSPM system and two (2) years being allotted for maintenance & support once the system is implemented (warranty period). The Contract will be allotted up to five (5) additional renewal years for annual post-warranty maintenance & support. Up to $425,000.00 is currently budgeted for this Contract.

1.4 Estimated RFP Timeline

The timeline below is an estimate for the RFP and Contracting process.

Event Date Pre-Proposal Meeting September 10th, 2026 at 10:30 a.m.

Deadline for RFP Questions September 14th, 2026 at 5:00 p.m.

Written proposals due at 5:00 p.m. (for Phase 1) September 21st, Short list posted and Phase 2 instructions shared [if applicable] Early October, Notice of Intent to Award Posted Mid to Late October, 2026

The City will adjust the schedule as necessary.

1.5 Grant Funding

Funding sources are local and federal. Federal funds include funds provided through the Surface Transportation Block Grant Program (STBG) and Carbon Reduction Program (CRP) passed through State of Oregon Department of Transportation (ODOT) Local Agency Certification Program Supplemental Project Agreement No. 73000-00006678. Relevant Contract provisions are included as part of the Sample Contract included in Section 5 and will be adopted as part of any final, negotiated contract.

RFP # 2384785615 6 of 25 RFP Information Packet

1.6 Optional Pre-Proposal Meeting

There will be a pre-proposal meeting scheduled for this Project on Thursday, September 10th, 2026 at 10:30 a.m. via Microsoft Teams.

Join: https://teams.microsoft.com/meet/23336343933575?p=i8PyPjdsMchLIeqFqs

Meeting ID: 233 363 439 335 75

Passcode: XB9pe2ww

This meeting is not mandatory. You can submit a proposal without attending this meeting.

The City of Portland will make reasonable accommodation for people with disabilities. Please notify the Official RFP Contact at least two (2) Business Days prior to the event, by the City’s TTY at 503-823-6868, or by the Oregon Relay Service at 1-800-735-2900.

1.7 Addenda

The City will share more information about this RFP if something is missing or unclear. The City will share this information as an addendum (or addenda, if more than one). The City will post addenda on the City of Portland Bid Portal.

Addenda issued seventy-two (72) hours or more before the due date are binding. The seventy-two (72) hour window excludes Saturdays, Sundays, and City-observed holidays.

You are responsible for complying with the addenda, even if you do not see it.

https://teams.microsoft.com/meet/23336343933575?p=i8PyPjdsMchLIeqFqs https://www.portland.gov/policies/human-resources-administrative-rules/leaves/hrar-602-holidays

RFP # 2384785615 7 of 25 RFP Information Packet

Section 2: How Your Proposal Will Be Evaluated

2.1 Proposal Review and Selection

Evaluation Overview The City will appoint an Evaluation Committee (Committee) to evaluate the proposals received.

To score proposals, the Committee will evaluate each proposal using the criteria below. The Committee may seek outside expertise. The Committee will require at least ten (10) Business Days to evaluate and score the proposals.

The City will decide how or when to proceed through the evaluation process. The City will also decide if additional clarifications are needed, when to begin or end negotiations, reasonable timelines, and whether to open negotiations with a lower scoring proposer.

The City can also decide to cancel the solicitation or reject all proposals.

Evaluation Process Each proposal is evaluated using these criteria:

Responsiveness, Responsibility, and Mandatory Criteria

The City will determine if you are a Responsible Proposer who has submitted a Responsive Proposal (ORS 279B.005).

Refer to Portland Public Contracting Rules for details.

https://www.portland.gov/policies/public-contracting-rules

RFP # 2384785615 8 of 25 RFP Information Packet

Evaluation Phase 1–Written Scoring

Proposals that meet the responsiveness, responsibility, and mandatory requirements will be evaluated in Evaluation Phase 1. The Committee will conduct a detailed review of the written proposals.

Phase 1 Evaluation Criteria

Evaluation Criteria Percent of total points

Percent of points for sub-criteria

Proposer Capabilities 30 — Project Team 10 — Project Approach 20 — Pricing 20 Corporate Responsibility 20 —

Equal Employment Opportunity and Access in Subcontracting 10

Equal Opportunity Employer and Community Involvement 5

Sustainable Business Practices — 5 Total 100%

Short Listing

At the end of any evaluation phase, the Evaluation Committee may focus on only a limited number of proposals by developing a “short list” based on the scores. The number of proposals on the short list depends on the number of proposals the Committee believes have a reasonable chance of leading to a contract award. If you are eliminated from further consideration, you will be notified by a Notice of Shortlisting posted on the City of Portland Bid Portal.

Subsequent Evaluation Phases The City will proceed with subsequent evaluation phases as needed. These phases may include oral interviews, demonstrations, presentations, site visits, clarification of the proposals, or other activities.

If you are invited to participate in subsequent evaluation phases, the City will share additional information and instructions a reasonable amount of time before any further evaluation is held.

Evaluation Phase 2 – Interviews, Demonstrations, or Presentations [Optional]

The City may elect to conduct a second phase of evaluations once Phase 1 is complete. The scoring of Phase 2 generally will be as follows.

Phase 2 Evaluation Criteria

Evaluation Criteria % Allocation

Content of Phase 2 Evaluation 100

RFP # 2384785615 9 of 25 RFP Information Packet

To be determined

Information and instructions regarding Phase 2 Evaluations will be shared with short listed proposers if the decision is made to proceed with Phase 2.

Additional Optional Evaluation Phases and Methods

In addition to the evaluation phases above, the City can use other methods like best and final offers, serial negotiations, and competitive simultaneous negotiations.

Proposers eliminated at any stage of the evaluation process will be notified.

Total Overall Score

At the end of each evaluation phase, the points from that phase will be added to your cumulative score to determine your Total Overall Score. The proposer with the highest Total Overall Score may be identified as the finalist.

The selection of the finalist may also be based on negotiated costs and agreeing to the City’s terms and conditions within the City’s Sample Contract.

Negotiations will follow with the finalist. If successful, negotiations may result in a final award and Contract for the work. If the Contract with the finalist cannot be reached within a time that is reasonable to the City, the City may elevate the proposer with the next highest Total Overall Score to be the finalist.

2.2 Award Review and Protest

Review The City will post a Notice of Intent to Negotiate and Award on the City of Portland Bid Portal.

The Notice will identify the proposer(s) to which the City intends to award a contract.

Following the Notice of Intent to Negotiate and Award, the public may view proposal documents, in accordance with the Oregon Public Records Act.

If you were not awarded the Contract, you can ask for clarification or debriefing, request time to review the selection procedures, or discuss the scoring methods used by the Evaluation Committee.

Protests Proposers can challenge the City’s decision to exclude the proposer from the next step in the evaluation process, and to award a contract. If you wish to protest your elimination, you must submit a protest within seven (7) Calendar Days of the City’s posting of the Notice of Short List or Notice of Intent to Award.

Proposers can read Portland Public Contracting Rules regarding protest procedures, all of which may be found online: https://www.portland.gov/policies/public-contracting-rules.

https://www.portland.gov/policies/public-contracting-rules

RFP # 2384785615 10 of 25 RFP Information Packet

Proposers may also learn more about protests by reviewing ORS 279B.405 and ORS 279B.410.

Protesters may not use judicial appeal rights unless all protest and appeal rights are exhausted.

RFP # 2384785615 11 of 25 RFP Information Packet

Section 3: Scope of Work

1. PROJECT MANAGEMENT

1.1. PROJECT MANAGER – Designate a dedicated project manager who shall be committed to this project and fulfill the responsibilities described in this scope of work. The project manager shall have experience working on a project that installed and/or modified Open Source Automated Traffic Signal Performance Measure (ATSPM) software version 5.0. Responsibilities shall include, but not be limited to, the following:

1.1.1. Maintain bi-weekly communication with the PBOT Project Manager via email or phone.

1.1.2. Maintain adequate number of staff of qualified support personnel to perform the work necessary to complete the project on schedule.

1.1.3. Maintain contract administration consistent with federal requirements, including monitoring of project status and project budget.

1.1.4. If applicable, manage all sub-contractors and act as a single point of contact between sub-contractors and PBOT staff.

1.2. PROJECT TEAM – Project staff shall have, at a minimum, a knowledge base and experience with the following features and coding:

1.2.1. Open Source ATSPM software version 5.0

1.2.2. Installation, configuration, and custom programming of the following:

1.2.2.1. Apache ECharts for dynamic, interactive charts

1.2.2.2. API Layer using ASP.NET Core Web API for streamlined data interactions

1.2.2.3. Entity framework core object-relational mapper for compatibility with multiple databases, including, but not limited to, Microsoft SQL Server, PostgreSQL, Oracle, and MySQL

1.2.2.4. React and Next.js for front end framework

1.2.2.5. JSON data compression

1.2.2.6. Data aggregation and event logging using TPL Dataflow

1.2.2.7. Clean architecture for modular, testable, and maintainable code

1.2.2.8. Claims-based security

1.2.3. Collection, storage, and processing of data from the following sources:

1.2.3.1. Q-Free MAXTIME advanced transportation controllers (ATCs)

1.2.3.2. Wavetronix Matrix and Advance radar detection sensors

1.2.3.3. LiDAR detection sensors

1.2.3.4. Video detection sensors

1.2.3.5. Thermal detection sensors

1.2.3.6. TriMet API transit data

RFP # 2384785615 12 of 25 RFP Information Packet

1.2.3.7. RITIS/INRIX probe data

1.2.3.8. Safety camera speed and red-light-running data

1.2.4. Development and custom programming of performance measure dashboards

1.2.5. Implementation of on-premises (on-prem) solutions

1.2.6. Implementation of cloud-hosted solutions and migration from on-prem solutions to cloud-hosted solutions

1.2.7. Virtualized environments

1.2.8. Documentation of ATSPM calculations

1.2.9. Documentation of testing requirements and procedures for ATSPMs

1.2.10. Development of training materials

1.2.11. Training of stakeholders

1.3. PROJECT SCHEDULE – Develop and maintain a project schedule for the duration of the project. Within one week after notice to proceed (NTP), submit a detailed schedule indicating all milestone dates and major deliverables for PBOT review.

Upon approval of the project schedule, update the project schedule on a bi-weekly basis to reflect actual progress.

1.4. BI-WEEKLY PROGRESS MEETINGS – Arrange and attend bi-weekly project meetings/calls with the PBOT Project Manager to discuss project status, schedule, forecasted work, issues, etc., until final acceptance of the ATSPM system by PBOT.

1.5. STATUS SUMMARIES – Provide a project status summary with each monthly invoice that lists tasks completed during the month and anticipated tasks for the next month.

2. TECHNOLOGY RECOMMENDATIONS

2.1. Arrange and attend a minimum of two (2) meetings with PBOT and Portland Bureau of Technology Services (BTS) staff to discuss existing equipment, information security, and networking requirements.

2.2. Develop a memorandum with recommendations for the following near-term server hardware, data storage, and data sharing considerations.

2.2.1. Recommendations for on-prem server hardware.

2.2.1.1. Server hardware must meet federal requirements including Build America Buy America (BABA).

2.2.1.2. Recommendations shall include:

2.2.1.2.1. Minimum required processors (CPU, GPU), memory, storage (hard disk space), and network adapters

2.2.1.2.2. Number of Hyper-V virtual machines (if any)

2.2.1.2.3. Server model(s) that are compatible with existing

PBOT equipment

2.2.1.3. The on-prem solution shall have enough storage for 13 months of raw data from a minimum of 2,000 ATCs and 200 radar, video, or thermal detection sensors and 13 months of aggregated data from a minimum of 50 LiDAR detection sensors and external data

RFP # 2384785615 13 of 25 RFP Information Packet sources (including transit data from the TriMet API, probe data from RITIS/INRIX, and speed and red-light-running data from safety cameras).

2.2.1.4. PBOT shall procure the recommended server(s) with Windows operating system (OS), install the physical server(s), and connect to PBOT and BTS networking equipment.

2.2.2. Recommendations for data storage management solutions, such as partitioning data, for long term data storage. Recommendations shall include SQL database software.

2.2.3. Recommendations for data sharing. In particular, some data shall be sent securely to PSU Bike/Ped PORTAL over the regional ITS Network.

2.3. Develop a memorandum with recommendations for the following long-term server hardware, data storage, and data sharing considerations.

2.3.1. Recommendations for a transition plan from on-prem server(s) to a cloud-hosted environment.

2.3.1.1. Plan shall include information about required hardware, software, data storage management solutions, data sharing, security standards, scalability, and estimated costs.

2.3.1.2. A cloud-based system shall include an intermediary physical server at PBOT. Server hardware must meet federal requirements including Build America Buy America (BABA). Recommendations shall include:

2.3.1.2.1. Minimum required processors (CPU, GPU), memory, storage (hard disk space), and network adapters

2.3.1.2.2. Number of Hyper-V virtual machines (if any)

2.3.1.2.3. Server model(s) that are compatible with existing

PBOT equipment

2.3.2. Recommendations for a transition plan from an internal PBOT Open Source

ATSPM website or dashboard to a public website or dashboard. Plan shall include considerations for both an on-prem environment and cloud-hosted environment.

3. OPEN SOURCE ATSPM SOFTWARE INSTALLATION

3.1. Coordinate with PBOT to gain remote access to the on-prem server(s) and iDRAC(s).

3.2. Prepare server(s) for Open Source ATSPM software installation.

3.2.1. Provide a whitelist of destinations and ports for required websites.

3.2.1.1. Whitelist shall limit wildcard requests.

3.2.1.2. PBOT shall coordinate review of whitelist with BTS Information

Security (InfoSec) team.

3.2.2. Coordinate with PBOT and BTS to determine configuration of automated web certificates.

RFP # 2384785615 14 of 25 RFP Information Packet

3.2.3. Provide recommendations for the following items. Install and configure them once selected and approved by PBOT.

3.2.3.1. If required, virtual disks

3.2.3.2. If required, Hyper-V virtual machines

3.2.3.3. SQL database software

3.2.3.4. Software libraries

3.3. Install Open Source ATSPM version 5.2.0, or newer if available (from repository at https://github.com/OpenSourceTransportation/Atspm). Provide all labor, supervision, and materials to install the latest open source version available. The ATSPM system shall collect data and report against the following metrics:

3.3.1. Performance measures

3.3.1.1. Approach delay

3.3.1.2. Approach speed

3.3.1.3. Approach volume

3.3.1.4. Arrivals on red

3.3.1.5. Green time utilization

3.3.1.6. Left turn gap analysis

3.3.1.7. Pedestrian delay

3.3.1.8. Preemption details

3.3.1.9. Purdue coordination diagram

3.3.1.10. Purdue phase termination

3.3.1.11. Purdue split failure

3.3.1.12. Split monitor

3.3.1.13. Timing and actuation

3.3.1.14. Turning movement counts

3.3.1.15. Wait time

3.3.1.16. Yellow and red actuations

3.3.2. Time-space diagrams

3.3.2.1. Time-space diagram (historic)

3.3.2.2. Time-space diagram (50th percentile)

3.3.3. Link pivot

3.3.4. Reports

3.3.4.1. Pedestrian activity

3.3.4.2. Transit signal priority

3.3.5. Aggregate charts

3.4. Configure data storage management solutions, such as partitioning data, for long term data storage.

3.5. Configure data sharing to send some data to PSU Bike/Ped PORTAL.

https://github.com/OpenSourceTransportation/Atspm

RFP # 2384785615 15 of 25 RFP Information Packet

3.6. Add accounts for PBOT administrators.

3.7. Provide credentials for all software and databases to PBOT Project Manager.

3.8. Provide a schematic of the final system architecture including data transfer, server integration, data storage, and end users.

4. CUSTOM SOFTWARE DEVELOPMENT

4.1. Arrange and attend a minimum of ten (10) software development meetings with the

PBOT steering committee to prioritize and review new metrics, dashboards, maps, and tables.

4.2. All new software components or improvements shall remain and abide by the existing Open Source ATSPM V5 architecture.

4.3. Provide all labor, supervision, and materials to configure an ATSPM dashboard.

Features of the dashboard shall potentially include:

4.3.1. Summary of metrics

4.3.2. Overall system health (e.g., using metrics that report equipment and operational failures) for a variable time period such as day, week, month, year

4.3.3. Identification of worst signal/corridor performers with go-to-map features

4.3.4. Identification of normal operations versus abnormal operations (e.g., comparing current metrics to thresholds or historical trends)

4.4. Configure database to collect and store data from sources including LiDAR detection sensors, video detection sensors, thermal detection sensors, TriMet API transit data, RITIS/INRIX probe data, safety camera speed and red-light-running data.

4.5. Provide all labor, supervision, and materials to code a minimum of ten (10) custom metrics. Estimate shall include a cost per custom metric. Custom performance measures potentially include:

4.5.1. TSP requests and service along transit routes and bus delay at signalized intersections

4.5.2. Pedestrian actuations and intervals, when in the cycle pedestrians arrived, and pedestrian delay

4.5.3. Bicycle actuations, if the bicyclist arrived on green or red, if the bicyclist experienced a split failure, and bicyclist delay

4.5.4. Delay anomalies by type of user

4.5.5. Speed distributions

4.5.6. Red-light-running occurrences

4.5.7. Speeding opportunities

4.5.8. Near-miss occurrences*

4.5.9. Conflicting crossings on walk*

4.5.10. Pedestrian non-compliance*

4.5.11. Belated pedestrians*

4.5.12. Bicyclist non-compliance*

RFP # 2384785615 16 of 25 RFP Information Packet

4.5.13. Frequency of red flash events

4.5.14. Communication failure

4.5.15. Stuck preemption

4.5.16. Skipped phase(s)

4.5.17. Stuck all-red

4.5.18. Failed detection (pedestrian)

4.5.19. Failed detection (vehicle or bicycle)

4.5.20. Failed detection (light rail transit, LRT, or streetcar)

4.5.21. TSP not operating

4.5.22. Phases gapping out or maxing out/forcing off more than usual

4.5.23. Transitioning more than usual

* Custom performance measure that could be informed by new detection, but detection testing results will dictate whether performance measures will be possible as part of this project.

4.6. For each custom metric, develop a memorandum to be reviewed by the PBOT steering committee that summarizes the proposed concept of operation, proof of concept, approach to integrating signal data into the Open Source ATSPM software, and approach to analyzing accuracy. Once the custom metric has been programmed, provide an updated memorandum with final analysis of accuracy.

4.7. For each custom metric that has been tested and approved, develop a new chapter to supplement the Utah Department of Transportation (UDOT) “ATSPM Methods and Assumptions Manual”. Chapters shall include an overview of the metric, required data and sources (including event codes), overview of the methodology, computational steps, and an example.

5. SYSTEM TESTING AND ACCEPTANCE

5.1. Arrange and attend a minimum of two (2) meetings with the PBOT steering committee to discuss testing, verification, and acceptance.

5.2. Provide all materials and equipment for testing. If PBOT is required to provide any hardware, network access, or other necessary equipment, staff shall be notified a minimum of 30 days in advance of testing.

5.3. Develop and submit acceptance test procedure for review. Test procedure must be submitted at least 30 days before testing is scheduled. Acceptance testing shall not begin until the procedures have been approved by PBOT.

5.3.1. Test procedures shall describe the means, methods, tools, and pass/fail criteria to verify that the system is working as designed. The final testing shall demonstrate:

5.3.1.1. All system requirements have been met.

5.3.1.2. User interface is configured properly for all use cases.

5.3.1.3. System is storing and retrieving data per requirements in Table 1.

5.3.1.4. System is free of errors.

https://drive.google.com/file/d/12k5LrOyXuc7Ta64Bvi80QlERuNdBI3bC/view).

https://drive.google.com/file/d/12k5LrOyXuc7Ta64Bvi80QlERuNdBI3bC/view).

RFP # 2384785615 17 of 25 RFP Information Packet

5.3.1.5. Integration with PBOT traffic signal controllers and other equipment is free of errors and not impacting normal operations of the traffic signal equipment.

5.3.1.6. Reporting functionality is working.

5.3.1.7. System measures have been demonstrated.

5.3.1.8. System can be updated remotely free from errors.

5.3.2. Test procedures shall include the following environments:

5.3.2.1. Test environment – all software must pass testing in an offline environment prior to release

5.3.2.2. Production testing – testing shall demonstrate that the documented software requirements are being fulfilled and that all features are operating as agreed

5.3.2.3. User testing – establish a subset of stakeholders to perform operational testing of the deployed software

5.3.3. Test procedures shall be clearly stated and independently testable.

5.3.4. Test procedures shall map to at least one of the system requirements (listed in Table 1), and all requirements must have a test procedure associated with it.

5.3.5. Test procedures shall include tests for the Open Source ATSPM software, any hardware/equipment associated with the ATSPM system, communications, detection inputs, networking equipment, and traffic signal controller equipment necessary for the operation of the ATSPM system to demonstrate conformance to the system requirements.

5.3.6. Test procedures shall use ten (10) pilot locations determined by PBOT.

Configure controller and detection setup in the Open Source ATSPM software to be reviewed by PBOT.

5.4. Conduct acceptance testing after Open Source ATSPM software installation (Task 3). Develop a memorandum summarizing acceptance test results. PBOT must provide written acceptance before proceeding with acceptance testing for custom metrics.

5.5. Conduct acceptance testing after installation of custom metrics (Task 4). Develop a memorandum summarizing acceptance test results. PBOT must provide written acceptance prior to the start of the warranty period.

5.6. In the event of errors, PBOT may choose to temporarily end further testing until the errors have been resolved. Testing shall not proceed to the next stage until PBOT has provided written acceptance.

5.7. Testing must be conducted to permit observation of the testing if so desired by PBOT staff.

RFP # 2384785615 18 of 25 RFP Information Packet

6. DEPLOYMENT

6.1. Arrange and attend a minimum of one (1) meeting with the PBOT steering committee to discuss deployment.

6.2. After system acceptance, configure 100 signals identified by PBOT.

6.2.1. Add intersection names, IPs, controller type, and latitudes/longitudes.

6.2.2. PBOT shall configure phases and detectors.

6.3. Code for custom metrics and associated documentation shall be contributed back to the Open Source ATSPM repository on Github.

7. SYSTEM TRAINING

7.1. Provide two (2) virtual training sessions for PBOT staff. The training shall be a combination of classroom instruction and hands-on interaction with the Open Source ATSPM software.

7.2. Training shall include all aspects of operating, maintaining, and administering the Open Source ATPSM software. At a minimum, training shall include how to:

7.2.1. Access the dashboard environment

7.2.2. View, input, and manage data sources (ATCs, detectors, etc.)

7.2.3. Access ATSPM data and performance reports

7.2.4. Add/remove users from the environment

7.2.5. Configure reports and notifications

7.3. Submit a training plan to PBOT for review and approval 30 days prior to the start of training.

7.3.1. Training plan shall include an agenda with timing for the training.

7.3.2. Training materials shall include all reference materials, procedures, and manuals that shall be used.

8. SYSTEM LICENSE, WARRANTY, AND SUPPORT

8.1. LICENSES – Provide all licenses required for the operation and maintenance of the

Open Source ATSPM system, including, but not limited to, third-party software applications, databases, network components, and server(s) (if applicable) for the unlimited use by PBOT. The terms and conditions of any software license shall be incorporated into the final contract. Prior to finalizing the contract, PBOT reserves the right to negotiate terms of the software license.

8.2. WARRANTY – Provide a warranty for two (2) years for all software. Warranty shall begin after PBOT provides written acceptance of all acceptance testing. The terms of the warranty shall be incorporated into the final contract and shall include all software bug fixes, patches, software updates, and additional features for the life of the warranty. Coordinate in advance of updating the software, including scheduling time for any updates that shall cause the software to be inaccessible.

8.3. TECHNICAL SUPPORT – Provide technical support for the life of the warranty.

Provide in the contract the support terms, including response times, communication methods, and hours of availability.

RFP # 2384785615 19 of 25 RFP Information Packet

8.3.1. The vendor shall respond to outages, failures, and software not functioning as expected within 24 hours and apply fixes within three (3) business days.

8.3.2. Technical support includes, but is not limited to, the following:

8.3.2.1. Troubleshooting of the system

8.3.2.2. Routine questions

8.3.2.3. Configuration questions or changes

8.3.2.4. Customized reporting

8.4. POST-WARRANTY MAINTENANCE AGREEMENT – Include an annual

maintenance agreement and associated cost to PBOT as part of the proposal that may be purchased before the warranty period expires. Maintenance agreement shall be included as a line item for the cost proposal. Maintenance agreement shall explain all items covered as part of the maintenance agreement.

Table 1 summarizes the System Requirements developed as part of FHWA Systems Engineering documentation. New language added as part of this scope of work development is in BOLD.

Table 1. System Requirements

Req.

# Requirement Re qu ire d

D es ira bl e

1 DATA COLLECTION

1.1 The system shall retrieve high-resolution data from Advanced Transportation Controllers (ATCs) operating Q-Free MAXTIME (or equivalent) firmware, including those documented in the Indiana Hi Resolution Data Logger Enumerations and any proprietary vendor enumerations.

X

1.2 The system shall be capable of collecting data from a minimum of 2,000 Advanced Transportation Controllers (ATCs) operating Q-Free MAXTIME (or equivalent) firmware. X

1.3 The system shall retrieve speed data from Wavetronix SmartSensor Advance radar detection units. X

1.4 The system shall retrieve data from LiDAR detection units, video detection units, or thermal detection units.

X

1.5 The system shall be capable of collecting data from a minimum of 250 roadside traffic signal detection sensors (e.g., radar and LiDAR). X

1.6 The system shall retrieve transit data from the TriMet API. X

1.7 The system shall retrieve probe data from the Regional Integrated Transportation Information

System (RITIS). X

1.8 The system shall retrieve speed and red-light-running data from the safety cameras. X

1.9 The system shall be capable of collecting data from additional Advanced Transportation

Controllers (ATCs), roadside traffic signal detection sensors, and external data sources in the future.

X

1.10 The system shall initiate data collection from a central location behind the PBOT firewall. No communication shall be initiated by field devices. X

1.11 The system shall support connections via Ethernet over a variety of media including fiber, copper, wireless, and cellular. X

1.12 The system shall work with the existing communications architecture. X

1.13 The system shall retrieve data using secure encrypted protocols. X

RFP # 2384785615 20 of 25 RFP Information Packet

Req.

# Requirement Re qu ire d

D es ira bl e

1.14 The system shall retrieve data from the Advanced Transportation Controllers (ATCs), roadside traffic signal detection sensors, and external data sources (including transit data from the TriMet API, probe data from RITIS, and speed and red-light-running data from the safety cameras) every 15 minutes automatically without requiring an operator to be logged into the system.

X

1.15 If there is an interruption in communication, the system shall retrieve all available data stored on the Advanced Transportation Controllers (ATCs), roadside traffic signal detection sensors, and external data sources (including transit data from the TriMet API, probe data from RITIS, and speed and red-light-running data from the safety cameras) to backfill missing data.

X

2 DATA STORAGE

2.1 The software and data shall be stored on a server, either physical or in the cloud. X

2.2 The server shall be a separate server independent of any other systems, including the central traffic signal system. X

2.3 The system shall have enough storage for 13 months of raw data from a minimum of 2,000 Advanced Transportation Controllers (ATCs) and 200 radar, video, or thermal detection sensors and 13 months of aggregated data from a minimum of 50 LiDAR detection sensors and external data sources (including transit data from the TriMet API, probe data from RITIS, and speed and red-light-running data from the safety cameras).

X

2.4 The system shall archive data automatically after a user-specified period. X

2.5 Any physical server shall be compatible with existing PBOT equipment. X

2.6 Any cloud server shall be approved by the Bureau of Technology Services (BTS) Information

Security (InfoSec) team. X

2.7 A cloud-based system shall include an intermediary physical server at PBOT. X

2.8 The system shall initiate communication with the cloud from the intermediary physical server behind the BTS firewall. No communication shall be initiated by the cloud. X

2.9 The system shall use secure encrypted protocols for communication with the cloud. X

2.10 The system shall store data in a SQL database. X

2.11 The system database shall be independent of any other database, including the central traffic signal system database. X

2.12 Data from different sources shall be compiled into one database. X

2.13 The system shall be capable of packaging data to send to external parties, such as PORTAL. X

2.14 The system database shall be transferable to a shared regional system in the future. X

3 SOFTWARE

3.1 The software shall be fully operational within a Windows operating system. X

3.2 The software shall utilize open-source code so that custom methodologies can be shared. X

3.3 The vendor shall provide routine updates to the software and software environment for a minimum of two (2) years following system acceptance. X

3.4 The software shall operate 24 hours a day, seven days a week. X

3.5 The vendor shall respond to outages, failures, and software not functioning as expected within

24 hours and apply fixes within three (3) business days. X

3.6 The system shall allow intersections to be included in a group. X

3.7 The software shall be capable of storing multiple detection scenarios for a single intersection. X

3.8 The system shall be capable of configuring the following detector types at a minimum: X

3.8.1 Advance Count X

3.8.2 Advance Speed X

3.8.3 Advance Presence X

3.8.4 Stop Bar Count X

3.8.5 Stop Bar Yellow/Red Actuation X

3.8.6 Stop Bar Presence X

3.8.7 Bicycle X

3.8.8 Pedestrian Push Button X

4 MEASUREMENT PROCESSING

RFP # 2384785615 21 of 25 RFP Information Packet qu ire d

D es ira bl e

4.1 The system shall process the collected and stored data to produce the following standard metrics available in the most recent version of ATSPM Open Source Code (currently version 5.2.0):

X

4.1.1 Purdue Phase Termination X

4.1.2 Split Monitor X

4.1.3 Pedestrian Delay X

4.1.4 Preemption Details X

4.1.5 Timing and Actuation X

4.1.6 Purdue Split Failure X

4.1.7 Yellow and Red Actuations X

4.1.8 Turning Movement Counts X

4.1.9 Approach Volume X

4.1.10 Approach Delay X

4.1.11 Arrivals on Red X

4.1.12 Purdue Coordination Diagram X

4.1.13 Approach Speed X

4.1.14 Left Turn Gap Analysis X

4.1.15 Purdue Link Pivot X

4.1.16 Green Time Utilization X

4.1.17 Wait Time (for Vehicles) X

4.1.18 Time-Space Diagrams X

4.1.19 Transit Signal Priority X

4.1.20 Pedestrian Activity X

4.1.21 Aggregate Charts X

4.2 Calculations for existing metrics (listed in 4.1) shall follow the methodologies in Automated

Traffic Signal Performance Measure Methods and Assumptions Manual. X

4.3 The system shall process the collected and stored data to produce a minimum of 10 custom operational, safety, and maintenance metrics for transit, pedestrians, and bicyclists: X

4.3.1 TSP requests and service along transit routes and bus delay at signalized intersections X

4.3.2 Pedestrian actuations and intervals, when in the cycle pedestrians arrived, and pedestrian delay X

4.3.3 Bicycle actuations, if the bicyclist arrived on green or red, if the bicyclist experienced a split failure, and bicyclist delay X

4.3.4 Delay anomalies by type of user X

4.3.5 Speed distributions X

4.3.6 Red-light-running occurrences X

4.3.7 Speeding opportunities X

4.3.8 Near-miss occurrences X

4.3.9 Conflicting crossings on walk X

4.3.10 Pedestrian non-compliance X

4.3.11 Belated pedestrians X

4.3.12 Bicyclist non-compliance X

4.3.13 Frequency of red flash events X

4.3.14 Communication failure X

4.3.15 Stuck preemption X

4.3.16 Skipped phase(s) X

4.3.17 Stuck all-red X

4.3.18 Failed detection (pedestrian) X

4.3.19 Failed detection (vehicle or bicycle) X

4.3.20 Failed detection (LRT or streetcar) X

4.3.21 TSP not operating X

4.3.22 Phases gapping out or maxing out/forcing off more than usual X

RFP # 2384785615 22 of 25 RFP Information Packet qu ire d

D es ira bl e

4.3.23 Transitioning more than usual X

4.4 Metrics shall be refreshed as frequently as new data is uploaded from the Advanced

Transportation Controllers (ATCs), roadside traffic signal detection sensors, and external data sources (including transit data from the TriMet API, probe data from RITIS, and speed and red-light-running data from the safety cameras).

X

5 MEASUREMENT REPORTS

5.1 The system shall include a dashboard that displays aggregated metrics. X

5.2 The system shall allow users to customize the dashboard with user-selected metrics. X

5.3 The dashboard shall be planned such that it can be shared publicly in the future. X

5.4 The system shall include a map that displays aggregated metrics. X

5.5 The system shall allow metrics to be overlaid in reports, charts, and maps. X

5.6 Reports, charts, and maps shall be dynamic so that a user can zoom, pan, and select layers to turn on/off. X

5.7 Reports, charts, and maps shall be customizable by timeframe (e.g., dates and times). X

5.8 Reports, charts, and maps shall be customizable by data interval (e.g., bin size). X

5.9 Raw data shall be downloadable (e.g., as a CSV file). X

6 USER INTERFACE

6.1 The system shall have a web-based user interface. X

6.2 The system shall allow access at City facilities. X

6.3 The system shall allow remote access using a secure Virtual Private Network (VPN). X

6.4 The system shall allow operators from different agencies access, subject to assigned privilege levels, using either the ITS Network if the server is on-prem or through a secure connection to the cloud.

X

6.5 The system shall allow 25 users to log on to the system simultaneously. X

6.6 The system shall allow multiple operators to query reports for the same intersection simultaneously. X

6.7 The system shall provide the ability to control and limit user access via user privileges (i.e., allowing for different levels of user access to system features and functions). X

6.8 The system shall provide user privileges definable by functional level: X

6.8.1 Administrator with full rights including the ability to configure user accounts, set privilege levels, and manage passwords X

6.8.2 Operator with read/write access X

6.8.3 Guest with read-only access X

6.9 The system shall require a username and password to login. X

6.10 Passwords shall be encrypted. X

6.11 Passwords shall be resettable by the user. X

6.12 The system shall comply with the security policy as described in BTS-2.01 - Information Security

Administrative Rule. X

RFP # 2384785615 23 of 25 RFP Information Packet

Section 4: Exhibits

1. Exhibit A Submission Instructions

2. Exhibit B System Requirements

3. Exhibit C Concept of Operations

RFP # 2384785615 24 of 25 RFP Information Packet

Section 5: Sample Contract Please see Attachment A Sample Contract.

RFP # 2384785615 25 of 25 RFP Information Packet

Section 6: RFP Terms and Conditions Link to RFP Terms and Conditions: https://www.portland.gov/business-opportunities/documents/terms-and-conditions-rfp-sample-v2/download https://www.portland.gov/business-opportunities/documents/terms-and-conditions-rfp-sample-v2/download https://www.portland.gov/business-opportunities/documents/terms-and-conditions-rfp-sample-v2/download