Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
CHAPTER 4 SYSTEM NEEDS FOR PERFORMANCE MEASURES 4.1 GAP ASSESSMENT 122 4.2 DATA SOURCES 124 4.3 TECHNICAL REQUIREMENTS 134 4.4 DATA MANAGEMENT 146 4.5 CONSIDERATIONS FOR ATSPM SYSTEM SELECTION 147 4.6 REFERENCES 149 LIST OF EXHIBITS EXHIBIT 4-1. EXISTING RESOURCE CHECKLIST 123 EXHIBIT 4-2. DATA SOURCES 124 EXHIBIT 4-3. AUTOMATED VEHICLE LOCATION (AVL) DATA EXAMPLE: TIMESTAMPED VEHICLE LOCATION DATA OBTAINED FROM A PRIVATE-SECTOR VENDOR (DAY ET AL. 2016) 131 EXHIBIT 4-4. CONNECTED VEHICLE DATA EXAMPLE: VEHICLE POSITION IN THE LANE (U.S. DOT 2015) 133 EXHIBIT 4-5. ATSPM SYSTEM COMPONENT DESCRIPTIONS 134 EXHIBIT 4-6. EXAMPLE NETWORK ARCHITECTURE USING DIFFERENT COMMUNICATION METHODS (DAY ET AL. 2016) 136 EXHIBIT 4-7. EXAMPLE EMBEDDED PC USED TO COLLECT ATSPM DATA (COURTESY HOWELL LI, PURDUE UNIVERSITY) 137 EXHIBIT 4-8. DETECTION REQUIREMENTS FOR SIGNAL PERFORMANCE MEASURES 139 EXHIBIT 4-9. EXAMPLE DETECTION LOCATIONS 140 EXHIBIT 4-10. EXAMPLE DETECTOR MAPPING INFORMATION 141 EXHIBIT 4-11. EXAMPLE AS-BUILT DRAWING (COURTESY INDIANA DEPARTMENT OF TRANSPORTATION) 142 EXHIBIT 4-12. EXAMPLE DETECTOR RACK WITH LABELING FOR DETECTOR CHANNELS (COURTESY INDIANA DEPARTMENT OF TRANSPORTATION) 142
CHAPTER FOCUS Once an agency has identified signal performance measures to implement, staff will need to determine if their existing system can achieve those metrics or if new resources will need to be procured. Chapter 3 introduced some of the resources required for each signal performance measure, including data sources and detection. This chapter describes those elements in more detail. Using the information in Chapter 4, an agency should be able to start a procurement process for required resources. 4.1 GAP ASSESSMENT An agency should determine if additional equipment and/or staff are needed to deploy desired signal performance measures. Resource needs can generally be organized into three categories: System components including communication, detection, data logging, data storage, and software. Workforce resources (i.e., staff) required to apply signal performance measures. Business processes including formal scoping, planning, programming, and budgeting processes. EXHIBIT 4-1 is a high-level checklist that can be used to start a gap assessment. Existing capabilities may influence which signal performance measures are implemented to meet near-term goals and can also highlight needs required to meet long-term goals. For example, an agency may want to assess split failures, but the required stop bar detection may not be installed on every approach. In the near term, the agency may decide to use phase termination information to estimate the likelihood of split failures, with a long- term goal of installing additional detection. An agency should fill out a gap assessment considering both their own resources as well as any shared resources that may be available to them. For example, local agencies may be able to share resources with the state. In Utah, many local agencies operate their own traffic signals but are able to integrate them with the Utah Department of Transportation (UDOT) Automated Traffic Signal Performance Measure (ATSPM) system (UDOT).â 122 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
EXHIBIT 4-1. EXISTING RESOURCE CHECKLIST SYSTEM COMPONENTS COMMUNICATION  Communication available? Communication Type: DETECTION  Detection as-built drawings available?  Detector channel mapping information available? Detector Wiring: ï¯ Lane-by-Lane ï¯ Multi-Lane Detection on Major Street/Minor Street/Left-Turn Lanes: ï¯ Stop Bar Presence ï¯ Stop Bar Count ï¯ Advance ï¯ Count Past the Stop Bar ï¯ Speed For Advance Detection, Distance from Stop Bar: DATA LOGGING Controller Vendor: Model Number: Onboard Cards (If Any): External Hardware Vendor: Model Number: Firmware Version:  Firmware upgrade required?  High-resolution data logging available? DATA STORAGE  Server available for data storage?  Cloud-based solution available for data storage? Available Storage Capacity: SOFTWARE  Database available? Database Type:  Central system available? Central System Type: WORKFORCE STAFFING RESOURCES Signal Engineers/Technicians: IT Staff (Available to Support Traffic Signal Network): IT Staff Experience: ï¯ Databases ï¯ Programming ï¯ Network  Opportunities for ongoing training? Senior/Executive Managers: Senior-Level Support: ï¯ High-Committed ï¯ Medium-Interested ï¯ Low-Skeptical BUSINESS PROCESSES DOCUMENTATION  Traffic Signal Management Plan?  Business process documented?  ATSPM documented in agency policy?  Design and maintenance standards?  ATSPM budget line item? COORDINATION Partner Agencies: Shared Staff Resources: Shared Technology: SYSTEM NEEDS FOR PERFORMANCE MEASURES 123
4.2 DATA SOURCES There are two categories of data that will be explored in this guidebook: the external data sources that measure traffic performance without using information from a traffic signal controller and the internal data sources that capture traffic signal controller events. EXHIBIT 4-2 summarizes seven data sources (organized into internal and external data) that can be used to produce signal performance measures. Historically, external data required manual collection methods. Turning movement counts were recorded by a human observer or travel times were collected using a âfloatingâ car driven by an analyst. Over the years, methods of automating those data- EXHIBIT 4-2. DATA SOURCES DATA SOURCE TYPE DESCRIPTION Controller (High- Resolution Data) Internal Timestamped âeventsâ (e.g., detector inputs and signal display outputs) recorded by the controller at 1/10-second resolution. Central System (Low-Resolution Data) Internal Volumes, detector occupancies, green times, and phase terminations aggregated for a selected time period (e.g., 1, 5, or 15 minutes) by the central system. Vendor-Specific Both Data collected by detection systems, preemption systems, and adaptive control systems. Automated Vehicle Identification (AVI) External Travel time, route choice, and origin-destination estimated through identification of unique vehicle identifiers at multiple locations (using Bluetooth MAC addresses, Wi-Fi network IDs, physical detector signatures, or toll tag readers). Probe Vehicle Segment Speed External Average speeds on pre-defined segments aggregated using data from individual probe vehicles. Automated Vehicle Location (AVL) External Timestamped GPS coordinates of probe vehicles collected using external hardware or âcrowd-sourcedâ applications. GPS coordinates for probe bicycles and pedestrians could also be obtained. Connected Vehicle (CV) External CV data are similar to AVL data but contain more information about vehicle characteristics. CV data are defined by the SAE J2735 standard, which includes Basic Safety Messages (BSM), Signal Phase and Timing (SPaT) messages, and likely traveler information messages in the future. collection activities emerged. Looking to the future, connected vehicles will continue to advance available external data through detailed vehicle-location information. A complementary dataset is internal to the traffic signal controller. This dataset captures signal state and detection events. It has always been available through the electrical impulses sent to the signal displays and received from detectors, but the development of âhigh-resolution dataâ has allowed for the continuous collection and storage of those traffic signal events. High-resolution controller event data are considered a valuable source of signal performance measures and has been given significant attention throughout this guidebook. 124 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
The following information is provided as a âprimerâ for each data source. DESCRIPTION Detailed description of the data source. REQUIREMENTS COMMUNICATION Intersection and system components required to produce the data, organized using five categories. DETECTION DATA LOGGING DATA STORAGE SOFTWARE AVAILABILITY Current availability of the data through agency sources or private-sector vendors. CAPABILITIES Advantages to using the data source. CHALLENGES Potential complications of using the data source. EXAMPLE DATA Example of how the data are reported. SYSTEM NEEDS FOR PERFORMANCE MEASURES 125
4.2.1 CONTROLLER HIGH-RESOLUTION DATA DESCRIPTION The data consist of timestamped events (and associated parameters) recorded at the nearest 1/10-second by the traffic signal controller. Events describe state changes at the intersection such as outputs to the signal displays and inputs from the detectors (Sturdevant et al. 2012), and parameters give additional details about the event such as the associated phase or detector. For example, Event Code 1 is recorded when a phase begins its green interval. If Event Code 1 is recorded along with Parameter 4, the event that occurred is Phase 4 beginning its green interval at the designated timestamp. REQUIREMENTS COMMUNICATION ⢠Communication is needed to collect the data without manual retrieval. DETECTION ⢠Detection is needed to record the presence of roadway users. DATA LOGGING ⢠Many different types of traffic signal controllers (i.e., ATC controllers) are now capable of logging high-resolution data. ⢠Another option is to use a stand-alone device that is external to the traffic signal controller to record the data. These devices can typically be used alongside older traffic signal controllers. ⢠It is also possible to develop equivalent data by central system polling (i.e., retrieving real-time status). However, this method does not tolerate any latency in the communication system. DATA STORAGE ⢠Either a server or cloud-based solution is required to store the data. SOFTWARE ⢠Open source software is available for data processing. ⢠Vendors have software available through central systems and web-based platforms. AVAILABILITY ⢠Most traffic signal controller manufacturers have at least one controller model that supports high-resolution data logging. ⢠Other vendors have external data collection units that can be used with older controllers. CAPABILITIES ⢠Highly detailed records allow a wide variety of signal performance measures to be calculated. CHALLENGES ⢠Because of the large amount of data, system management may be challenging for some agencies. EXAMPLE DATA 1/10-Second Enumerations TIMESTAMP EVENT CODE PARAMETER DESCRIPTION 02/15/17 12:01:16.0 8 4 Phase 4 Begin Yellow Clearance 02/15/17 12:01:16.0 8 8 Phase 8 Begin Yellow Clearance 02/15/17 12:01:19.4 81 9 Detector 9 Off 02/15/17 12:01:19.5 10 4 Phase 4 Begin Red Clearance 02/15/17 12:01:19.5 10 8 Phase 8 Begin Red Clearance 02/15/17 12:01:20.0 1 2 Phase 2 Begin Green 02/15/17 12:01:20.0 1 6 Phase 6 Begin Green 02/15/17 12:01:25.5 82 19 Detector 19 On 02/15/17 12:01:28.0 81 19 Detector 19 Off 02/15/17 12:01:29.3 82 9 Detector 9 On 126 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
4.2.2 CENTRAL SYSTEM LOW-RESOLUTION DATA DESCRIPTION Volume and occupancy data have been available through central systems for many years. These data typically consist of volumes (vehicle counts) and detector occupancy measurements averaged over a time period such as 1 minute, 5 minutes, or 15 minutes. Some central systems can also provide aggregated phase information such as average green times or termination types (i.e., max-outs, force-offs, gap-outs, skips). REQUIREMENTS COMMUNICATION ⢠Communication is needed to collect the data without manual retrieval. DETECTION ⢠Detection is needed to record the presence of roadway users. DATA LOGGING ⢠The data require a central system capable of polling the controllers, storing the data, and displaying or exporting it.DATA STORAGE SOFTWARE AVAILABILITY ⢠Most central systems can produce this type of data. ⢠Not all locations will have appropriate communication or detection in place to collect it. CAPABILITIES ⢠The data are readily available to an agency using a central system. For an agency that does not have resources to collect any other type of data, low-resolution data may provide an interim solution for performance-based management. CHALLENGES ⢠The level of detail in the data is typically low, so in-depth, cycle-by-cycle analysis will not be possible. ⢠Equipment interoperability may be an issue with some central systems. EXAMPLE DATA 15-Minute Volumes TIMESTAMP NBL NBT NBR EBL EBT WBT WBR 03/07/18 17:00-17:15 12 21 77 78 329 258 128 03/07/18 17:15-17:30 10 20 61 92 323 265 126 03/07/18 17:30-17:45 3 21 65 107 376 273 110 03/07/18 17:45-18:00 6 27 68 92 297 275 124 03/07/18 18:00-18:15 9 27 44 92 310 248 120 03/07/18 18:15-18:30 8 22 67 91 284 199 116 03/07/18 18:30-18:45 7 25 60 92 278 184 141 03/07/18 18:45-19:00 5 20 51 94 230 181 114 03/07/18 19:00-19:15 7 22 48 90 213 156 109 03/07/18 19:15-19:30 11 20 40 105 226 162 138 SYSTEM NEEDS FOR PERFORMANCE MEASURES 127
4.2.3 VENDOR-SPECIFIC DATA DESCRIPTION Many vendors provide data directly from their equipment, which can include detection systems, preemption systems, and adaptive control systems. Most of these systems are proprietary and require specific equipment and software. REQUIREMENTS COMMUNICATION ⢠Communication is needed to collect the data without manual retrieval. DETECTION ⢠This type of data requires investment in a specific system (i.e., detection, preemption, adaptive) and all the necessary components. DATA LOGGING DATA STORAGE SOFTWARE AVAILABILITY ⢠Available through private-sector vendors. ⢠In general, these systems are not procured for performance measurement purposes alone but as part of a larger program of system upgrades. CAPABILITIES ⢠Detailed, cycle-by-cycle metrics can be obtained from certain types of proprietary systems. CHALLENGES ⢠Interoperability with equipment from other vendors is unlikely except in cases where the traffic signal cabinet and controller are modern, standards-based equipment that is compatible with other software and firmware. Intersections must be equipped with the same vendor-compatible equipment in order to obtain comparable data. EXAMPLE DATA Adaptive Splits PH 1 PH 2 PH 3 PH 4 PH 5 PH 6 PH 7 PH 8 Active Split (Sec) 11 18 15 16 12 17 15 16 Utilization (%) 100 69 95 81 100 61 61 63 Next Split (Sec) 13 19 14 14 14 18 15 13 128 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
4.2.4 AUTOMATED VEHICLE IDENTIFICATION (AVI) DATA DESCRIPTION Automated vehicle identification (AVI) involves identifying vehicles through unique identifiers at multiple locations. Matching identifiers allow the travel time between locations to be estimated. Other network dynamics such as route choice and origin-destination patterns can also be deduced. There are several technologies that can be used to collect AVI data, including Bluetooth MAC addresses, Wi-Fi network IDs, physical detector signatures, and toll tag readers. REQUIREMENTS COMMUNICATION ⢠Communication to sensors is required for the data to be collected without manual retrieval. DETECTION ⢠Sensors must be procured, installed, and maintained in order to produce AVI data.DATA LOGGING DATA STORAGE ⢠Either a server or cloud-based solution is required to store the data. SOFTWARE ⢠Software is needed to process the relevant data into performance measures. AVAILABILITY ⢠Available through private-sector vendors. CAPABILITIES ⢠AVI allows corridor-level data to be collected at a much higher rate than through manual methods such as floating-car studies. CHALLENGES ⢠A minimum of two sensors are required on each individual route. Developing travel times for many routes or for turning movements requires a higher number of sensors. As a result, AVI data tend to be collected only for major movements. EXAMPLE DATA Bluetooth MAC Address Travel Times START TIME END TIME IDENTIFIER TRAVEL TIME (SEC) SPEED (MPH) 12/01/17 13:18:29.0 12/01/17 13:20:11.0 1AC5D6 102 26.0 12/01/17 13:18:46.0 12/01/17 13:20:42.0 005FE5 116 22.8 12/01/17 13:20:14.0 12/01/17 13:22:06.0 314324 112 23.6 12/01/17 13:22:14.0 12/01/17 13:23:45.0 770FB0 91 29.1 12/01/17 13:22:58.0 12/01/17 13:25:14.0 222655 136 19.5 12/01/17 13:22:59.0 12/01/17 13:25:15.0 0055CF 136 19.5 12/01/17 13:24:16.0 12/01/17 13:25:50.0 59D7E7 94 28.2 12/01/17 13:26:26.0 12/01/17 13:28:51.0 D154A9 145 18.3 12/01/17 13:28:30.0 12/01/17 13:30:55.0 89B8A1 145 18.3 12/01/17 13:28:59.0 12/01/17 13:31:33.0 B6C049 154 17.2 SYSTEM NEEDS FOR PERFORMANCE MEASURES 129
4.2.5 PROBE VEHICLE SEGMENT SPEED DATA DESCRIPTION The data are derived from analysis of individual probe vehicles, but the data are anonymized by converting individual vehicle positions into average segment speeds. The data are provided as speed records per segment over a specified time period (e.g., 1 minute, 5 minutes, 15 minutes). This process requires that practitioners index shapefiles describing the roadway segments by route and direction. The data quality is generally reliable on freeway routes, and its use on signalized arterials has been increasing. REQUIREMENTS COMMUNICATION ⢠Requires a contract with a data provider for delivery of the data, which can be in an archived format for past data or real-time through web-based polling. DETECTION DATA LOGGING ⢠State agencies may also be eligible to use the National Performance Measure Research Data Set (NPMRDS) at no cost. DATA STORAGE ⢠Either a server or cloud-based solution is required to store the data. SOFTWARE ⢠Software is needed to process the relevant data into performance measures. ⢠Route definitions are typically needed to make the best use of the data, which may necessitate the availability of GIS software to be able to view shapefiles and interpret the meaning of segment IDs. AVAILABILITY ⢠Available through private-sector vendors. ⢠Available through the National Performance Measure Research Data Set. CAPABILITIES ⢠The data can provide 24/7 coverage of the entire roadway network without the agency needing to install field equipment. ⢠Data are available both in real-time and for past performance (potentially going back several years). CHALLENGES ⢠The data are constrained by the segment definitions used by the data provider, which may not align with segments of interest to the agency. ⢠The data are provided as averages. Although it is possible to take the average of many different time periods to develop a distribution, the full degree of variation within a small time period may not be available. EXAMPLE DATA NPMRDS Segment Speeds TMC TIMESTAMP SPEED (MPH) AVERAGE SPEED (MPH) REFERENCE SPEED (MPH) TRAVEL TIME (MIN) 110N04178 09/01/14 0:00 72 57 67 0.82 110N04179 09/01/14 0:00 89 59 67 0.61 110-04175 09/01/14 0:00 61 53 65 1.51 110-04176 09/01/14 0:00 62 57 68 0.48 110-04177 09/01/14 0:00 63 59 67 1.05 110-04178 09/01/14 0:00 72 57 67 0.83 110-04179 09/01/14 0:00 89 59 67 0.24 110N04175 09/01/14 0:00 61 53 65 0.54 110N04176 09/01/14 0:00 62 57 68 0.83 110N04177 09/01/14 0:00 63 59 67 0.07 130 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
4.2.6 AUTOMATED VEHICLE LOCATION (AVL) DATA DESCRIPTION Automated vehicle location (AVL) data consist of timestamped GPS coordinates of probe vehicles that are recorded as they move through a roadway network. It is also possible to collect this type of data for bicycles and pedestrians. GPS data have been used for years in floating-car studies, but the number of available data points was typically low because of the cost associated with manual data collection. Over time, some agencies equipped fleet vehicles (such as buses) with GPS units, which reduced costs. In more recent years, AVL data have become âcrowd-sourced,â with participants âopting inâ to provide data through the use of navigation devices or apps on cell phones. In the transportation sector, that data can yield valuable information about roadway performance, and a few private companies are beginning to make the data available after they gather, clean, and anonymize it. In the future, it is likely that similar data will be available from connected vehicles (CVs) (see Section 4.2.7:Connected Vehicle (CV) Data). REQUIREMENTS COMMUNICATION AVL data can be obtained through: ⢠GPS devices installed on agency fleet vehicles. ⢠Purchasing data from private companies. ⢠Connected vehicles. At the time of writing, the number of CVs on the roadway remains small but is expected to increase in the future. DETECTION DATA LOGGING DATA STORAGE ⢠Either a server or cloud-based solution is required to store the data. SOFTWARE ⢠Software is needed to process the relevant data into performance measures. AVAILABILITY ⢠Available through private-sector vendors. CAPABILITIES ⢠No field infrastructure is required to collect the data. ⢠There is a potential for highly detailed analysis of individual movements. CHALLENGES ⢠A map-matching process is required to extract useful information about the performance of individual movements. ⢠Sample rates are currently low (about 1% or less of traffic volumes). ⢠Complex geometries, such as where bridges occur, may be difficult to analyze. ⢠Concerns over privacy remain to be resolved for this type of data. EXAMPLE DATA Timestamped Position Records EXHIBIT 4-3 shows southbound trajectories along an arterial route that were recorded in 2015 by a private- sector data provider. Each point represents a timestamped position record. Some traces have a higher density of points than others, indicating that the reporting intervals among vehicles differ. EXHIBIT 4-3. AUTOMATED VEHICLE LOCATION (AVL) DATA EXAMPLE: TIMESTAMPED VEHICLE LOCATION DATA OBTAINED FROM A PRIVATE-SECTOR VENDOR (DAY ET AL. 2016) Vehicle Location Data for Individual Probe Vehicles Can Be Converted into Trajectories Some Vehicles Report Their Position More Frequently Than Others SYSTEM NEEDS FOR PERFORMANCE MEASURES 131
4.2.7 CONNECTED VEHICLE (CV) DATA DESCRIPTION These data are defined by the SAE J2735 standard, which describes several data streams that will allow vehicles and infrastructure to communicate. These data streams include: ⢠Basic Safety Messages (BSMs) used by vehicles to communicate their position and other information about driving behavior. ⢠Signal Phase and Timing (SPaT) messages broadcast by infrastructure, so that nearby CVs will know the current signal state and anticipated future signal state. ⢠Traveler information messages are also expected to be included in the future. CV data contain more information about vehicle characteristics than AVL data; however, it is not clear whether CV data will be traceable through multiple intersections due to privacy concerns. Predictions vary as to when a sufficient percentage of the vehicle fleet will have onboard equipment to communicate with roadside infrastructure and other vehicles. In the United States, connected vehicle pilot programs have entered their second phase and some vehicle manufacturers have begun to include connected vehicle capabilities in new models. REQUIREMENTS COMMUNICATION ⢠Dedicated short range communication (DSRC) transceivers are required for communication between infrastructure and CVs. ⢠Other types of communication (such as cellular networks) may also be available for CV use in the future. DETECTION ⢠None. DATA LOGGING ⢠Additional hardware and software is typically required for signal controllers to interface with DSRC equipment for broadcasting SPaT messages and receiving BSMs. DATA STORAGE ⢠Either a server or cloud-based solution is required to store the data. SOFTWARE ⢠Software is needed to process the relevant data into performance measures. AVAILABILITY ⢠The equipment for DSRC is readily available. At the time of writing, the âSPaT Challengeâ is encouraging state DOTs to invest in this infrastructure and a few vehicle models have DSRC equipment installed. ⢠Other types of communication (such as cellular networks) may be available in the future for CV use. CAPABILITIES ⢠Extremely detailed information (beyond vehicle position) can be extracted from connected vehicles. ⢠The data will be available in real time, so could potentially be used for signal control applications. CHALLENGES ⢠A significant amount of map-matching is required to make use of the data. ⢠The number of vehicles deployed with the necessary equipment is currently low. ⢠A significant amount of infrastructure may need to be deployed to obtain the data. ⢠Concerns over privacy remain to be resolved for this type of data. EXAMPLE DATA Connected Vehicle Data EXHIBIT 4-4 presents charts that are taken from the U.S. DOT Safety Pilot Model Deployment. The data show a 100-second sample. Each chart contains 10,000 points that arise from the 1/10-second reporting interval. Detailed information about the vehicle heading and steering activity are seen in EXHIBIT 4-4A and EXHIBIT 4-4B. The vehicle position at each point is recorded by its latitude and longitude information, as reported in EXHIBIT 4-4C and EXHIBIT 4-4D. Data from onboard vehicle sensors are also available, as shown in EXHIBIT 4-4E and EXHIBIT 4-4F, which show the measured distance from the vehicle centerline to the left and right sides of the roadway. 132 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
EXHIBIT 4-4. CONNECTED VEHICLE DATA EXAMPLE: VEHICLE POSITION IN THE LANE (U.S. DOT 2015) (A) Vehicle heading, from GPS (C) Latitude, from GPS (E) Distance from vehicle centerline to left side of road (B) Position of steering wheel (D) Longitude, from GPS (F) Distance from vehicle centerline to right side of road SYSTEM NEEDS FOR PERFORMANCE MEASURES 133
4.3 TECHNICAL REQUIREMENTS This section focuses on the technical requirements for ATSPM systems, as summarized in EXHIBIT 4-5. In some places, the current infrastructure may already be able to support ATSPMs with marginal investments. In addition to upfront costs for intersection and system components, an agency should be aware that use of ATSPMs may result in an increased number of work orders. Malfunctioning equipment that would previously have gone unnoticed until there was a public service request will be highlighted more quickly by ATSPMs. EXHIBIT 4-5. ATSPM SYSTEM COMPONENT DESCRIPTIONS SYSTEM COMPONENTS & OPTIONS DESCRIPTION Communication Connection between field devices and central office required for automated data collection. Detection Equipment used to detect presence of roadway users required for many signal performance measures. Data Logging High-Resolution Data Traffic signal controller with onboard data logger or external data collection unit. Other Data Source Vendor-specific equipment. Data Storage Hardware Servers for hosting and workstations/laptops for accessing applications, services, and data. Cloud Server hosted by private-sector vendor with cloud access. Software Operating System Software Required for basic operation of server hardware. Database Software Required for storing and managing data. ATSPM System Software Required to convert data stored in a database into signal performance measures. Central System Software Some vendors have ATSPM capabilities through modules that can be added onto base software. 134 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
4.3.1 LEVERAGING EXISTING EQUIPMENT The current capabilities of existing systems vary widely from one agency to another depending on the amount of resources that have been invested over time as well as how recently those investments were made. Every agency is unique and may face challenges in procurement, operation, or maintenance of new equipment. The following list outlines opportunities to leverage existing equipment for ATSPMs. Communication. Many existing traffic signal systems have some type of communication available for remote access. Although there are still older types of communication in use, improvements in technology and reductions in cost have made higher-bandwidth network communication (necessary for ATSPMs) more feasible for agencies to install. Alternatives to wired communication include cellular modems and point-to-point wireless bridge technology. Detection. Detection systems are not strictly required for ATSPMs, but a large portion of the available metrics compare detector actuations to controller events. Most existing detection systems can be leveraged for high-resolution data. However, some modifications to existing configurations may be desirable (Day et al. 2017), as discussed in Section 4.3.3: Detection Requirements. Cabinets. Most existing cabinets can support equipment for data collection. Cabinet upgrades are unlikely to be necessary in most cases. Data logging. Many existing controllers can support collection of high-resolution data. Some agencies may already possess controllers with this functionality, perhaps only requiring a firmware upgrade. An alternative to a controller-based data logger is an external data collection unit. Data storage. Agencies may be able to repurpose an old server that was previously used for another function (e.g., video camera system). Rather than decommissioning the server, it could be used for data collection. 4.3.2 COMMUNICATION REQUIREMENTS Communication to field devices is necessary for automated data collection. The cost for communication can vary significantly depending on the desired latency and speed. The following are some considerations for an agency deciding whether to upgrade communication: ⢠Will the communication system be used for other purposes? ⢠Will data be stored locally and transmitted in batches or will it be measured in real time by polling? ⢠How often should data be updated? ⢠Is intermittent downtime acceptable? If the communication system will be used for traffic control purposes in addition to ATSPMs, it may be desirable to make a bigger investment in the system. However, different types of signal control have different requirements. For example, clock updates for a coordinated system do not require high-speed communication, but adaptive control, traffic responsive control, and video require reliable, low-latency, high- speed communication. Polling (particularly NTCIP-polling) can consume significant bandwidth and requires communication with little downtime. Many NTCIP âgetâ statements will need to be transmitted each second to every intersection. The advantage of polling is that no ânewâ processes necessarily need to be created; polling already exists as a central system function for retrieving real-time intersection status. High-resolution data can also be stored in a cache locally and transmitted in packets. Data can be downloaded frequently (e.g., once every few minutes) or less frequently (e.g., once a day in the overnight hours). It is possible for different intersections to be harvested at different rates and for downloads of current data to be triggered manually during critical times. SYSTEM NEEDS FOR PERFORMANCE MEASURES 135
At a minimum, each subnetwork of traffic signal controllers should have one link to the central office to facilitate data transfer (Makovejs 2012). Options for connecting between intersections and to the central office include the following communication types: Fiber-optic communication, which typically has the lowest latency (with speeds up to 8.8 terabits per second, Tbps, of bidirectional capacity per each fiber pair). Fiber communication systems require fiber transceivers, cabling and cable deployment, and aggregation cabinets to collect and distribute the fiber. Point-to-point wireless bridging (i.e., broadband radios), which can be used where clear lines of sight are available between connection points. Internet-based options (i.e., Wi-Fi and serial Ethernet), which may also be used to connect intersections. EXHIBIT 4-6. EXAMPLE NETWORK ARCHITECTURE USING DIFFERENT COMMUNICATION METHODS (DAY ET AL. 2016) Commercial cellular communication, which can provide adequate bandwidth without extensive infrastructure. Legacy systems, such as Digital Subscriber Lines (DSL) and dial-up via telephone, which will require investigation for available bandwidth. For corridors or networks with a large number of intersections or intersections that are spread out over long distances, a combination of technologies may be used. For example, some architectures leverage localized fiber running along an arterial but use a cellular modem from one of the cabinets to connect to the central office. Architecture details vary by agency, but EXHIBIT 4-6 shows one example diagram of a hybrid network that uses a combination of fiber and broadband radio communication. 136 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
If communication to a central office is not possible (and the agency wants more data than can be stored on the controller), the agency can use an embedded personal computer (PC) to cache ATSPM data. A memory capacity of a few gigabytes (GB) is capable of storing many years of raw ATSPM data for an intersection, which allows infrequent visits to the cabinet for data download. Options for data storage include flash memory cards and Raspberry Pi devices (see the example in EXHIBIT 4-7). There are also external processors that can serve a dual purpose, storing data and maintaining clock synchronization using GPS time sets. Embedded PC Storing Data Generated by Traffic Signal Controller ⢠In the simplest case, a detection system might use exactly one detector channel per phase. All the detectors associated with a particular phase (regardless of which lane they are in or their position in that lane) are brought together on one channel. This task can be accomplished by splicing inductive loop wires together or extending above-ground detection zones across multiple lanes. This configuration uses the minimum number of detector channels, but all actuation information will be aggregated. ⢠In a moderately comprehensive configuration, a detection system may use a few different channels for each phase. For example, the advance detectors may be on their own channel, while the rest of the detectors for that phase are on another channel. This type of configuration may be employed where an agency wants more information about the presence of vehicles but has limited space in the cabinet for additional detector cards. There are two common ways agencies reduce the number of detector channels in use: (1) tying together advance and stop bar detectors in a lane and (2) tying together detectors across multiple lanes. EXHIBIT 4-7. EXAMPLE EMBEDDED PC USED TO COLLECT ATSPM DATA (COURTESY HOWELL LI, PURDUE UNIVERSITY) 4.3.3 DETECTION REQUIREMENTS DETECTOR LAYOUT Although detection is not an absolute requirement for signal performance measures, more metrics can be derived from high-resolution data if detection is in place. Detector configurations vary widely depending on agency practices, the type of detection technology, and site characteristics. No particular detector configuration or type is preferred for ATSPMs provided it is accurate and reliable. SYSTEM NEEDS FOR PERFORMANCE MEASURES 137
Advance and stop bar detectors that are tied together in a lane will not work for ATSPMs. If advance and stop bar detectors are tied together in a lane, they will need to be separated onto different detector channels to collect data for ATSPM reports. Detectors that are tied together across multiple lanes (i.e., all advance detectors on an approach are tied together or all stop bar detectors on an approach are tied together) will work for ATSPMs without having to make adjustments. However, the data will be more aggregated than if detectors are on separate lane-by-lane channels. ⢠In the most comprehensive configuration, every lane has its own detectors reporting calls on their own channels. This type of configuration requires a large number of detector channels, particularly at intersections with many lanes, but it provides the most accurate data and is necessary for some metrics such as turning movement counts. The more lanes a detection zone spans, the more aggregated the data. Data aggregation can cause occupancy to appear saturated at lower levels of traffic and vehicle arrival information to be less accurate. It is not necessary to use the most comprehensive detector configuration, but in some cases, it may be desirable to adjust the existing detector configuration to report specific ATSPMs. Detector count data (whether collected through high-resolution data or other means) may require specific types of detection equipment to support the required number of channels. Although other types of detection can be tied together, count detection requires individual detector channels for each count detector to collect accurate counts (ITE 2008). In addition to how detectors are tied together, their locations impact the ATSPMs that can be reported. EXHIBIT 4-8 summarizes the metrics that can be obtained from different detector locations (illustrated in EXHIBIT 4-9). Note that a handful of metrics are available even if no detection is available. Without detection, an intersection will operate as a fixed-time intersection, but it is possible to identify anomalies in the programmed signal timing using ATSPMs. If detector mapping is not readily available (i.e., unmapped detection), it is possible to examine some metrics by phase. For example, the number of gap-outs versus max-outs and force-offs can be determined without knowing which detectors belong to which lanes and phases. However, a greater number of metrics become available with detector mapping information (Smaglik, Bullock, and Urbanik 2005; Smaglik et al. 2007). Certain types of detection allow practitioners to be selective about the vehicle actuations that are reported to the ATSPM system. For example, detection zones near (or just past) the stop bar may be used to track yellow/red actuations (see Section 3.16: Yellow/Red Actuations), and if a speed setting is applied, vehicles that are stopped or decelerating will not be reported. In this case, only vehicles traveling over a certain speed and likely to enter the intersection during the yellow or red intervals will be added to the Yellow/Red Actuation report.â 138 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
EXHIBIT 4-8. DETECTION REQUIREMENTS FOR SIGNAL PERFORMANCE MEASURES TYPE OF DETECTION AVAILABLE SIGNAL PERFORMANCE MEASURES None ⢠3.1 Communication Status ⢠3.2 Flash Status ⢠3.3 Power Failures ⢠3.18 Effective Cycle Length (7) ⢠3.24 Time-Space Diagram Unmapped Detection ⢠3.4 Detection System Status (1) ⢠3.6 Phase Termination ⢠3.7 Split Monitor ⢠3.13 Pedestrian Phase Actuation and Service ⢠3.14 Estimated Pedestrian Delay ⢠3.25 Preemption Details ⢠3.26 Priority Details Mapped Detection Lane-by-Lane: Each Detector Mapped to Its Own Channel or Multi-Lane: Multiple Detectors Tied Together Across Lanes Stop Bar Presence ⢠3.8 Split Failures ⢠3.9 Estimated Vehicle Delay ⢠3.10 Estimated Queue Length ⢠3.17 Red-Light Running (RLR) Occurrences ⢠3.23 Travel Time and Average Speed (8) Stop Bar Count ⢠3.5 Vehicle Volumes ⢠3.8 Split Failures (2) ⢠3.9 Estimated Vehicle Delay (3) ⢠3.15 Estimated Pedestrian Conflicts ⢠3.16 Yellow/Red Actuations ⢠3.23 Travel Time and Average Speed (8) Advance ⢠3.5 Vehicle Volumes ⢠3.8 Split Failures (2) ⢠3.9 Estimated Vehicle Delay (3) ⢠3.10 Estimated Queue Length ⢠3.11 Oversaturation Severity Index ⢠3.19 Progression Quality ⢠3.20 Purdue Coordination Diagram ⢠3.21 Cyclic Flow Profile ⢠3.22 Offset Adjustment Diagram ⢠3.23 Travel Time and Average Speed (8) Special Detection AVI / AVL ⢠3.9 Estimated Vehicle Delay (4) ⢠3.10 Estimated Queue Length (5) ⢠3.24 Time-Space Diagram (9) Pedestrian ⢠3.12 Pedestrian Volumes ⢠3.15 Estimated Pedestrian Conflicts Speed ⢠3.16 Yellow/Red Actuations (6) ⢠3.23 Travel Time and Average Speed (1) Although some detection alarms do not require detection to be mapped, the most useful metrics will report status on specific detectors. (2) Stop bar count and advance detection can be used to calculate volume-to-capacity ratios. (3) Stop bar count and advance detection can be used to count vehicles for use in the HCM delay equation. Advance detection can also be used in arrival and departure models and to estimate time to service (with an adjustment to account for travel time to the stop bar). (4) AVI/AVL data can be used to estimate delay using a travel time ârouteâ that covers only one signalized movement. (5) AVL data can be used to measure queues if the data are available at a high enough penetration rate. (6) Some detection technologies allow actuations to be recorded only if vehicles are traveling over a specific speed. (7) No detection is required, but without detection, cycle lengths will remain constant. (8) Stop bar presence, stop bar count, and advance detection can be used to calculate Estimated Vehicle Delay, which can be aggregated to estimate travel time. (9) AVL data can be used to overlay vehicle trajectories. SYSTEM NEEDS FOR PERFORMANCE MEASURES 139
EXHIBIT 4-9. EXAMPLE DETECTION LOCATIONS Note: Adapted from âUDOT Automated Traffic Signal Performance Measuresâ (Mackey 2017). DETECTOR CHANNEL MAPPING For many signal performance measures, it is important for detection to be âmappedâ so that the agency knows how detector channels are tied to lanes and phases. To fully describe an event, the following information is needed for the detection zone associated with each detector channel: ⢠Distance from the stop bar (i.e., advance, stop bar, past the stop bar) ⢠Type of wiring (i.e., lane-by-lane, multi- lane) ⢠Type of detection (i.e., presence, count) ⢠Approach (i.e., north, south, west, east) ⢠Lane group (i.e., left, through, right) ⢠Associated phase or overlap EXHIBIT 4-10 shows example detector mapping information. The table links detector channels to lanes, movements (i.e., lane groups), and controlling phases. Presence Advance Count Advance Speed Stop Bar Count Exit Count Yellow & Red Actuation 140 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
EXHIBIT 4-10. EXAMPLE DETECTOR MAPPING INFORMATION APPROACH LANE GROUP LANE PHASE CONTROL TYPE PRESENCE CHANNEL COUNT CHANNEL DISTANCE FROM STOP BAR (FEET) APPROACH SPEED (MPH) NB Left - 5 Protected 17 19 0 55 NB Thru 1 (Inside) 2 Protected 18 20 100 55 NB Thru 1 (Inside) 2 Protected 39 - 365 55 NB Thru 2 (Outside) 2 Protected 21 23 100 55 NB Thru 2 (Outside) 2 Protected 40 - 365 55 NB Right - 2 Permitted 22 24 100 55 There are several places where detector mapping information may be available. If documentation is not readily available or no longer reflects field conditions, agencies can send staff into the field to confirm detector mapping. ⢠As-built drawings. Equipment layout and wiring diagrams are often included as part of as-built drawings (such as the example in EXHIBIT 4-11). A practitioner should conduct a field visit if the plans have aged and are no longer likely to represent actual conditions. ⢠Signal timing sheets. Practitioners can configure detector channels in the signal controller to call and/or extend specific phases. Although the signal timing sheets will not provide location information, they may help to clarify the phases and overlaps associated with detector channels. ⢠Asset management system. Some agencies may keep records of detection in an asset management system such as a Geographic Information Systems (GIS) database. ⢠Cabinet labeling. Detector racks in the cabinet may directly interface with physical detection; these may be âtaggedâ with information about the detectors (such as the example in EXHIBIT 4-12). ⢠Detection software. Detector rack units may provide input directly to the controller through the SDLC bus or some other interface. The detection zones (e.g., for video or radar systems) might be configured through a software interface that can provide the necessary information. SYSTEM NEEDS FOR PERFORMANCE MEASURES 141
EXHIBIT 4-11. EXAMPLE AS-BUILT DRAWING (COURTESY INDIANA DEPARTMENT OF TRANSPORTATION) Detector Channel Information Detector Location Information Detector Channel Labels EXHIBIT 4-12. EXAMPLE DETECTOR RACK WITH LABELING FOR DETECTOR CHANNELS (COURTESY INDIANA DEPARTMENT OF TRANSPORTATION) 142 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
4.3.4 DATA LOGGING REQUIREMENTS HIGH-RESOLUTION DATA Several options exist for obtaining high- resolution data. All require that the IP address of the data logger be available so that data can be organized using an identifier. The most âcompleteâ set of data will come from a data logger internal to a traffic signal controller. While external data collection units can record detection inputs and signal display outputs, a traffic signal controller can also record control parameters such as next phase decisions and phase termination types. Several controller manufacturers have implemented the ATSPM data-logging feature in at least one controller model compatible with the NEMA TS/2 Type 1 and Type 2, ATC 170 and 2070 cabinet standards. If an agency installs new controllers to collect ATSPM data, signal timing from the old controllers will need to be converted. For more information on programming signal timing parameters, refer to NCHRP Report 812: Signal Timing Manual, 2nd ed. (STM2) (Urbanik et al. 2015). It may be possible to collect high-resolution data using some older controller models through firmware upgrades or hardware upgrades (e.g., through installation of a new central processing unit, CPU). The data- logging feature may need to be enabled (through the front panel or an NTCIP setting), as this may not be the default setting. An agency should check that the data-logging feature remains active as part of regular maintenance (e.g., after a power loss). Where controller upgrades are not feasible, an alternative would be to use an external data collection unit. There are now several vendors that have made such units commercially available. Although some events might not be captured, the data from an external unit will support most of the existing signal performance measures. Another advantage is that the controller can be separated from the ATSPM process, which may be desirable to some agencies. Another alternative is to use NTCIP polling to obtain signal events. This method uses a central system to retrieve phase and detector states in real time. Because the event data are not cached, the events must be captured as they occur. This method requires a reliable, low-latency connection to the traffic signal controller because even 1 second of communication downtime could result in lost data. OTHER DATA SOURCES As discussed in Section 4.2: Data Sources, there are several data sources outside high- resolution data that can be used to produce ATSPMs. A few considerations relative to the field equipment required for those data sources are listed here: ⢠Certain data sets (such as probe data collected by private-sector vendors) do not require any agency-owned field infrastructure. However, an agency will likely need to secure server space (reference Section 4.3.5: Data Storage Requirements) and define the data to be provided (e.g., geographic extents and roadways). ⢠Vehicle identification data sources require sensors to be installed in the field with communication available to them. The sensors will need to be mapped to their geographic locations and routes in the network. ⢠Connected vehicle data requires a substantial investment in equipment to facilitate communication between vehicles and infrastructure. Those devices also need to have communication to a central office for full data collection capabilities. SYSTEM NEEDS FOR PERFORMANCE MEASURES 143
4.3.5 DATA STORAGE REQUIREMENTS HARDWARE Some physical components will need to be configured at a central office if an agency decides to use in-house equipment to facilitate the retrieval, processing, presentation, access, and archiving of the ATSPM data. Agencies can use a collection of one or more servers to host applications, services, and data pertaining to an ATSPM system. The three essential considerations for a server are processing power, the size of the memory, and the disk configuration. Agencies can emphasize different components based on their needs. ⢠Processing. Agencies will need a faster processor for performing computationally intensive operations, real-time data processing, or video processing. ⢠Memory. Agencies that serve many users simultaneously, host many different applications, and perform a large amount of in-memory operations will need multiple gigabytes (GB) or terabytes (TB) of memory. Approximately one megabyte (MB) of data per intersection per day is needed (Bullock et al. 2011). ⢠Disk configuration. Agencies that store a significant amount of data may need multiple disks in a redundant array with backups. For large systems, the computational power can be distributed over multiple servers, such as with the Hadoop Distributed File System (HDFS). Depending on the server hardware, some systems may also require the additional purchase of racks and rack mounting hardware, cooling systems, power backups, and other supporting components. In addition to servers, agencies may need to configure workstations or laptops to make use of the ATSPM platform applications and hosted services. For example, an analyst may use client software on a laptop to connect to a server database. CLOUD The alternative to an agency procuring their own server(s) is to use a cloud-based system with a vendor hosting the server(s). These solutions are typically subscription-based. 4.3.6 SOFTWARE REQUIREMENTS OPERATING SYSTEM SOFTWARE Operating system (OS) software is essential for the basic operation of server hardware. Windows and Linux-based platforms are the two most common types of server OS. ⢠Windows OS requires commercial licensing. Agencies that operate many servers can often purchase licenses in bulk. ⢠Linux OS comes in both freely available open source distributions and commercially licensed platforms. When selecting an OS, agencies should consider ATSPM software compatibility, software dependencies, user authentication and security, and technical support options. Additionally, agencies should install anti- virus software with the OS to provide protection from viruses and malware. OS installation is typically completed by IT staff, consultants, or the server manufacturer prior to delivery of the hardware. DATABASE SOFTWARE There are many options available when selecting database software for storing and managing ATSPM data. ⢠Relational Database Management Systems (RDBMS) are popular for storing data in tabular formats similar to a spreadsheet organized using individual tables. Popular RDBMS software includes Microsoft SQL Server, PostgreSQL, and MySQL. Each has different features, capacities, and costs. 144 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
⢠NoSQL varieties, such as MongoDB, which store documents using dynamic schemas. ⢠Cassandra, which is highly scalable and uses a hybrid key-value and column-store architecture. Although there are many options, it is important to consider the ATSPM software requirements as well as the workflow of the organization. Agencies can use more than one type of database software at different points in the lifecycle of the ATSPM data. For example, it may be beneficial for newer, more-frequently accessed data to operate on a highly optimized RDBMS while older data are stored as compressed flat files. ATSPM SYSTEM SOFTWARE ATSPM system software is used to convert data stored in a database into signal performance measures. Some software may have settings that need to be configured during initial set-up. For example, regions may need to be defined for intersection organization or user roles may need to be defined for administrative capabilities. ⢠Open source software. FHWA made an open source application developed by the Utah Department of Transportation (UDOT) available on its Open Source Application Development Portal (OSADP), and UDOT maintains a version on GitHub that allows developers to track their changes. Practitioners can download the application and install it at no cost. This option gives agencies the greatest flexibility to customize reports and features. ⢠Agency-developed software. Various research institutions and agencies, such as the University of Minnesota/Minnesota Department of Transportation (MnDOT), Purdue University/Indiana Department of Transportation (INDOT), and Colorado Springs, have developed their own ATSPM systems over the years. ⢠Vendor-developed software. More recently, vendors have incorporated ATSPM modules into their software for reporting and analytics. Available metrics and functionalities vary by vendor. There are typically annual subscription-based licensing fees, but implementation costs may be less than other options because of vendor-supplied data storage. CENTRAL SYSTEM SOFTWARE Central system software can potentially provide mechanisms for collecting, displaying, and archiving ATSPM data. In some cases, these implementations will need to have compatible equipment in the field to make use of the features at the central office. At present, several vendors offer central system products that include ATSPM capabilities, typically as âadd-onâ modules to the base software. 4.3.7 NETWORK SECURITY There are two types of security that should be addressed in a traffic signal system (often requiring coordination with IT staff): ⢠Physical security for cabinets, server rooms, and offices where workstations and laptops reside. ⢠Network security for routers, switches, and wireless networks. In order for the central office hardware to retrieve ATSPM data from the field, the devices must have some type of network connectivity to the intersections. Agencies with dedicated communications infrastructure (such as fiber networks out to each cabinet) have the benefit of being able to operate within the agencyâs intranet. Networks that rely on some type of commercially operated connection in the communications chain (such as a cellular network between the intersections and central office) typically have data transferred through the internet. In those cases, Virtual Private Networks (VPNs) are often used for virtually incorporating networks in the field into the central office network. VPNs use encryption algorithms that are provided by dedicated VPN routers, built into a cellular modem, or configured as a software option. Common encryption protocols include: SYSTEM NEEDS FOR PERFORMANCE MEASURES 145
⢠Point-to-Point Tunneling Protocol (PPTP) ⢠Layer 2 Tunneling Protocol (L2TP) ⢠Internet Protocol Security (IPSec) ⢠Secure Socket Tunneling Protocol (SSTP) ⢠Internet Key Exchange version 2 (IKEv2) ⢠OpenVPN, which employs the OpenSSL library ⢠Transport Layer Security (TLS) methods Practitioners can leverage software configurations to provide further layers of security. One example is setting up or using an existing user authentication protocol to provide limited access to certain types of data or user interfaces. Other methods include further dividing the intranet into subnetworks where more sensitive devices such as controllers and signal monitors are obscured to a user with non-elevated credentials. 4.4 DATA MANAGEMENT ATSPM data will go through the following lifecycle between initial collection and interpretation. Keeping all the raw data is not the most efficient use of storage space or processing power, so this section describes steps that can be taken to manage data between downloading it and displaying it as actionable information. Download unprocessed data from a data logger to the central office. Normalize unprocessed data (potentially from different sources) into a uniform, consistent, and efficient format. Store unprocessed or normalized data in a database. Process data using logic, algorithms, and heuristics. Display processed data using charts, graphs, tables, maps, and text reports. 4.4.1 DATABASE STRATEGIES Depending on the ATSPM software that is used, there may be differences in how data are stored. ATSPM databases can fill up quickly. Several basic database management strategies are suitable for large data sets. ⢠Data types. Select an appropriate data type for each data field to improve performance and reduce data size. For example, a field that contains only integers between 0 and 255 can be stored as a 1-byte integer instead of a string. ⢠Compression. Data compression reduces the amount of space needed on the server and improves query response times. Types of compression features vary amongst database software. ⢠Clustering and indexing. Queries can be faster if data are organized or "clustered" according to the most critical fields (i.e., fields consistently used for filtering clauses). Creating non-clustered indices on frequently queried columns will add further performance benefits (although at the cost of additional storage consumption). ⢠Partitioning. Large, homogeneous data sets, such as those contained in a single data table, can be subdivided or "partitioned" into separate data sets for improved performance and management flexibility. Depending on the database software, practitioners can use different partitioning methods. For example, in a relational database, practitioners can partition a single data table that spans several years into monthly partitions, back up the older partitions onto tape, and remove them from the main database. 146 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
4.4.2 DATA ARCHIVING Moving older data to an archive (i.e., through a logical or physical separation) can limit the size and improve the efficiency of an ATSPM system. An archival process moves data from an active or âhotâ system where users and programs can retrieve it quickly to an archive or âcoldâ system with lower priority access. In most cases, practitioners may need to process archived data to make it useful again. ⢠Logical separation keeps the data on the same physical medium (i.e., an array of hard drives) but separates the data using different software containers and pointers within the medium. ⢠Physical separation copies the data to a different medium. This can be on the same server (i.e., different array of hard drives on the same server), a different server, or in the cloud. The amount of time to keep records âactiveâ depends on how often and far back an agency requires access to archived data as well as storage constraints. For systems that have few intersections, it may be feasible to keep many years of data in both active and archive systems. For larger systems, practitioners may only be able to keep a few months of data active and maintain up to 2 years of archives. 4.4.3 DATA AGGREGATION Practitioners can convert raw data into aggregated metrics for quicker queries. Aggregated metrics consume less storage space than raw data because certain temporal and spatial attributes are combined for greater efficiency. For example, practitioners might use aggregation for the following data. ⢠Convert detector on and off events into occupancy events, reducing the number of detection records by half. ⢠If there are stop bar detectors in multiple lanes, only keep the highest occupancy ratio for split failure calculations. ⢠Bin metrics into time intervals (e.g., 5, 10, 15 minutes) by summing the number of occurrences. 4.5 CONSIDERATIONS FOR ATSPM SYSTEM SELECTION 4.5.1 USER INTERFACES There are three major types of user interfaces that can display ATSPM data: web-based, mobile, and desktop applications. A greater number of users can generally gain access through web-based and mobile applications than if a desktop application is used. Web-based and mobile applications can be open (for public access) or restricted (for agency-only access). Restricted access will require user accounts, but data scrubbing will not be as critical. Tools such as Google Analytics can be used to track times and pages being accessed, so that information can be tailored to the most- frequent users. ⢠Desktop applications are typically installed on a per-workstation basis and activated by licensing systems or a product key. ⢠Web-based applications are run on a server and accessed by users over the internet (or alternately within an intranet on a private network) through a web browser on a computer. ⢠Mobile applications function on a mobile device (i.e., cell phone or tablet) either through a web browser or a standalone app. SYSTEM NEEDS FOR PERFORMANCE MEASURES 147
4.5.2 DATA EXPORTING Many ATSPM systems have some capability to export data either into a flat file such as a comma-separated values (CSV) file or into tables and charts. These features typically require a small amount of configuration for the format of the exported data and which ATSPM elements will be included in the output. 4.5.3 ALERTS AND THRESHOLDS Parameters can be defined in an ATSPM system to alert users of performance issues via email or text message. User roles can be defined so that different groups receive different types or categories of alerts; roles may be defined by staff responsibilities or geographic boundaries. For each alert, specific performance measure thresholds (discussed in Chapter 5) should be established to determine when alerts are sent. 4.5.4 SYSTEM REPORTS ATSPMs can provide insights into how a system is performing for a given time period. It is important to understand how ATSPM information will ultimately be used, so that customized reports can be developed that are appropriate for different groups. For example, a field engineer may want a report for traffic signals in his or her district that contains detailed split failure information, volumes, and progression percentages, while an operations manager may only want a performance index for percentage of signals communicating. 4.5.5 INTEGRATION WITH EXISTING SYSTEMS An ATSPM system may need to interface with multiple existing agency systems. ⢠Many agencies have existing user account systems to grant login and access privileges. ⢠Existing asset management systems and GIS can reduce some of the upfront configuration efforts for ATSPMs, such as by providing the latitude and longitude for each intersection. ⢠Other external systems such as weather service, automatic vehicle location, connected vehicle systems, and probe data systems can be complementary to ATSPM data. 4.5.6 COORDINATION WITH IT STAFF Coordination with IT staff will be important, particularly for traffic signal groups that share communications infrastructure with other city services (e.g., police, fire). Managing traffic signal system components as network devices will likely be a new task for IT personnel and may require closer coordination than typical day-to-day interactions. 148 PERFORMANCE-BASED MANAGEMENT OF TRAFFIC SIGNALS
4.6 REFERENCES 1. Bullock, D.M., C.M. Day, T.M. Brennan, J.R. Sturdevant, and J.S. Wasson. 2011. âArchitecture for Active Management of Geographically Distributed Signal Systems.â ITE Journal, Vol. 81, Iss. 5, pp. 20-24. 2. Day, C.M., D.M. Bullock, H. Li, S.M. Lavrenz., W.B. Smith, and J.R. Sturdevant. 2016. Integrating Traffic Signal Performance Measures into Agency Business Processes. Purdue University, West Lafayette, IN. http:// dx.doi.org/10.5703/1288284316063 3. Day, C.M., H. Li, J.R. Sturdevant, and D.M. Bullock. 2017. âData-Driven Ranking of Coordinated Traffic Signal Systems for Maintenance and Retiming.â Presented at 96th Annual Meeting of the Transportation Research Board, Washington, DC, Paper No. 18-00115. 4. Institute of Transportation Engineers (ITE). 2008. Using Existing Loops at Signalized Intersections for Traffic Counts. 5. Mackey, J. 2017. âUDOT Automated Traffic Signal Performance Measures.â Presented at 2017 Train the Trainer Workshop, Salt Lake City, UT. 6. Makovejs, S. 2012. âWired or wireless?â South Asian Wireless Communications, pp. 23-24. 7. Smaglik, E., D. Bullock, and T. Urbanik. 2005. "Evaluation of lane-by-lane vehicle detection for actuated controllers serving multi-lane approaches." Transportation Research Record, No. 1925, pp. 123-133. 8. Smaglik E.J., D.M. Bullock, J.R. Sturdevant, and T. Urbanik. 2007. "Implementation of lane-by-lane detection at actuated controlled intersections." Transportation Research Record, No. 2035, pp 81-87. 9. 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, West Lafayette, IN. http://dx.doi.org/10.4231/K4RN35SH 10. Urbanik, T., et al. 2015. NCHRP Report 812: Signal Timing Manual, 2nd ed. Transportation Research Board of the National Academies, Washington, DC. 11. U.S. Department of Transportation (USDOT). 2015. Safety Pilot Model Deployment â Sample Data Environment Data Handbook. 12. Utah Department of Transportation (UDOT). (n.d.-a). Automated Traffic Signal Performance Measures website. http://udottraffic.utah.gov/atspm/ SYSTEM NEEDS FOR PERFORMANCE MEASURES 149
