Technical Specification~3.pdf

June 2024

TSP

and

SPM

Next Generation of Transit Signal Priority and Signal Performance Measures Technical Specification Standard

Document No. 1 | Revision 7

Prepared for and

SPM

BUSPS13

Project No: BUSPS13 Document Title: Transit Signal Priority and Signal Performance Measures Technical Specification Document No.: 1 Revision: 7 Date: July 4, 2024 Client Name: Massachusetts Bay Transportation Authority Author: Jacobs - Thomas Udell, Enrique Porras, Diederick VanDillen

© Copyright 2023 The concepts and information contained in this document are the property of . Use or copying of this document in whole or in part without the written permission of constitutes an infringement of copyright.

Limitation: This document has been prepared on behalf of, and for the exclusive use of ’ client, and is subject to, and issued in accordance with, the provisions of the contract between and the client. accepts no liability or responsibility whatsoever for, or in respect of, any use of, or reliance upon, this document by any third party.

and

Contents

EXECUTIVE SUMMARY

MBTA TSP OPERATIONS

STANDARD SYSTEM COMPONENTS

1. CABINETS

2. CONTROLLERS

3. MULTIMODAL DETECTION (OPTIONAL)

3.1. Video Detection System (VDS)

3.2. Microwave Vehicle Detection System (MVDS)

4. PRIORITY REQUEST GENERATOR (PRG) / PRIORITY REQUEST SERVER (PRS)

5. COMMUNICATIONS AND REPORTING

6. VIRTUAL BUS DETECTOR METHODOLOGY

and

SPM

Executive Summary The MBTA, in partnership with local traffic signal owner-operating agencies, operates a Transit Signal Priority (TSP) system to improve the on-time performance and operational efficiency of the transit system.1 The MBTA bus/light rail fleet are equipped with onboard communications and GPS location technology that provides location and status information. The signal systems are expected to obtain this information from MBTA’s existing Automated Vehicle Location (AVL) system and provide TSP.2 The Next Generation of Transit Signal Priority and Signal Performance Measures Technical Specification is intended to serve as guidance to local agencies when procuring traffic signal control hardware and software to meet current best in class functionality including the specialized needs of the MBTA. It will also address improving accuracy of ‘stop bar’ arrival predictions, which significantly impacts TSP effectiveness; enabling the collection of high-resolution data for each intersection, allowing for more robust evaluation of the TSP system as a whole; and providing a suite of technologies at varying levels of technological capabilities and cost. As a benefit for the local agency, the high-resolution signal data collected by the Advanced Transportation Controllers (ATC) can be processed into Signal Performance Measures (SPMs) and then be used to optimize signal operations without the need for time consuming and expensive traffic studies.

MBTA TSP Operations MBTA, in partnership with local traffic signal owner-operating agencies, operates a TSP system to improve the on-time performance and operational efficiency of their buses.3 Figure 1 shows the elements used in the TSP system.

TSP operates as follows:

• The MBTA uses AVL to track bus locations on a continuous basis. MBTA makes this location information available in real-time through their publicly available API at www.mbta.com/developers.

• The priority request generator (PRG) identifies a bus approaching a signalized intersection.

• A priority request is created for each active in-service bus on the route and sent to the priority request server.

• Once received, a call is placed into the controller to request priority. There are several priority treatments that can reduce the time it takes the bus to move through the intersection. The two most common are extended green or shortened red. The decision to grant priority along with the type of treatment and the logic to recover to normal operations is all determined by the rules within the ATC.

• When the bus leaves the intersection, the priority request generator triggers the call to be dropped and the signal returns to normal operation.

The ATC collects and logs data including traffic volumes (from the intersection detectors), pedestrian pushbutton activity, signal phasing, TSP calls, and other controller functions every tenth of a second. This data is periodically sent to the local Agency and/or MBTA API for processing into T-SPMs.

1 These specifications focus on buses, but also apply to Green Line trolleys, which are within the purview of TSP when traveling through mixed-traffic intersections.

2 These specifications do not apply to for example the signals connected to the City of Boston’s Traffic Management Center.

3 Though these specifications have been focused on bus, they can also be applied to Green Line trolleys, which are also within the purview of TSP when travelling through mixed-traffic intersections.

Figure 1 Transit Signal Priority Operational Diagram

The system components included in this specification includes:

1. Cabinet: The traffic cabinet is the weatherproof enclosure where the various pieces of equipment are located at the intersection. The controller is housed within this cabinet and interfaces and interprets the inputs from the detectors and translates them to outputs to the traffic signal displays.

2. Controller: The traffic signal controller is the piece of equipment in the signal cabinet that translates input from detectors into the displays that are detected on the street. Signal timing parameters are programmed into the controller software to determine the allocation of green time and interpreting detector and display information.

3. Multimodal Detection: Detectors within the traffic signal system sense the presence of roadway users and provide the controller with information it can use to determine green allocation. Transit signal priority is a type of multimodal detection that can be used for buses and light rail. This specification addresses multimodal detection because today’s systems are largely focused on vehicular traffic (setback and stop bar detection) and pedestrian signal requests (push buttons).

a. Video Detection System (VDS): VDS uses video or thermal cameras and a machine vision processor to detect and classify traffic. Typically, one or more sensors communicate with a processor in the traffic signal cabinet to log and communicate detections to the local traffic signal controller. Machine vision processing may occur within the individual sensors or within the cabinet processor. The VDS can detect, track, and classify individual objects within its field of view. When the object crosses a user-defined detection zone the VDS generates a detection event which is sent to the local traffic signal controller. Sensors can be either a standard camera and

SPM

to see a single intersection approach or a 360-degree fisheye camera to simultaneously see all approaches. In the latter case, the video is post processed to de-warp the image to allow programming of detection zones and viewing video feeds. VDS can be negatively impacted by low visibility conditions including nighttime with poor lighting conditions and inclement weather.

b. Microwave Vehicle Detection System (MVDS): MVDS (commonly referred to as RADAR) utilizes a microwave transmitter/receiver to detect vehicles, bicycles, and pedestrians; some systems are also able to classify different vehicles. The sensor can detect, track, and classify individual objects within its entire field of view. When the object crosses a user-defined detection zone the MVDS generates a detection event which is sent to the local traffic signal controller. MVDS are not affected by lighting conditions and to a much lesser extent by weather. In their simplest form MVDS are motion detectors, while more advanced multi-sensor units can detect and maintain a call on a stopped vehicle.

4. Priority Request Generator (PRG)/Priority Request Server (PRS): The PRG and PRS are functional entities that work together to provide the necessary services needed to request TSP. In the case of MBTA, the PRG would receive active in-service bus AVL data on a continuous and real-time basis directly via the MBTA API. The PRS receives these data and translates them into the actual detector cabinet and/or controller inputs assigned to that function based on controller configuration. The PRS may perform additional filtering and logic functions based on local agency policy that may determine if and when a request is made. The MBTA uses unconditional TSP for every intersection therefore additional logic is not anticipated. The local traffic signal controller then determines if and how to adjust timings to support a priority movement for the bus based on a pre-defined TSP timing configuration. The controller determines issues such as reconciling simultaneous requests from different buses for competing priorities or lock out times that limit how often priority may be requested within a given time period.

The architecture and implementation details of the PRG/PRS may vary greatly depending on selected solution and agency equipment capabilities. Both a center-to-field (C2F) and center-to-center (C2C) architectural model are possible to implement TSP within the MBTA operational region. With C2F, the PRG may be either on-premise or cloud hosted. The PRG would communicate directly to a PRS in each field traffic signal controller cabinet thereby bypassing any central traffic signal management capability.

In this scenario a PRS device in each cabinet would receive the information and place a priority call into the controller. This would most likely be the case in situations where the local traffic signal owner-operating agency does not have a central traffic signal management system with full-time communications to each traffic signal cabinet. With C2C, the MBTA server communicates the AVL messages directly to the traffic signal owner-operating agency centralized traffic management system.

The centralized traffic management system would include the PRG functionality and would use the same communications path supported by other centralized traffic operations to also issue the TSP request to the traffic signal controller. The PRS function may reside centrally alongside the PRG or may be distributed to each traffic signal cabinet depending upon implementation details.

5. Communications and Reporting: The MBTA’s goal of signal communications is twofold; to provide TSP for transit vehicles moving through a signalized intersection, and to retrieve the hi-resolution data from traffic signal controllers to analyze and understand operational performance.

The MBTA has completed an effort to standardize transit detection setup so that this can be used with and

SPM

the ATSPM enumeration to produce Transit focused Signal Performance Measures (SPM). This data is typically stored in a circular buffer on each traffic signal controller. Each controller event is time stamped and stored in a first-in/first-out buffer that will begin to automatically overwrite the oldest events once the buffer is full. The number of recorded events over a given period is dependent upon the intersection complexity and traffic volumes.

and

SPM

STANDARD SYSTEM COMPONENTS

This level provides for basic performance standards required for a new or upgraded system to facilitate the continued MBTA TSP operation and collection and reporting of standard compliant hi-resolution traffic data that is required to calculate Signal Performance Measures to MBTA. It also provides the capability to improve ETA predictions overtime.

1. Cabinets The Cabinets shall meet the roadway owner specification and the project specific build materials requirements.

MBTA recommends following the standard and specification of Commonwealth of Massachusetts Department of Transportation Standard Specifications for Highways and Bridges Section M10: Traffic Control Devices.4

2. Controllers To provide the data needed for T-SPMs a NEMA standard ATC Controller with hi-resolution data logger is required. The data logger collects signal controller status on a 1/10th of a second interval. The data is defined and formatted in accordance with the Indiana Traffic Signal Hi Resolution Data Logger Enumerations 5(August 2020 or latest version.) This document defines the enumerations, events, parameters and descriptions of all hi-resolution data to be recorded on the traffic controller and forms the basis for calculating Signal Performance Measures.

• TS2-2016 Traffic Controller Assemblies with NTCIP Requirements Version 03.07 is the latest NEMA Traffic Signal Controller standard that provides a functional, mechanical, and electrical interface definition for the Field I/O connectors of the traffic controller. It provides cabinet level interchangeability but does not define nor support controller hardware or application software interchangeability. A controller from one vendor can be easily swapped with another vendor controller within the same NEMA TS2 cabinet, but controller component hardware and application software remain proprietary to the vendor. The TS2 standard utilizes a Synchronous Data Link Control (SDLC) serial communication Field I/O bus to communicate with cabinet devices.

• NTCIP 1202 v2 (Actuated Signal Controller object definition) with the Indiana Traffic Signal Hi- Resolution Data Logger Enumerations (defined in NTCIP 1202 v3) and allows for operational data to be retrieved from the controller. The following events are Mandatory [M], Strongly Recommended [SR], and Desired [D] to be in the high-resolution log.

i. [M] Phase Begin Green

ii. [M] Phase Begin Yellow Clearance

iii. [M] Phase End Yellow Clearance

iv. [M] Detector Check-in (for TSP virtual detectors, defined in the MBTA TSP detection guidance)

v. [M] Detector Check-out (for TSP virtual detectors, defined in the MBTA TSP detection guidance)

vi. [M] TSP Check-in

vii. [M] TSP Check-out

viii. [M] TSP Types (Early Return, Green Extension, etc.)

4 https://www.mass.gov/doc/2023-standard-specifications-for-highways-and-bridges-division-iii/download 5 Li, Howell & Hainen, Alexander & Sturdevant, James & Talukder, Md Abu Sufian & Mathew, Jijo & Bullock, Darcy & Nelson, Daniel & Maas, Donald. (2019). Indiana Traffic Signal Hi Resolution Data Logger Enumerations. 10.5703/1288284316998.

and

SPM

ix. [M] TSP denied reason

x. [SR] Priority Parameter (Time of Service Desired, Priority Class, Transparity Parameter, etc.)

xi. [SR] Detector Check-in (other)

xii. [SR] Detector Check-out (other)

xiii. [SR] Phase Gap Out

xiv. [SR] Phase Max Out

xv. [SR] Phase Force Off

xvi. [D] Other event listed in the Indiana Traffic Signal Hi Resolution Data Logger Enumerations

• The NTCIP 1211 Object Definitions for Signal Control and Prioritization (SCP) standard defines the application layer data to be exchanged to support bus or rail transit signal priority (TSP). The NTCIP 1211 SCP Concept of Operations is comprised of two primary elements, the Priority Request Generator (PRG) and a Priority Request Server (PRS). A transit vehicle, which could be a light rail train, bus, or other transit vehicle, through its agent, the PRG, submits a request for priority to the PRS. These two elements can be thought of as a logical process that could be physically implemented in more than one way. The specific hardware implementation details are not defined here but left to the local agency and MBTA to determine. The standardization occurs at the interface of these processes and represents the objects developed by NTCIP 1211. The two primary interfaces are (1) between PRG and PRS and (2) between PRS and the traffic signal controller coordinator, which implements special coordination operation.

o If the vendor is not compliant but conformant to the NTCIP 1211 standard. The vendor shall provide information to MBTA that demonstrates its equivalent functionality with the NTCIP 1211 mandatory objects. The information includes but is not limited to firmware documentation, proprietary Management Information Base (MIB), and a mapping of how each function in NTCIP 1211 is met through vendor-specific functions. The vendor will be responsible for integrating with all other TSP vendors MBTA selects and shall provide integration materials to MBTA and its designated vendors and localities during its service period.

ATC 5201 v06.34 (or newer) standard defines a minimum required functional capability of hardware and software for an on-street transportation controller computing platform. A key component of the standard is the Engine Board which contains all of the computational facilities. Standardized edge connectors define how this board mates with the receiving Host Module of the controller platform.

While the Engine Board is completely specified, the Host Module and the rest of the controller platform may be of various shapes and sizes based on vendor preference. The intention is to allow portability of the Engine Board to accommodate upgrades with technology advances or cross vendor deployment.

The standard defines minimum physical interfaces to ensure compatibility with all major transportation field cabinets.

3. Multimodal Detection (Optional) MBTA is recommending the use of multimodal detection as a possible addition to the Next Generation TSP system in order to have a more complete picture of all road users. Non-intrusive multimodal detection includes detection for pedestrians, bicycles, and other vulnerable road users in addition to detecting various different vehicle classifications to provide improved service for all travelers. This more complete picture can be used to better optimize signal operations to help MBTA passengers reach the service provided. The use of multimodal detection can support the agency’s desire to meet mobility goals (e.g., pedestrian or bicycle progression, person and

SPM

delay vs vehicle delay, etc.). The Multimodal Detection can be achieved through either Video Detection System or Microwave Vehicle Detection System.

3.1. Video Detection System (VDS)

This section defines the minimally required functional aspects of the system as well as the required accuracy levels. Detection zones

i. Provide capability to emulate the output of consecutive 6 ft. by 6 ft. (1.8 m by 1.8 m) in-pavement loops spaced 8 ft. (2.4 m) apart for stop bar applications at traffic signals.

ii. Provide capability to emulate the output of in-pavement loops ranging from 6 ft. by 20 ft. (1.8 m by 6.1

m) to a 6 ft. by 50 ft. (1.8 m by 15.2 m) for stop bar applications at traffic signals and ramp meters.

iii. Provide a minimum of 16 detection zones with one video camera sensor.

iv. Enable multiple detection zones to be logically combined onto a single channel.

v. Provide in-cabinet VDS processor front panel that includes the status of the following:

o VDS processor (online).

o Network communications (transmit/receive).

o VDS processor to camera assembly communications.

o Active detection for each video camera assembly.

vi. Provide a VDS processor with standard NEMA cabinet level interface to provide pulse and presence type logic level inputs to the controller.

vii. Ensure that VDS provides vehicle presence, speeds, vehicle counts and roadway occupancies on a lane-by-lane basis.

viii. Ensure that the VDS can detect and classify Pedestrian and Bicycle traffic. These detections shall be able to be output on separate detector channels.

ix. Provide processor with non-volatile memory enough to store all system detection zones settings and two weeks of binned detection data. Ensure the processor includes a published API that may be used to automatically retrieve the recorded data.

x. Provide capability to display detection zones superimposed on the camera sensor images on a monitoring device and centralized video system.

xi. Verify that the system responds with the accumulated binned traffic data collected since the last data request with no gap in data.

xii. Provide processor equipped with video stabilization to compensate for camera movement attributable to temperature effects, wind shifting, pole sway, pole expansion, or vibration.

3.2. Microwave Vehicle Detection System (MVDS)

This section defines the minimally required functional aspects of the microwave detection system as well as the required accuracy levels. It also outlines the testing process that will be used to determine whether a proposed microwave detection system product meets these specifications.

i. Ensure that MVDS provide vehicle presence, speeds, vehicle counts and roadway occupancies on a lane-by-lane basis.

ii. Ensure that the MVDS can detect and classify Pedestrian and Bicycle traffic. These detections shall be able to be output on separate detector channels.

iii. Provide processor with non-volatile memory enough to store all system detection zones settings and two (2) weeks of binned data. Ensure the processor includes a published API that may be used to automatically retrieve the recorded data.

iv. Verify that the traffic data collected by the microwave detection system is stored in internal non-volatile memory.

v. Verify the MVDS enables local and remote configuration and monitoring including data retrieval using computers on the network.

vi. Verify that the system configuration data and software are also stored within internal non-volatile memory in repeaters.

and

SPM

vii. Verify the system enables the user to view live actuations from the microwave detector with the programmed detectors overlaying a representation of the roadway.

viii. Verify the microwave detection system configuration data can be uploaded and saved to a laptop or performed over the network to re-load to the processor, if necessary.

ix. Verify no periodic adjustments or fine-tuning is required except in the case of physical roadway changes such as lane-shifts, new construction, or closures.

4. Priority Request Generator (PRG) / Priority Request Server (PRS)

i. The PRG should be capable of ingesting AVL data, providing simple trip wire check-in/check-out detection based on virtual detector locations, and evaluating each received AVL record to determine the bus location relative to the TSP detector locations.

ii. The PRG needs to have a map of the agency intersections, intersection names and numbers, and accurate geospatial information about each intersection TSP detectors (check-in, and check-out) for all bus routes and approaches.

o The TSP virtual detectors should be programed based on the MBTA TSP detection guidance.

5. Communications and Reporting The MBTA’s goal of signal communications is twofold; to provide TSP for transit vehicles moving through a signalized intersection, and to retrieve the hi-resolution data from traffic signal controllers to analyze and understand operational performance.

i. Either modem to connect signal to cloud and receive priority and preemption requests, or central signal system with active link to signals and connected to the cloud.

ii. All communications need to be compliant with national standard (NTCIP)

iii. All communications to support this capability need to conform to Internet Protocol (IP) broadband standards.

iv. For the TSP systems to operate properly, hardware must be capable of supporting continuous full-time

IP communications.

v. Depending upon the local agency architecture, the communications can either be dedicated to the TSP function or be combined with other signal management functions onto a signal communication channel.

To support TSP operation, the traffic signal owner-operating agency needs to have a centralized PRG process capable of connecting to the MBTA’s API. This connection enables reception of continuous and real-time bus location data.

i. An Internet-based virtual private network (VPN) broadband connection (typically 1-15Mb/s) with MBTA is preferred.

ii. A single PRG process and VPN-based API connection is preferred to manage this interface more efficiently.

iii. TSP communications between the PRG/PRS and each local traffic signal controller requires minimal bandwidth (typically <1Mb/s).

iv. Low latency performance is required for each connection to ensure timely reception and processing of TSP requests.

To support hi-resolution data reporting, the traffic signal owner-operating agency needs a centralized file server capable of connecting to the MBTA API to report back hi-resolution data collected and stored on the traffic signal controller.

i. A single Internet-based VPN API connection (typically 1-15Mb/s) is preferred.

ii. This connection may be shared with the PRG.

and

SPM

iii. Communications between the central file server and each local traffic signal controller requires minimal bandwidth (typically <1Mb/s).

iv. Either FTP or API can be used to report the data. Both need to account for the possibility of duplication due to the nature of the controller circular buffer. The vendor API need to be compatible with MBTA system to allow data reporting. The MBTA Customer Technology Department (CTD) team shall provide the specifications on the API details.

v. To avoid conflict, it is recommended that only a single central system for each agency be responsible for collecting and storing the data from each controller and then making it available to all other users including the MBTA.

vi. The upload frequency of the data from each controller shall be an hour or at maximum upload frequency and storage capacity shall be sufficient for a year worth of data.

vii. Security. All data and access to data stored on the controller shall be password protected and secure.

viii. Data recording. See Section 4, Detector Placement on how transit location data is to be recorded within the controller data logger.

ix. Data Transfer. All Signal Controller Data shall be transmitted hourly to MBTA’s Amazon Web Services

(AWS) S3 bucket “cloud storage”. If vendor utilizes Amazon AWS, MBTA will provide cross account access. If vendor does not utilize Amazon AWS, MBTA will provide the access key and secret key to storage. Any data written in a proprietary format must be decoded by the vendor to convert the data to a comma separated values file type (CSV). This decoding can either occur prior or after submitting the data to the MBTA’s “cloud storage” but it is the vendor’s responsibility that this data has been converted to the CSV regardless of where in the process this conversion occurs. The file name and folder structure should follow the guidance in Chapter 7.

x. Troubleshooting. If the data is not transmitting properly which could be due to a number of factors including but not limited to: internet or power outages at the traffic signal, data corruption issues, file transfer issues or software credentialing issues the vendor shall make a reasonable and timely effort to troubleshoot and resolve the issue within 3 business days.

xi. Years of Service and Renewing. It is expected that the vendor will provide signal data for 3 years from installation. If vendor is no longer doing business, vendor shall provide reasonable accommodation to transfer product and software to MBTA and/or municipality.

xii. Renewing. As part of the bid, the vendor shall provide a quote for an additional 4 renewal periods of 3 years each. The MBTA and/or City may at its option renew up to 4 additional times at the quoted price. It is expected that the renewal price is less than the initial 3-year price because no installation, hardware and only minimal maintenance should be required. The vendor may include bulk discounts for bulk renewing orders. The MBTA and/or City has full flexibility to renew some or all the signals for any number of renewal periods up to the 4. For example, if the MBTA and/or City chose to use all 4 renewal periods the total time of service would be 15 years: 3 years for the initial service and 4 renewal periods at 3 additional years each.

xiii. Unless otherwise specified, all internet communication to/from the signal controller and its component parts shall be in operation for 15 years. The difference between the renewal period in the bullet above and this is that TSP will be functioning for 15 years, but the measures of effectiveness and signal performance metrics would not be expected to be maintained if MBTA chooses not to renew.

6. Virtual Bus Detector Methodology The purpose of this memorandum is to establish a regionally consistent way to define detectors to locate buses with respect to a signalized intersection for high-resolution signal controller data.

Background To provide Transit Signal Priority (TSP) at a signalized intersection, an arriving bus is first detected with an and

SPM

upstream detector and a request is made to the signal controller to prioritize the bus movement through the signal. To measure the effectiveness of TSP, high-resolution signal controller data is utilized to track changes to signal phasing and timing, bus arrivals, and delays. Within the MBTA service area, each municipality installs, operates, and maintains its signal controllers in its jurisdiction, using various signal controller manufacturers, operating infrastructure, and communication infrastructure. However, each TSP vendor must detect an MBTA transit vehicle via our publicly available API.

MBTA is in the process of developing a dashboard to capture transit-specific performance metrics at TSP-enabled intersections utilizing high-resolution signal controller data. To enable this, MBTA is developing specifications to standardize TSP functionality, detector placement, reporting of metrics, and high-resolution data formats. This memo addresses the detector placements of typical intersection layouts to demonstrate how to locate a bus arrival upstream of an approach and track the bus location as it traverses the intersection.

The bus-specific detector calls are logged into the high-resolution data files, which are then processed to generate TSP-specific performance metrics.

Detector Lengths Bus detectors should be sized to capture the necessary number of GPS pings from a bus. The recommended detector length can be calculated based on the formula below:

𝐿 = 𝑣 × (𝑛 + 1) × 𝑓 × 1.467 Where:

L= recommended detector length (ft), rounded up to the nearest 50 v= average bus travel speed (mph) n= minimum number of pings needed to geolocate the bus and the direction of travel f= bus ping frequency (sec)

For example, the if a bus travels at an average speed of 20 mph, pings every 6 seconds and the geolocator system needs two pings to locate the buses, then the recommended detector length is 20 * (2+1) * 6 *1.467 ~ 550 ft.

Detector Placement For each intersection approach, when possible, place 3 virtual ‘geofence’ detectors at each approach one ½ mile upstream, one ¼ mile upstream and one L (recommended length) feet to the stop bar. Additionally, place one virtual ‘geofence’ detector as a check-out on the departure approach.

When this is not feasible due to upstream signalized intersections, adjust accordingly by placing the furthest upstream detector immediately downstream of the next upstream signal. All upstream detector boundaries shall start at the aforementioned locations enabling the bus to trigger the detector. For the detector at ½ mile upstream, the detector shall begin at ½ mile upstream and shall be the calculated length downstream.

Detector Event Parameter Values The purpose of the event parameter values is to identify the bus approach and movement with respect to the signalized intersection. Each virtual ‘geofence’ detector is assigned a unique parameter value of event codes 82 detector-on and 81 detector-off as defined in the Indiana Traffic Signal Hi Resolution Data Logger Enumerations6 that can be mapped to the intersection. Given that each intersection is unique and could have multiple configurations, a consistent way to number parameters of detector

6 https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1003&context=jtrpdata https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1003&context=jtrpdata and

SPM

events is necessary.

Using the approach that is closest to the cardinal north direction for each intersection, detector parameters can be numbered starting from 50 for the upstream check-in detector and sequentially numbering them until the check-out detector. The numbering continues on the next approach in the clockwise direction and sequentially numbering them from the upstream check-in to the check-out.

For example, if an intersection has four legs, and the approach that is closest to cardinal north has four detectors: a check-in, an update, a stop-bar and a check-out detector, they would be numbered 49, 50, 51, and 52 respectively.

If one or more approaches have more than one bus route coming from different streets, more than 4 detectors are needed for those approaches. The route that is closest to the cardinal north or the previous leg in the clockwise sequential order will be numbered first. The other routes for this approach will be numbered after all other approaches’ first routes were numbered. The approach without any bus route won’t be numbered., The numbering for the second route will start from the smallest unused number between 49 and

64. After all the second routes for each approach are numbered, move to the third route for each approach. If all the numbers between 49 and 64 were used, the one ½ mile upstream detectors could be skipped.

The detector numbering for each intersection should be documented.

Detector configurations for typical intersection layouts Figures 8, 9, and 10 show the configuration of a typical 4-legged, 3-legged, and 5-legged intersection respectively.

Detector configurations for atypical intersection layouts Figures 11 show the configuration of an intersection with bus routes from different streets arriving at the same approach.

Figure 2: Detector Configuration - 4-legged intersection

As mentioned previously, the approach that is closest to cardinal north (southbound approach) has three upstream detectors and a downstream check-out detector, they shall be numbered 49 through

52. Next, working clockwise through the approaches, the westbound approach shall be numbered 53 through 56, the northbound approach shall be numbered 57 through 60 and the eastbound approach shall be numbered 61 through 64.

Figure 3-1: Detector Configuration - 3-legged intersection

Figure 9-2: Detector Configuration - 3-legged intersection

Figure 9-3: Detector Configuration - 3-legged intersection

Figure 9-4: Detector Configuration - 3-legged intersection

A three-legged intersection shall be numbered like a 4-legged intersection but skipping the numbers for the and

SPM

absent leg. Take Figure 2-4 as example, the approach that is closest to cardinal north (southbound approach) has three upstream detectors, and a downstream check-out detector, they shall be numbered 49 through 52.

Next, working clockwise through the approaches, the westbound approach check-in detectors shall be numbered 53 through 55 but 56 for check-out detector shall be skipped since there’s no receiving lane on the west side. The northbound approach shall be numbered 57 through 60. The eastbound approach check in detectors shall be skipped since there is no eastbound approach and the check-out detector shall be numbered 64.

Figure 10: Detector Configuration - 5-legged intersection

For a five-legged intersection, the approach that is closest to cardinal north has three upstream detectors and shall be numbered 45 through 48. Other approaches shall be numbered going clockwise as shown in the above figure.

Figure 11 Detector Configuration – Intersection approach with bus routes from different streets and

SPM

7. High-Resolution File Structure and Naming Standards Once a file is retrieved from a traffic signal controller, the vender should convert it to csv file and rename it to the following format:

CCCLLLL_AAA_XXX.XXX.XXX.XXX_YYYY_MM_DD_HHHH.csv Where:

• CCC = Three-digit Agency (City) Code.

o Example: BOS, SOM, ARL, CAM, REV, EVE, QUI, MAL, BRO, CHE

• LLLL = Intersection (Location) Number o Range: 0001 – 9999 o Assigned on a first come first served basis. The vendor should provide a look up table including for each intersection.

• AAA = Manufacturer identification string o SIE = Siemens/Yunex Traffic o ECO = Econolite o TRA = Trafficware o MCC = McCain o ORI = Oriux

• XXX.XXX.XXX.XXX – IP address of the traffic signal controller

• YYYY_MM_DD_HHHH – Year, month, day, and hour when the log file was started. All the hours should be in EST.

CCCLLLL uniquely identifies each intersection, and the vendor should provide a table lookup and numbering map for the intersection and CCCLLLL code and avoid duplicate IDs with other vendor.

The vendor will need to remove the first line of data in each CSV “the header” for each file to be usable. The first line of each file contains column header names. Optionally, each file can be zipped (gz) to reduce the storage space and to reduce the volume of data processed by each query.

The file should be stored in the following structure.

<AWS S3 Bucket> csv/

Vendor/ id=CCCLLLL/ dt=YYYY_MM_DD/ CCCLLLL_AAA_XXX.XXX.XXX.XXX_YYYY_MM_DD_HHHH.csv

(All log files collected for the intersection for the specific date)

This storage structure permits the CSV files to be queried in place by the serverless query service. The id and dt prefixes are column name headers that permit the files to be queried by intersection and date range.