Exhibit C Concept of Operations.pdf

CONCEPT OF OPERATIONS

FOR THE

Portland Traffic Signal Performance Measures Development and

Evaluation

AND

Portland Bureau of Transportation

Federal Project No: 5900(333)

Date Approved: February 4, 2026

Prepared by: Portland Bureau of Transportation

Alison Tanaka

ODOT Project No: K22531

PBOT Project No: T01189

Version: 2.1

Date Issued: February 4, 2026

Portland Traffic Signal Performance Measures Development and Evaluation Concept of Operations

Portland Bureau of Transportation i Signals, Street Lighting, and ITS

TABLE OF CONTENTS

1. Purpose and Scope

2. Referenced Documents

3. Background

3.1. Existing System Architecture

3.2. Limitations of the Existing System

4. Concept for the Proposed System

4.1. Vision

4.2. Goals

4.3. Objectives

4.4. Alternative Strategies Considered

4.4.1. New UDOT Open-Source Code: Version 5

4.4.2. Alternative Open-Source Code: GDOT SigOps

4.4.3. Alternative Open-Source Code: ODOT PowerBI Dashboard

4.4.4. Existing Data Archive System: BikePed PORTAL

4.4.5. Existing Central Traffic Signal System: Q-Free Kinetic Mobility

4.4.6. Subscription Software

5. Operational Needs

5.1. Hardware

5.2. Software

5.3. Metrics

5.4. Field Access

5.5. User Access

5.6. Security

6. Operational Scenarios

6.1. Normal Conditions

6.2. Stress Conditions

6.3. Failure Events

6.4. Maintenance

7. Summary of Impacts

7.1. Future System Architecture

7.2. Stakeholder Impacts

7.3. Constraints on System Development

7.4. Assessment Metrics

Portland Bureau of Transportation 1 Signals, Street Lighting, and ITS

1. PURPOSE AND SCOPE

Automated Traffic Signal Performance Measures (ATSPMs) support a data-driven approach to traffic signal management. The Portland Bureau of Transportation (PBOT) has invested in ATSPMs, but most of the available metrics 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 Signals, Street Lighting, and Intelligent Transportation

Systems (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 multimodal performance measures.

This document outlines user needs for an ATSPM system that were identified during stakeholder discussions. It documents a shared vision for the ATSPM system. The intended audience of this document includes the users of the new ATSPM system:

• PBOT SSL Leadership (engineering and maintenance managers and supervisors), Engineering (district, ITS, and maintenance engineers), and Maintenance (district and ITS electricians) that will use the ATSPM system regularly.

• Other PBOT Groups including Planning, Safety, Design, and Operations that will share access to the ATSPM system.

• Other Regional and Academic Partners including the Cities of Gresham and Beaverton, Washington and Clackamas Counties, Oregon Department of Transportation (ODOT), TriMet, Portland State University (PSU), and Metro that will share the methodologies for multimodal performance measures.

The needs and corresponding requirements identified through this Systems Engineering process will be used to procure a new ATSPM system. A Request for Proposal (RFP) will be issued for software installation, hardware selection and configuration, and performance measure customization support. The selected system will be the one that provides the best value, subject to financial and schedule constraints. A detailed procurement plan will be prepared after the system requirements have been determined.

2. REFERENCED DOCUMENTS

The following documents have been used in the preparation of this Concept of Operations and stakeholder discussions.

1. Day, C. M., D. M. Bullock, H. Li, S. Lavrenz, W. B. Smith, and J. R. Sturdevant. (2015).

Integrating Traffic Signal Performance Measures into Agency Business Processes. Purdue

University. https://doi.org/10.5703/1288284316063

2. Day, C. M., D. M. Bullock, H. Li, S. M. Remias, A. M. Hainen, R. S. Freije, A. L. Stevens, J. R.

Sturdevant, and T. M. Brennan. (2014). Performance Measures for Traffic Signal Systems:

An Outcome-Oriented Approach. Purdue University.

https://doi.org/10.5703/1288284315333

3. Federal Highway Administration. (2023, April 14). EDC-4: Automated Traffic Signal

Performance Measures (ATSPMs).

https://www.fhwa.dot.gov/innovation/everydaycounts/edc_4/atspm.cfm

4. Federal Highway Administration (n.d.). Systems Engineering for ITS.

https://ops.fhwa.dot.gov/seits/

Portland Bureau of Transportation 2 Signals, Street Lighting, and ITS

5. Georgia Department of Transportation. (2022). Automated Traffic Signal Performance

Measures Reporting Details.

https://udottraffic.utah.gov/ATSPM/Images/ATSPM_Reporting_Details_4.3.pdf

6. Georgia Department of Transportation. (n.d.). SigOps Metrics.

https://sigopsmetrics.dot.ga.gov/

7. Li, H., A. M. Hainen, J. R. Sturdevant, T. Atkison, S. Talukder, J. K. Mathew, D. M. Bullock, D.

Nelson, D. M. Maas, Jr., J. Fink, and T. Stiles. (2019). Indiana Traffic Signal Hi Resolution

Data Logger Enumerations. Indiana Department of Transportation and Purdue

University. https://doi.org/10.5703/1288284316998

8. National Academies of Sciences, Engineering, and Medicine. (2020). Performance-Based

Management of Traffic Signals. The National Academies Press.

https://doi.org/10.17226/25875

9. Portland State University. (n.d.). BikePed Portal. https://bikeped.trec.pdx.edu/

10. Strasser, S. (n.d.). ATSPM Aggregation Code. Oregon Department of Transportation.

https://github.com/ShawnStrasser/atspm

11. Sturdevant, J. R., T. Overman, E. Raamot, R. Deer, D. Miller, D. M. Bullock, C. M. Day, T. M.

Brennan, H. Li, A. Hainen, and S. M. Remias. (2012). Indiana Traffic Signal Hi Resolution

Data Logger Enumerations. Indiana Department of Transportation and Purdue University.

https://doi.org/10.4231/K4RN35SH

12. Utah Department of Transportation. (2022). Automated Traffic Signal Performance Measure

Methods and Assumptions Manual.

https://udottraffic.utah.gov/ATSPM/Images/ATSPM_Methods_and_Assumptions_4.3.pdf

13. Utah Department of Transportation. (2020). Automated Traffic Signal Performance

Measures User Case Examples.

https://udottraffic.utah.gov/ATSPM/Images/ATSPM_User%20Case%20Examples_Manual_

20200128.pdf

14. Utah Department of Transportation. (n.d.). ATSPM Open-Source Code.

https://github.com/OpenSourceTransportation/Atspm

15. Utah Department of Transportation. (n.d.). Automated Traffic Signal Performance

Measures. http://udottraffic.utah.gov/atspm/

3. BACKGROUND

This section provides information about the existing ATSPM system used by PBOT, its capabilities, and its limitations.

3.1. EXISTING SYSTEM ARCHITECTURE

PBOT has version 4.2.3 of the Utah Department of Transportation (UDOT) ATSPM Open-Source

Code installed (see Figure 1). The ATSPM system is closely tied to the existing central traffic signal system (TransCore’s TransSuite).

• The Open-Source Code is installed on a virtual machine (VM) on the same physical server where TransSuite is installed.

• The Open-Source Code stores data in a Microsoft SQLServer database.

• PBOT SSL staff can access the web interface over VPN or at their City workstations.

• High-resolution data is queried from connected Advanced Transportation Controllers

(ATCs) every 15 minutes.

Portland Bureau of Transportation 3 Signals, Street Lighting, and ITS

Figure 1. PBOT ATSPM Website

The existing system architecture is illustrated in Figure 2 between the traffic signal controllers in the field, the server where the existing ATSPM system is housed, and the PBOT workstations where

SSL engineers can view the web interface. There are 1,138 existing traffic signals owned and maintained by PBOT. Of those, 657 are connected ATCs (see Figure 3). While the existing ATSPM system could be collecting data from all the connected ATCs, the existing ATSPM system has 454 of them configured.

Figure 2. Existing Data Flow

The typical workflow for the existing ATSPM system begins with a public service request or notification from field staff about an issue. An engineer will use the ATSPM system to review intersection-level reports or download raw data. This workflow requires the engineer to have a general timeframe and intersection that they want to review. Using the information from the ATSPM system, the engineer can make a change in the field or remotely (i.e., through the central traffic signal system). After the change has been implemented, the engineer can monitor the intersection using the ATSPM reports.

Advanced

Transportation

Controller (ATC)

Firewall

ATSPM

SQL Database

PBOT

SSL Staff

Firewall

PBOT

Workstations

(Web Interface)

ATSPM

Open-Source

Code

ATSPM Server

Portland Bureau of Transportation 4 Signals, Street Lighting, and ITS

Figure 3. Existing Connected ATCs

3.2. LIMITATIONS OF THE EXISTING SYSTEM

The existing ATSPM system has limitations that have led to the development of this project. Existing limitations include:

Lack of Multimodal Performance Measures: There are currently 15 ATSPM metrics available (see

Table 1). Some of them have information that is specific to pedestrians and bicyclists, but most of them were developed to report information about vehicular traffic. There is a need for metrics that will provide information specific to transit, pedestrians, and bicyclists in addition to vehicles so that staff have a full picture of signalized intersections.

Portland Bureau of Transportation 5 Signals, Street Lighting, and ITS

Lack of Safety and Maintenance Performance Measures: Some of the existing ATSPM metrics include information that is specific to safety (see Table 1), but most of them focus on operations.

There is a need for metrics that will provide information specific to safety and maintenance in order to prioritize work in those areas.

Table 1. Existing ATSPM Metrics

Metric Type V e h ic le s

T ra n it

P e d e s tr ia n

B ic y c li ts

O p e ra ti o

S a fe ty

M in te n a n c

Purdue Phase Termination X X X

Split Monitor X X X

Pedestrian Delay X X

Preemption Details X

Timing and Actuation X X X

Purdue Split Failure X X

Yellow and Red Actuations X X

Turning Movement Counts X X X

Approach Volume X X

Approach Delay X X

Arrivals on Red X X

Purdue Coordination Diagram X X

Approach Speed X X

Left Turn Gap Analysis X X

Purdue Link Pivot X

Lack of High-Level Monitoring: The existing ATSPM reports require the user to manually select a specific intersection and date. It is a useful tool when responding to field observations by a member of the public or staff, but it can be difficult to use the website for automated high-level monitoring such as identifying hot spots or evaluating whether safety, operations, and maintenance are improving.

Dependency on Central Traffic Signal System: The current ATSPM system is tied to the existing central traffic signal system, even sharing a server. Any report adjustments or customizations require working with the central traffic signal system vendor. PBOT is in the process of moving to a new central traffic signal system (Q-Free’s Kinetic Mobility), so the existing infrastructure will eventually be retired.

Low Data Quality at Some Signalized Intersections: The existing communications network has some bandwidth constraints. There are occasional gaps in the data, and the current ATSPM system does not attempt to backfill missing data that is available on the controllers or provide information about data quality.

Static Charts: The existing ATSPM charts are static, often requiring the reports to be run again to capture the data of interest.

Portland Bureau of Transportation 6 Signals, Street Lighting, and ITS

Requirement for Microsoft SQL Server: The current version of Open-Source Code relies on

Microsoft SQL Server, which has expensive licensing.

Data Storage: The current version of Open-Source Code requires a significant amount of server storage, which is difficult for PBOT SSL to maintain.

User Management: It is challenging to manage users with the current version of Open-Source

Code. There is no way to easily reset user passwords if they are forgotten or delete users from the web interface.

4. CONCEPT FOR THE PROPOSED SYSTEM

The limitations of the existing ATSPM system have led PBOT to define a concept for a new ATSPM system that will replace it.

4.1. VISION

The vision for the ATSPM system is a tool that overlays performance measures for transit, pedestrians, bicyclists, and vehicles to help PBOT staff identify operational, safety, and maintenance improvements at signalized intersections in a proactive manner.

4.2. GOALS

Goals for the project include:

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

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

• Aggregate new and existing metrics that will help PBOT SSL Leadership, Engineering, and

Maintenance staff make decisions about signalized intersections.

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

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

4.3. OBJECTIVES

Objectives for the project include:

• DEFINE actionable performance measures for transit, pedestrians, and bicyclists at signalized intersections.

• IDENTIFY required data, either collected by the traffic signal controllers, roadside traffic signal detection sensors, or other external data sources (e.g., APIs).

• ACQUIRE required hardware, software (or open-source code), and data sources.

• CONFIGURE performance measures, dashboards, and reports.

• DOCUMENT methodologies.

Portland Bureau of Transportation 7 Signals, Street Lighting, and ITS

4.4. ALTERNATIVE STRATEGIES CONSIDERED

PBOT explored several existing ATSPM systems to develop a list of needs for the new ATSPM system. Key benefits identified during the evaluation and assessment are summarized in this section.

• New UDOT Open-Source Code: Version 5

• Alternative Open-Source Code Options: GDOT SigOps and ODOT PowerBI Dashboard

• Existing Data Archive System: BikePed PORTAL

• Existing Central Traffic Signal System: Q-Free Kinetic Mobility

• Subscription Software

4.4.1. New UDOT Open-Source Code: Version 5

UDOT ATSPM Open-Source Code (https://udottraffic.utah.gov/atspm/) is now available in Version

5.1.0. There are significant changes from version 4.2.3 (that PBOT currently uses) starting with version 5.0. Enhancements include:

• Configuration enhancements so that multiple devices can be configured per location.

• Data import enhancements so that the system works with a broader range of protocols.

• Database flexibility so that the system works with different types of SQL databases.

• Data compression resulting in storage space reduction.

• Cloud compatibility.

• API layer that streamlines interactions with data.

• Modern front-end user interface adds a searchable toolbar for locations and the ability to see which dates have data available.

• Dynamic, interactive charts that allow zooming, panning, and layer selection.

• New performance measures include Green Time Utilization and Time-Space Diagrams

(note that Wait Time will also be considered a new metric for PBOT, see Table 2).

• Improved data aggregation and event logging.

• Watchdog enhancements including email functionalities, additional data checks, and a new report.

• Security controls enhancements including single sign-on and finer control over access and permissions.

• Built with clean architecture so that code is modular, testable, and maintainable.

Portland Bureau of Transportation 8 Signals, Street Lighting, and ITS

Enhancements planned for future versions include a Transit Signal Priority Report, Pedestrian

Active Transport Dashboard, and Speed Management.

Table 2. UDOT ATSPM Open-Source Code Version 5 Metrics

Metric Type V e h ic n d e s tr ia y c li e ra ti o in te n a n

All Version 4.2.3 Metrics Reference Table 1

Green Time Utilization X X

Wait Time X X

Time-Space Diagrams X X

Transit Signal Priority X X

4.4.2. Alternative Open-Source Code: GDOT SigOps

GDOT SigOps (https://sigopsmetrics.dot.ga.gov/) reports many of the same metrics as the UDOT

Open-Source Code (see Table 3), but it displays information in a dashboard format. This system includes “hot spot” maps, tables that summarize averages, and summary trends. The data aggregation can be in quarterly, monthly, weekly, daily, hourly, or 15-minute bins for the prior year, quarter, month, week, or day. Each metric is reported for the selected period as well as a percent change to the prior period. Defining features of this system include:

• Watchdog reports that highlight signalized intersections with consistent alerts (for no camera image, bad vehicle detection, bad ped push buttons, pedestrian activations, force offs, max outs, count, and missing records).

• Health Metrics that provide a consistent way to compare signalized intersections. Each signal is given a health score in three main categories (maintenance, operations, and safety) based on weighted metrics.

Portland Bureau of Transportation 9 Signals, Street Lighting, and ITS

Table 3. GDOT SigOps Metrics

Metric Type V e h ic n d e s tr ia y c li e ra ti o in te n a n

Throughput (vph) X X

Daily Traffic Volumes (vpd) X X

AM/PM Peak Volumes (vph) X X

Arrivals on Green (%) X X

Progression Ratio X X

Queue Spillback Rate (%) X X

Peak/Off-Peak Split Failures (%) X X

Travel Time Index X X

Planning Time Index X X

Detector Uptime (%) X X

Pedestrian Activations X X

Pedestrian Pushbutton Uptime (%) X X

CCTV Uptime (%) X

Communication Uptime (%) X

Watchdog (Days with Alerts) X X X X

Health Metrics (Maintenance, Operations, Safety

Percentages)

X X X X X

4.4.3. Alternative Open-Source Code: ODOT PowerBI Dashboard

Portland Bureau of Transportation 10 Signals, Street Lighting, and ITS

The ODOT PowerBI Dashboard

(https://app.powerbigov.us/view?r=eyJrIjoiNzhmNTUzNDItMzkzNi00YzZhLTkyYWQtYzM1OGExMDk

3Zjk1IiwidCI6IjI4YjBkMDEzLTQ2YmMtNGE2NC04ZDg2LTFjOGEzMWNmNTkwZCJ9) is another dashboard format that aggregates many of the same metrics available in the UDOT Open-Source

Code (see Table 4). This system includes “hot spot” maps and summary trends. Data can be averaged in day, hour, or 15-minute bins or totaled in day, four-hour, hour, or 15-minute bins by phase, signal, or corridor. PowerBI would present some visualization limitations for new metrics.

Table 4. ODOT PowerBI Dashboard Metrics

Metric Type V e h ic n d e s tr ia y c li e ra ti o in te n a n

Delay X X

Pedestrian Actuations X X

Pedestrian Services X X

Pedestrian Volumes X X

Phase Termination X X

Platoon Ratio X X

Services X X

Splits X X

Split Failure X X

Stop Bar Occupancy X X

Volumes X X

Yellow & Red Actuations X X

4.4.4. Existing Data Archive System: BikePed PORTAL

BikePed PORTAL (https://bikeped.trec.pdx.edu/) archives bicycle and pedestrian count data from across the United States (see Table 5). Additionally, there is a new tool that takes pedestrian push button actuations and estimates pedestrian volumes using ODOT research conducted by PSU and

Utah State University (USU). PBOT has previously provided vehicle data to PORTAL and was involved in the ODOT study on pedestrian push button actuations.

Portland Bureau of Transportation 11 Signals, Street Lighting, and ITS

Table 5. BikePed PORTAL Metrics

Metric Type V e h ic n d e s tr ia y c li e ra ti o in te n a n

Bicycle Counts X X

Pedestrian Counts X X

Pedestrian Push Button Actuations (Volume Estimates) X X

4.4.5. Existing Central Traffic Signal System: Q-Free Kinetic Mobility

Q-Free Kinetic Mobility (https://www.q-free.com/product/kinetic-signals/) is the central traffic signal system selected for the Portland region. It has ATSPM metrics built into the software. Most of the metrics are similar to the UDOT Open-Source Code (see Table 6). However, the detection configuration is simplified so calculations are not one-to-one with the existing ATSPM system.

Table 6. Q-Free Kinetic Mobility Metrics

Metric Type V e h ic n d e s tr ia y c li e ra ti o in te n a n

Split Monitor X X

Split Data X X

Average Split Data X X

Phase Termination X X X

Purdue Split Failure X X

Purdue Coordination Diagram X X

ATSPM Split Monitor X X

Turning Movement X X

Approach Volume X X

Approach Delay X X

Arrivals on Red X X

Yellow and Red Violations X X

Flow Profile X X

Event Timeline X X X X X

4.4.6. Subscription Software

There are several subscription-based software options that have many of the same performance metrics as the UDOT Open-Source Code. One of the differentiators between these systems and others is the number of automated recommendations and reports that are derived from the

ATSPMs. These often include recommendations derived from the data, overview maps that draw attention to intersection health, aggregated metrics on a corridor level, and executive reports that correlate the data to costs. However, subscription-based software options have ongoing costs.

Portland Bureau of Transportation 12 Signals, Street Lighting, and ITS

5. OPERATIONAL NEEDS

Based on evaluation and assessment of existing ATSPM systems, PBOT developed the following list of needs for a new ATSPM system.

5.1. HARDWARE

• The software and data need to be stored on a server, either physical or in the cloud.

• The server needs to be independent of any other servers, including the central traffic signal system server.

• The server needs to use a Windows operating system.

• Any physical server needs to be compatible with existing PBOT equipment.

• Any cloud server needs to be approved by the Bureau of Technology Services (BTS)

Information Security (InfoSec) team.

• A cloud-based system will require an intermediary physical server at PBOT.

• Connections to field devices and the cloud need to be one-way (i.e., read only) and encrypted.

• The server needs to have enough storage for 13 months of raw data from the ATCs and radar detection sensors and 13 months of aggregated data from LiDAR detection sensors and external data sources (including transit data from the TriMet API, probe data from the

Regional Integrated Transportation Information System (RITIS), and speed and red-light-running data from the safety cameras).

• Data storage needs to be planned such that data can be migrated to a shared regional system in the future.

5.2. SOFTWARE

• The software needs to be compatible with a Windows operating system.

• The software needs to utilize open-source code so that methodologies for customizations can be shared.

• The software needs to operate 24 hours a day, seven days a week.

• The software needs to be repaired promptly if there are outages, failures, or the software is not functioning as expected.

• Data needs to be stored in a SQL database that is independent of any other databases, including the central traffic signal system database.

• Different data sources need to be compiled into one platform. Users should not need to log into multiple interfaces to access different reports, charts, and maps.

• Raw data needs to be downloadable (e.g., as a CSV file).

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

• Reports, charts, and maps need to be customizable by time frame (e.g., dates and times) and data interval (e.g., bin size).

• The software needs to be capable of packaging data to send to external parties, such as

PORTAL.

• The software needs to be capable of archiving data for a configurable amount of time.

• The software and software environment needs to be updated regularly.

Portland Bureau of Transportation 13 Signals, Street Lighting, and ITS

5.3. METRICS

• The new system needs to include existing ATSPM metrics currently available to PBOT staff

(see Table 1).

• The new system needs to be capable of using high-resolution data from the following detectors at a minimum: advance count, advance speed, advance presence, stop bar count, stop bar yellow/red actuation, stop bar presence, bicycle, and pedestrian push buttons.

• Calculations for the existing metrics need to match the methodologies in Automated Traffic

Signal Performance Measure Methods and Assumptions Manual (UDOT 2022).

• The new system needs to include a dashboard and mapping that aggregates data up from the signalized intersection level. It is desirable for the new system to allow users to customize the dashboard with user-selected metrics.

• The new system needs to be customized with PBOT-specific metrics for transit, pedestrians, and bicyclists based on the Operational Scenarios.

• The new system needs to allow metrics to be overlaid.

5.4. FIELD ACCESS

• The software needs to be capable of connecting to 2,000 ATCs running Q-Free MaxTime (or equivalent) firmware and 250 roadside traffic signal detection sensors (e.g., radar and

LiDAR). The software needs to be planned such that it could connect to additional ATCs and roadside traffic signal detection sensors in the future.

• The software needs to be capable of connecting to 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. The software needs to be planned such that it could connect to additional external data sources in the future.

• The software needs to support connections via Ethernet over a variety of media including fiber, copper, wireless, and cellular.

• The software needs to be capable of uploading data from the 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.

• The software needs to be capable of backfilling data available on the 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) if there is an interruption in communications.

• Reports, charts, and maps need to be refreshed as frequently as new data is uploaded from the 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).

• The software needs to be capable of storing multiple detection scenarios for a single intersection.

Portland Bureau of Transportation 14 Signals, Street Lighting, and ITS

5.5. USER ACCESS

• The software needs to have a web-based user interface.

• The software needs to be accessible to PBOT SSL Leadership, Engineering, and

Maintenance staff, as well as other groups within PBOT such as Safety, Planning, Design, and Operations, at their City desks and over VPN.

• The software needs to be accessible to Regional Partners, either over the ITS Network if the server is on-prem (i.e., similar to the existing connection to the central traffic signal system) or through a secure connection to the cloud.

• The dashboard needs to be planned such that it could be shared publicly in the future.

• A minimum of 25 users need to be able to access the system simultaneously.

• Multiple users need to be able to query reports for the same intersection simultaneously.

5.6. SECURITY

• The software needs to have a login that requires a username and password.

• Passwords need to be encrypted.

• Passwords need to be resettable by the user.

• User categories need to include administrator (full rights with the ability to configure user accounts, set privilege levels, and manage passwords), operator (read/write access), and guest (read-only access).

• Privileges need to be assignable by intersection group (e.g., jurisdictions).

• The system needs to comply with BTS InfoSec policies.

Portland Bureau of Transportation 15 Signals, Street Lighting, and ITS

6. OPERATIONAL SCENARIOS

The following operational scenarios were derived during stakeholder meetings (see Table 7). There is a desire for the ATSPM system to be capable of overlaying information about transit, pedestrians, bicyclists, and vehicles for the following normal, stress, failure, and maintenance conditions.

Table 7. Proposed Operational Scenarios

Metric Type V e h ic n d e s tr ia y c li e ra ti o in te n a n

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

X X

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

X X

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

X X

4 Delay anomalies by type of user X X X X X

5 Speed distributions X X

6 Red-light-running occurrences X X

7 Speeding opportunities X X

8 Near-miss occurrences* X X X X X

9 Conflicting crossings on walk* X X X

10 Pedestrian non-compliance* X X

11 Belated pedestrians * X X

12 Bicyclist non-compliance* X X

13 Frequency of red flash events X

14 Communication failure X

15 Stuck preemption X

16 Skipped phase(s) X

17 Stuck all-red

18 Failed detection (pedestrian) X X

19 Failed detection (vehicle or bicycle) X X X

20 Failed detection (LRT or streetcar) X X

21 TSP not operating X X X

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

X X X

23 Transitioning more than usual

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

Portland Bureau of Transportation 16 Signals, Street Lighting, and ITS

6.1. NORMAL CONDITIONS

Scenario 1

Trigger Transit signal priority (TSP) is activated

Sequence of Events System monitors TSP requests and service along transit routes and calculates bus delay at signalized intersections

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☒ Regional

Communication • Chart of TSP requests and service counts (with the selected TSP strategy identified – truncate, extend) over time at a signalized intersection

• Chart of TSP requests compared to phase status (including preemption) at a signalized intersection and along the corridor

(e.g., in a time-space diagram)

• Chart of TSP estimated time to arrival (ETA) versus actual time to arrival

• Chart of bus percentages arriving on green versus red

• Map of TSP requests and service counts (with the selected TSP strategy identified – truncate, extend)

• Map of bus delay at signalized intersections (by TSP route)

• Map of real-time bus locations and bus stop requests (i.e., from

CAD AVL data)

Actions/Decisions • Prioritization of transit funding based on signalized intersections with bus delay

• Inform TSP signal timing settings (e.g., ETA windows, green for transit phase)

Scenario 2

Trigger Pedestrian pushes the button at a signalized intersection

Sequence of Events System counts pedestrian actuations and intervals, identifies when in the cycle pedestrians arrived, and calculates pedestrian delay

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☒ Regional

Communication • Chart of pedestrian actuations and intervals (e.g., advance walk, walk, walk extension) over time at a signalized intersection

• Chart of pedestrian actuations compared to phase status

(including preemption and rest in coord green) at a signalized intersection and along the corridor (e.g., in a time-space diagram)

• Map of pedestrian actuation and interval counts (e.g., advance walk, walk, walk extension)

• Map of pedestrian delay

Actions/Decisions • Prioritization of capital funding based on pedestrian actuations and delay

• Inform pedestrian signal timing settings (e.g., advance walk, walk, walk extension, rest in walk, pedestrian recall)

• Inform other signal timing settings that may impact pedestrian delay (e.g., green for conflicting phases, cycle length)

Portland Bureau of Transportation 17 Signals, Street Lighting, and ITS

Scenario 3

Trigger Bicyclist travels through a signalized intersection

Sequence of Events System counts bicycle actuations, identifies if the bicyclist arrived on green or red, identifies if the bicyclist experienced a split failure, and calculates bicyclist delay

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☒ Regional

Communication • Chart of bicycle actuations over time at a signalized intersection

• Chart of bicycle actuations compared to phase status (including preemption) at a signalized intersection and along the corridor

(e.g., in a time-space diagram)

• Chart of bicyclist percentages arriving on green versus red

• Chart of bicyclist split failures

• Map of bicycle actuation counts

• Map of bicyclist delay

Actions/Decisions • Prioritization of capital funding based on bicycle actuations and delay

• Inform bicycle signal phasing, particularly related to right turns

• Inform bicycle signal timing settings (e.g., green for bicycle phase)

• Inform other signal timing settings that may impact bicyclist delay (e.g., green for conflicting phases, cycle length, offset)

Scenario 4

Trigger Transit, pedestrian, bicyclist, or vehicle is delayed at a signalized intersection

Sequence of Events System compares delay to historical averages and highlights anomalies by type of user

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☒ Regional

Communication • Chart of delay by type of user over time at a signalized intersection

• Chart comparing delay to historical averages by type of user

• Map of delay by type of user

Actions/Decisions • Prioritization of capital funding based on delay

• Inform signal timing settings that may impact delay (e.g., green, walk, cycle length, TSP settings)

Portland Bureau of Transportation 18 Signals, Street Lighting, and ITS

6.2. STRESS CONDITIONS

Scenario 5

Trigger Vehicle speeds through a signalized intersection

Sequence of Events System monitors speed distributions

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☐ Regional

Communication • Chart of binned speeds over time at a signalized intersection and along the corridor

• Map of vehicle percentages traveling over a certain speed

Actions/Decisions • Prioritization of safety funding based on higher speeds

• Inform signal timing settings (e.g., gap settings related to speeding opportunities, rest-in-red)

Scenario 6

Trigger Vehicle runs a red light

Sequence of Events System monitors red-light-running occurrences

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☐ Regional

Communication • Chart of red-light-running occurrences (and vehicles entering on yellow) over time at a signalized intersection

• Map of red-light-running occurrences (and entering on yellow)

Actions/Decisions • Prioritization of safety funding based on vehicles entering on red and yellow

• Inform signal timing settings (e.g., red, gap settings)

Scenario 7

Trigger Vehicle has a speeding opportunity on stale green

Sequence of Events System monitors speeding opportunities (i.e., large gaps between vehicles when there is a green)

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☐ Regional

Communication • Chart of speeding opportunities over time at a signalized intersection

• Map of speeding opportunities

Actions/Decisions • Inform signal timing settings (e.g., green, gap settings)

Portland Bureau of Transportation 19 Signals, Street Lighting, and ITS

PBOT is currently testing several new detection technologies. There are operational scenarios that could be informed by new detection, but the testing results will dictate whether the following metrics would be possible as part of this project.

Scenario 8

Trigger Near miss occurs

Sequence of Events System monitors near-miss occurrences

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☐ Regional

Communication • Chart of near-miss occurrences over time at a signalized intersection

• Map of near-miss occurrences

Actions/Decisions • Prioritization of safety funding based on near misses

• Inform turn phasing (e.g., protected, permitted)

• Inform signal timing settings (e.g., red, gap settings)

Scenario 9

Trigger Vehicle crosses crosswalk during walk

Sequence of Events System monitors conflicting crossings on walk

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☐ Regional

Communication • Chart of conflicting crossings on walk over time at a signalized intersection

• Map of conflicting crossings on walk

Actions/Decisions • Prioritization of safety funding based on conflicting crossings on walk

• Inform right-turn-on-red and turn phasing (e.g., protected, permitted)

Scenario 10

Trigger Pedestrian crosses street during don’t walk or outside the crosswalk

Sequence of Events System monitors pedestrian non-compliance

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☐ Regional

Communication • Chart of pedestrian non-compliance over time at a signalized intersection

• Map of pedestrian non-compliance

Actions/Decisions • Prioritization of safety funding based on pedestrian non-compliance

• Inform pedestrian signal timing settings (e.g., advance walk, walk, walk extension, rest in walk, pedestrian recall)

• Inform other signal timing settings that may impact pedestrian delay (e.g., green for conflicting phases, cycle length)

Portland Bureau of Transportation 20 Signals, Street Lighting, and ITS

Scenario 11

Trigger Pedestrian does not clear the intersection during flashing don’t walk

Sequence of Events System monitors if there is a belated pedestrian and how much additional time they needed to cross

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☐ Regional

Communication • Chart of belated pedestrians over time at a signalized intersection

• Map of belated pedestrians

Actions/Decisions • Inform pedestrian intervals (e.g., walk, flashing don’t walk)

Scenario 12

Trigger Bicyclist runs a red light

Sequence of Events System monitors bicycle non-compliance

Participants ☒ Leadership ☒ Engineering ☐ Maintenance ☒ Other PBOT ☐ Regional

Communication • Chart of bicycle non-compliance over time at a signalized intersection

• Map of bicycle non-compliance

Actions/Decisions • Prioritization of safety funding based on bicycle non-compliance

• Inform signal timing parameters (e.g., red, gap settings)

6.3. FAILURE EVENTS

Scenario 13

Trigger Traffic signal enters red flash

Sequence of Events System monitors frequency of red flash events

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency and duration of flash occurrences

• Map of flash occurrences

Actions/Decisions • Prioritization of maintenance funding based on flash occurrences

Scenario 14

Trigger Communication failure

Sequence of Events System identifies communication failure

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency and duration of communication failures

• Map of communication failure occurrences

Actions/Decisions • Prioritization of maintenance funding based on communication failures

Portland Bureau of Transportation 21 Signals, Street Lighting, and ITS

Scenario 15

Trigger Preemption stuck

Sequence of Events System identifies stuck preemption

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency and duration of stuck preemption (i.e., preemption on for a period exceeding a threshold)

• Map of stuck preemption occurrences

Actions/Decisions • Prioritization of maintenance funding based on stuck preemption

Scenario 16

Trigger Phase skipped

Sequence of Events System identifies skipped phase

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency of skipped phases compared to historical averages

• Map of skipped phase occurrences

Actions/Decisions • Prioritization of maintenance funding based on skipped phases

Scenario 17

Trigger Traffic signal stuck in all-red

Sequence of Events System identifies stuck all-red

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency and duration of stuck all-red (i.e., all-red on for a period exceeding a threshold)

• Map of stuck all-red occurrences

Actions/Decisions • Prioritization of maintenance funding based on stuck all-red

6.4. MAINTENANCE

Scenario 18

Trigger Detection fails (pedestrian)

Sequence of Events System identifies failed detection (pedestrian)

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency and duration of failed pedestrian detection

(e.g., zero calls, max presence, erratic counts, more/fewer calls than historical averages)

• Map of pedestrian detection health

Actions/Decisions • Prioritization of maintenance funding based on failed detection

(pedestrian)

Portland Bureau of Transportation 22 Signals, Street Lighting, and ITS

Scenario 19

Trigger Detection fails (vehicle or bicycle)

Sequence of Events System identifies failed detection (vehicle or bicycle)

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency and duration of failed vehicle/bicycle detection (e.g., zero calls, max presence, erratic counts, more/fewer calls than historical averages)

• Map of vehicle/bicycle detection health

(vehicle or bicycle)

Scenario 20

Trigger Detection fails (LRT or streetcar)

Sequence of Events System identifies failed detection (LRT or streetcar)

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency and duration of failed LRT/streetcar detection

(e.g., zero calls, max presence, erratic counts, more/fewer calls than historical averages)

• Map of LRT/streetcar detection health

(LRT/streetcar)

Scenario 21

Trigger Transit signal priority fails

Sequence of Events System identifies when TSP is not operating

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency and duration of failed TSP (e.g., zero calls, max presence, erratic counts, more/fewer calls than historical averages)

• Map of TSP health

Actions/Decisions • Prioritization of transit funding based on failed TSP

Scenario 22

Trigger Phase gapping out or maxing out/forcing off more than usual

Sequence of Events System identifies phases that are gapping out or maxing out/forcing off more than usual

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency of phases gapping out or maxing out/forcing off compared to historical averages

• Map of gap out versus max out/force-off comparison

Actions/Decisions • Prioritization of maintenance funding if gap-out or max-out/force-off issue is related to detection

• Inform signal timing settings (e.g., green, gap settings)

Portland Bureau of Transportation 23 Signals, Street Lighting, and ITS

Scenario 23

Trigger Traffic signal transitioning more than usual

Sequence of Events System identifies traffic signal transitioning more than usual

Participants ☒ Leadership ☒ Engineering ☒ Maintenance ☐ Other PBOT ☐ Regional

Communication • Chart of frequency of traffic signal transitioning compared to historical averages

• Map of transition occurrences

Actions/Decisions • Prioritization of maintenance funding if transition issue is related to preemption or detection

• Inform signal timing settings (e.g., cycle length, pedestrian signal timing settings)

7. SUMMARY OF IMPACTS

7.1. FUTURE SYSTEM ARCHITECTURE

The future ATSPM system will build upon the existing system architecture to include more data sources and users.

• The Open-Source Code will be installed on a dedicated server (either on-prem or in the cloud).

• The data will be stored in a SQL database on the dedicated server (either on-prem or in the cloud).

• PBOT SSL staff and other PBOT groups will be able to access the web interface over VPN or at their City workstations.

• Regional partner agencies will be able to view the PBOT system, either over the ITS Network if the server is on-prem or through a secure connection to the cloud, and will have access to the custom metrics developed as part of the Open-Source Code.

• Data will be queried from connected ATCs, roadside traffic signal detection sensors, and external data sources, including the TriMet API, RITIS, and safety cameras.

The future system architecture is illustrated in Figure 2 between the data sources, the server where the future ATSPM system will be housed, and the users of the system.

Portland Bureau of Transportation 24 Signals, Street Lighting, and ITS

Figure 4. Future Data Flow

Note: This is the future data flow with an on-prem server, comparable to the existing system architecture in Figure 2, but some changes would be required with cloud-hosting.

The typical workflow for the future ATSPM system will change from reactive to proactive:

• PBOT SSL staff will proactively monitor reports, charts, and maps daily. Using the information from the ATSPM system, engineers and electricians will make changes remotely (i.e., through the central traffic signal system). After changes have been implemented, the engineers and electricians will monitor intersections using the ATSPM system.

• Other PBOT Groups will use the data for planning, safety, design, and operations projects and for prioritizing funding.

• Regional Partners will be able to view the PBOT system, either over the ITS Network if the server is on-prem or through a secure connection to the cloud, and will be able to install their own version of the Open-Source Code enhancements.

ATSPM Server

Roadside Traffic

Signal Detection

Sensor

Firewall

Firewall

PBOT

Workstations

(Web Interface)

External

Safety Data

External

Probe Data

External

Transit Data

Advanced

Transportation

Controller (ATC)

PBOT

SSL Staff

Other PBOT

Groups

ATSPM

SQL Database

ATSPM

Open-Source

Code

Regional Partner

Agencies

ITS Network

(through

Firewall)

Portland Bureau of Transportation 25 Signals, Street Lighting, and ITS

7.2. STAKEHOLDER IMPACTS

Table 8 lists roles and responsibilities that will be impacted by a new ATSPM system for PBOT

Leadership, Engineering, and Maintenance staff, other PBOT Groups, and Regional Partners.

Table 8. Stakeholder Roles and Responsibilities

Stakeholder Roles/Responsibilities

Leadership • Monitor operations, safety, and maintenance status over time

• Use data for decision-making and funding prioritization

Engineering • Respond to public service requests

• Identify and implement signal timing adjustments proactively

• Monitor impacts of signal timing changes

• Work closely with maintenance staff on signalized intersection improvements

Maintenance • Respond to public service requests

• Identify and replace failing equipment proactively (e.g., detection, communication equipment)

• Work closely with engineering staff on signalized intersection improvements

Other PBOT Groups • Apply data to planning and safety studies

• Use data to prioritize investments

Regional Partners • Apply methodologies to process own data

7.3. CONSTRAINTS ON SYSTEM DEVELOPMENT

Limitations for the new ATSPM system are related to existing infrastructure.

• Existing communications network has areas with bandwidth constraints resulting in data-quality issues. No new interconnect or network equipment will be installed as part of this project.

• Data will only be available based on existing detection zones. No new detection systems will be installed as part of this project.

• Only intersections with connected ATCs will be available to add to the ATSPM system. No new controllers will be installed as part of this project.

• Traffic signal controllers require a new NTP server configuration for consistent data timestamps. A new NTP server is proposed as part of this project.

• PBOT SSL will require support with hardware selection and procurement after software selection.

• The ATSPM system will not initially be public-facing because of limited PBOT SSL staff resources. However, the dashboard should be planned such that it can be shared publicly in the future. Any public service requests for data will require a response caveating that data quality cannot be assured.

Portland Bureau of Transportation 26 Signals, Street Lighting, and ITS

7.4. ASSESSMENT METRICS

New ATSPM systems will be assessed based on the following categories.

• Existing Metrics: Does the new ATSPM system include the existing ATSPM metrics that

PBOT staff are familiar with applying to their work? Do the metrics use the same calculations and detectors?

• Aggregation: Does the ATSPM system include a dashboard that aggregates the data up from the signalized intersection level using maps, charts, and tables?

• Independent: Is the ATSPM system installed on equipment that is independent of any other system, including the central traffic signal system?

• Simple: Does the ATSPM system consolidate data sources into one system?

• Customizable: Is the ATSPM system customizable so that PBOT-specific metrics identified in the Operational Scenarios can be added for transit, pedestrians, and bicyclists?

• Open-Source: Is the ATSPM system open-source and sharable with other public agencies?