Model Systems Engineering Documents for Central Traffic Signal Systems
Appendix A: Concept of Operations Table of Sample Statements
| ConOps Reference # | ConOps Sample Statements |
|---|---|
1 |
Scope |
1.1 |
Document Purpose and Scope |
1.1.1 |
The scope of this document covers the consideration of a Traffic Signal System (TSS) including Adaptive Signal Control Technology (ASCT) and Automated Traffic Signal Performance Monitoring (ATSPM) for use within (describe the agency and/or geographic area covered by this consideration). |
1.1.2 |
This document describes and provides a rationale for the expected operations of the proposed signal system. |
1.1.3 |
It documents the outcome of stakeholder discussions and consensus building that has been undertaken to ensure that the system that is implemented is operationally feasible and has the support of stakeholders. |
1.1.4 |
The intended audience of this document includes: system operators, administrators, decision-makers, elected officials, other nontechnical readers and other stakeholders who will share the operation of the system or be directly affected by it. (Edit list as appropriate) |
1.2 |
Project Purpose and Scope |
1.2.1 |
The purpose of providing a signal system is to overcome (describe why it is needed, such as to overcome specific deficiencies or limitations in the existing system). |
1.2.2 |
The purpose of providing adaptive control in this area is to overcome (describe why it is needed, such as to overcome specific deficiencies or limitations in the existing system). An adaptive traffic signal system is one in which some or all the signal timing parameters are modified in response to changes in the traffic conditions, in real time. |
1.2.3 |
The purpose of automated traffic signal performance measurement and monitoring is to validate and optimize how well single and multiple intersections are performing (describe specifics). |
1.2.4 |
This project will establish a new traffic signal system or replace the existing traffic signal system with a new one. |
1.2.5 |
This project will add adaptive capabilities to a new or existing coordinated signal system. |
1.2.6 |
This project will add performance monitoring capabilities to a new or existing coordinated traffic signal system. |
1.3 |
Procurement |
1.3.1 |
The traffic signal system will be procured using [Edit this or choose alternative statement]. |
1.3.2 |
.a combination of best value procurement for software and system integration services, and low-bid procurement for equipment and construction services. |
1.3.3 |
.a best value procurement process based on responses to a request for proposals. |
1.3.4 |
.a low-bid process based on detailed plans and technical specifications. |
1.3.5 |
A request for qualifications (RFQ) will be issued to all potential vendors. Responses will be used to develop a short list of suitable systems and a request for proposals (RFP) will be issued to those vendors. The selected system will be the one that provides the best value, subject to financial and schedule constraints. |
1.3.6 |
Field equipment (parts and labor) will be procured using a low-bid process based on detailed plans and technical specifications. |
1.3.7 |
A detailed procurement plan will be prepared after the system requirements have been determined. |
2 |
Referenced Documents |
2.1 |
The following documents have been used in the preparation of this Concept of Operations and stakeholder discussions. Some of these documents provide policy guidance for traffic signal operation in this area, some are standards with which the system must comply, while others report the conclusions of discussions, workshops and other research used to define the needs of the project and subsequently identify project requirements. |
2.2 |
References Specific to the Traffic Signal System Location
|
2.3 |
Systems Engineering
|
2.4 |
Adaptive Signals
|
2.5 |
Automated Traffic Signal Performance Measures
|
2.6 |
ITS, Operations, Architecture, Other
|
2.7 |
National Transportation Communications for Intelligent Transportation System Protocol (NTCIP)
|
2.8 |
National Electrical Manufacturers Association (NEMA)
|
2.9 |
PROCUREMENT
|
3 |
User-Oriented Operational Description |
3.1 |
The Existing System and Limitations of the Existing System [Explain how the lack of or inadequacy of traffic signal system is preventing achieving transportation management operational objectives. Describe the problem to be solved by deploying traffic signal system technologies.] |
3.1.1 |
Existing System |
3.1.1.1 |
The existing system architecture is illustrated in Figure XX. (Provide an appropriate system network block diagram and describe the following elements, as applicable.) – Traffic Management Center (TMC) and workstations -Local hubs, on-street masters, etc. - Communications infrastructure (e.g., fiber optic cable, twisted wire pair cable, dial up, cell, serial or Ethernet communications) - Detection locations and technology (e.g., video, loops or other technology) |
3.1.1.2 |
All of the traffic signals on the system are within the City limits and are connected to the existing signal system as illustrated in Figure XX. |
3.1.1.3 |
While all signals are relatively close, the traffic conditions and distances vary. The signals are in multiple coordination groups and some operate in free mode. |
3.1.1.4 |
The existing closed loop system consists of X signal groupings each with a master controller. |
3.1.1.5 |
The signal system includes traffic signals all over the state and not grouped into one location. |
3.1.1.6 |
The [Specify jurisdiction] is the only agency that will be accessing the traffic signal system. |
3.1.1.7 |
The traffic signal system will be accessed by [INSERT RELEVANT AGENCIES] and maintained by the City through an intergovernmental agreement. |
3.1.2 |
Limitations of the Existing System |
3.1.2.1 |
The following statements summarize the limitations of the existing system that prevent it from satisfactorily accommodating the agency's needs. [Select from the following samples and create new descriptions that fit your situation.] |
3.1.2.2 |
New traffic signal controllers and software were recently procured and the existing traffic signal system is not compatible with all of the features. |
3.1.2.3 |
The existing closed loop system doesn't provide continual real-time monitoring of the traffic signal network. |
3.1.2.4 |
The existing system is no longer supported by the vendor. |
3.1.2.5 |
The mapping interface capabilities are limited. It is difficult to quickly add a new intersection to the system. |
3.1.2.6 |
The alarm and flagging capabilities are limited. |
3.1.2.7 |
The existing traffic signal system doesn't support high resolution data for performance monitoring. |
3.1.2.8 |
The existing traffic signal system doesn't allow multiple agencies to be connected to the same system. |
3.1.2.9 |
The existing traffic signal system doesn't allow multiple users to view the same intersection simultaneously. |
3.1.2.10 |
The existing traffic signal system doesn't interface with other systems. |
3.1.2.11 |
The existing traffic signal system doesn't have a laptop version that can be used at remote locations not connected to the network. |
3.1.2.12 |
The user interface and display screens are old style, lack resolution, and do not clearly display sufficient data to efficiently support the operator. |
3.2 |
Vision, Goals, and Objectives for the Proposed System |
3.2.1 |
Traffic Signal System (TSS)/Adaptive Signal Control Technology (ASCT) Vision, Goals and Objectives |
3.2.1-1 |
The agencies vision, goals and objectives for the proposed TSS are: [extract a summary from relevant planning documents. If planning documents do not provide vision, goals and objectives for the role of traffic signal systems in transportation management, summarize that role here]. |
3.2.1.1 |
TSS/ASCT Vision The vision of a TSS is to support efficient operations and maintenance of a traffic signal infrastructure. |
3.2.1.1.1 |
The vision of the ASCT is to provide an advanced traffic control system that responds to changing traffic conditions, and reduces delays and corridor travel times, while balancing multimodal transportation needs. [Customize this statement to suit your situation.] |
3.2.1.2 |
TSS/ASCT Goals |
3.2.1.2.1 |
The goals of the TSS are: [Select from the following items and customize to suit your situation.] |
3.2.1.2.1.1 |
Support vehicle, pedestrian and transit traffic mobility. |
3.2.1.2.1.2 |
Provide measurable improvements in personal mobility |
3.2.1.2.1.3 |
Support interoperability between agencies |
3.2.1.2.1.4 |
Support regional systems |
3.2.1.2.1.5 |
Support congestion and environment policy objectives |
3.2.1.2.1.6 |
Meet a timely project implementation schedule Support the efficient maintenance of a state of good repair of the traffic signal infrastructure Support the agency's ability to provide good customer service related to traffic signal operation |
3.2.1.3 |
TSS/ASCT User Objectives |
3.2.1.3.1 |
The objectives of the TSS that support the stated goals are: [Select from the following items and customize to suite your situation.] |
3.2.1.3.1.1 |
To support vehicle, pedestrian and transit traffic mobility:
|
3.2.1.3.1.2 |
To support measurable improvements in personal mobility:
|
3.2.1.3.1.3 |
To support agency interoperability:
|
3.2.1.3.1.4 |
To support regional systems:
|
3.2.1.3.1.5 |
To support environmental objectives:
|
3.2.1.3.1.6 |
To support a timely schedule:
|
3.2.1.4 |
TSS Operational Objectives (These objectives are appropriate for all traffic signal systems, not all systems modify operations in real time to attain these objectives. In many systems, the operator is expected to attain these objectives when designing signal timings, and the system is expected to facilitate the installation, maintenance, and monitoring of those signal timings.) |
3.2.1.4.1 |
The operational objectives of the TSS will be to effect and demonstrate: [Select the samples appropriate to your situation] |
3.2.1.4.1.1 |
Smooth flow of traffic along coordinated routes, particularly in uncongested conditions |
3.2.1.4.1.2 |
Maximized throughput of traffic at bottleneck intersections, particularly in congested conditions |
3.2.1.4.1.3 |
Equitable distribution of green time at the intersection (which may be to appropriately serve adjacent land uses or specific intersection users) |
3.2.1.4.1.4 |
Managed queues, to prevent excessive queuing from reducing efficiency, particularly in congested conditions |
3.2.1.4.1.5 |
Appropriate control of operation using a combination of these objectives |
3.2.1.4.1.6 |
Appropriate selection of and response to objectives based on changing traffic conditions |
3.2.1.4.1.7 |
For a critical isolated intersection, maximized intersection efficiency. |
3.3 |
Strategies to be Applied by the Improved System |
3.3-1 |
This section describes in broad terms the improvements that are desirable in order to address the limitations described above. The main improvements that are desired are: [Select from the samples below and create new descriptions that suit your situation.] |
3.3.1 |
General Actors |
3.3.1-1 |
The general actors listed below represent the various roles and systems that interact with the Traffic Signal System (TSS). Each actor represents a role, a user can have multiple roles and there can be multiple for the same type of actor. For example, a TSS Maintainer and a TSS User could be the same person or they could be different people. |
3.3.1.1 |
TSS Owner |
3.3.1.1-1 |
The agency or organization that owns the system and sets policy for its use is represented by the TSS Owner actor. |
3.3.1.2 |
TSS Operator |
3.3.1.2-1 |
TSS Operators generally includes all roles that directly manipulate the TSS software. TSS Operators may also serve in other roles (e.g., Manager and Maintainer). Operators may be local or remote, but have access to the system controlling the traffic signals in question. A TSS Operator also includes external systems such as an ATMS (Advanced Traffic Management System) whose operators aren't identified as users of the TSS. It is left up to the ATMS for example to control the access of the ATMS operators. This is distinct from identifying remote operators who gain access through an External System, for whom the TSS will be responsible for handling their access control. |
3.3.1.3 |
TSS Manager |
3.3.1.3-1 |
The TSS Manager is a TSS Operator responsible for the overall operation of the system. The TSS Manager is expected to have full control of the system. The TSS Manager assigns TSS Operators, External Systems and TSS Maintainers their system permissions and capabilities. |
3.3.1.4 |
External System |
3.3.1.4-1 |
The External System actor represents the role of any type of external system to the TSS, through which a remote operator may gain access to the system. |
3.3.1.5 |
TSS Maintainer |
3.3.1.5-1 |
The TSS Maintainer is a TSS Operator who is receiving fault information, diagnosing faults and repairing faults. |
3.3.1.6 |
TSS Designer |
3.3.1.6-1 |
The TSS Designer actor represents the role of the designer of the TSS taking into account overall system requirements and constraints. |
3.3.1.7 |
Traveling Public |
3.3.1.7-1 |
This actor represents the role of the traveling public viewing the Traffic Signal Field Equipment including signal heads as well as pedestrian equipment. |
3.3.2 |
Use Cases |
3.3.2-1 |
Use cases capture the high-level typical interactions between an operator and a computer system. A use case needs to address a discrete goal of the user/operator. Besides the common use cases of system support (e.g., configuration, maintenance, etc.) the TSS use cases give the system operator the ability to better manage transportation-related situations. |
3.3.2.1 |
Configuration of the Central Traffic Signal System (CTSS0 Management System This use case covers the overall configuration of a CTSS Management System including TSS Manager(s) configuring the traffic signal controller's network and managing access to the CTSS Management System. The configuration of operator access to the CTSS Management System as well as access to the databases is set up by the TSS Manager(s). The TSS Manager(s) also configure the overall CTSS Management System's system architecture, system fallback and the intersection display map. Fallback configuration for a controller is set up by the TSS User in the event of communications failure ascertained by the lack of response to a certain number of get requests. |
3.3.2.2 |
Managing the Local Signal Controller Database The Managing the Local Signal Controller Database use case covers the operations performed by the TSS Operator when managing the database residing in local signal controllers. This use case covers TSS Operator operations for data entry, system validity checks to ensure that the central system database matches the controller database, accommodating Universal Traffic Data Format (UTDF) transfers, viewing and printing timing sheets, development of multiple versions of the timing database, upload and download of the timing database, database comparison, database change tracking and searching for intersection databases. |
3.3.2.3 |
Monitoring the Traffic Signal Network This use case covers the TSS Operator monitoring the traffic signal network with the CTSS Management System. The TSS Operator configures the CTSS Management System to monitor specific and groups of traffic signal intersections and overall signal system status. |
3.3.2.4 |
Managing the Traffic Signal Network The Managing the Traffic Signal Network use case covers the management of the traffic signal network by the TSS Operator. For adaptive signal control operations, reference the set of Adaptive Operations use cases. The primary centralized traffic signal systems operations for managing the traffic signal network by the TSS Operator include: enabling diversion plans, synchronizing the time clocks for a group of controllers, selecting plans based on time-of-day either local time-of-day or central system time-of-day, selecting plans based on traffic responsive patterns, selecting plans manually, synchronization of time-of-day clock with external systems, overriding time-of-day operation, remotely placing vehicle and pedestrian calls, manage external devices, managing emergency vehicle preemption, managing bus and light rail signal priority and managing rail preemption. |
3.3.2.5 |
Performance Monitoring Note: Embedded or separate |
3.3.2.5.1 |
Configure Enumerated Data to Intersection Mapping This use case is part of performance monitoring covering the TSS Operator configuring the mapping of the enumerated data to the intersection. |
3.3.2.5.2 |
Retrieve / Store Enumerated Data This use case is part of performance monitoring covering the ability of the TSS Operator to store and retrieve the enumerated data. |
3.3.2.5.3 |
Retrieve / Store High Resolution Traffic Detection Data This use case is part of performance monitoring covering the ability of the TSS Operator to store and retrieve the high-resolution traffic detection data. |
3.3.2.5.4 |
Process Data into Performance Measurements This use case is part of the performance monitoring covering the TSS Operator's initiation of the processing of the enumerated and high resolution traffic detection data into performance measurements. |
3.3.2.5.5 |
Report Performance Measures The Report Performance Measures use case covers how the processed performance measures are reported to the TSS Operator. The performance measures are stored in a log, can be printed and displayed to the TSS Operator. |
3.3.2.6 |
Adaptive Operation Note: The configuration of the Adaptive Signal Control Technologies (ASCT) can either be embedded as part of the CTSS Management System or separate from the CTSS Management System with an Adaptive |
3.3.2.6.1 |
Implement Adaptive Strategies The Implement Adaptive Strategies use case is part of adaptive operations covering how the TSS Operator implements various adaptive strategies such as TBD via the ASCT. |
3.3.2.6.2 |
Adaptively Control Signal Network The Adaptively Control Signal Network use case covers how the TSS Operator determines how the ASCT control the signal network using adaptive capabilities. |
3.3.2.6.3 |
Adaptively Coordinate Signals with Adjacent System The Adaptively Coordinate Signals with Adjacent System use case covers where the TSS Operator prepares the ASCT to coordinate with an adjacent jurisdiction to facilitate coordination of adaptive progression. |
3.3.2.6.4 |
Modify Adaptive Operation based on Queuing This use case covers when the TSS Operator configures the ASCT to modify the adaptive operation based on queuing conditions. |
3.3.2.6.5 |
Accommodate Pedestrians within Adaptive Operation This use case covers when the TSS Operator configures the ASCT to accommodate pedestrians within its adaptive operation. |
3.3.2.6.6 |
Operate Non-Adaptively The Operate Non-Adaptively use case covers when the TSS Operator configures the ASCT to suspend adaptive control under certain situations. |
3.3.2.6.7 |
Managing Sensitivity to Changing Conditions This use case covers when the TSS Operator configures the ASCT to change its sensitivity to changing traffic conditions resulting in a timely non-erratic response. |
3.3.2.6.8 |
Support Signal Controller Features This use case covers special signal controller features that require operational settings as part of the controller database management using a TSS, and features that a TSS or ASCT must allow to operate as the signal controller user intended. |
3.3.2.6.9 |
Provide Security The Provide Security use case covers the system security features as managed by the TSS Manager. |
3.3.2.6.10 |
Monitor and Control Adaptive Operation (was Monitoring and Control) The Monitor and Control Adaptive Operation use case covers how the TSS Operator ensures that the ASCT is performing correctly within a range of operating conditions. |
3.3.2.6.11 |
Measure and Monitor Adaptive Performance The Measure and Monitor Adaptive Performance use case covers how the TSS Operator ensures that the ASCT is measuring and monitoring its performance. |
3.3.2.6.12 |
Report Adaptive Performance The Report Adaptive Performance use case covers the reporting of the performance metrics to the TSS Operator by the ASCT. |
3.3.2.6.13 |
Provide Adaptive Failure Notification The Provide Adaptive Failure Notification use case covers when the ASCT reports adaptive failures to the TSS Operator. |
3.3.2.6.14 |
Accommodate Preemption and Priority Imposed on Adaptive Operations This use case covers when the TSS Operator configures the ASCT to accommodate adaptive operations when preemption and priority occur. |
3.3.2.6.15 |
Respond to Adaptive System Failures This use case covers when the TSS Operator configures the ASCT to respond to adaptive-related system failures. |
3.3.2.7 |
TSS Maintenance |
3.3.2.7.1 |
The TSS Maintainer maintains the TSS by performing and testing all TSS capabilities both locally and remotely. |
3.3.2.7.2 |
The TSS Maintainer maintains the TSS by performing remote updates of the signal controllers, controller firmware and TSS software. |
3.3.2.8 |
Interfacing with External Systems |
3.3.2.8.1 |
The TSS User interfaces with signal controllers and detectors from different manufacturers within the TSS. |
3.3.2.8.2 |
The TSS Maintainer replaces signal controllers detectors from different manufacturers within the TSS. |
3.3.2.8.3 |
The TSS Designer specifies different signal controller and detector interface standards within the TSS. |
3.3.2.8.4 |
The TSS Designer specifies the existing signal controller and detector interfaces in order to integrate new signal controllers and detectors into an existing TSS. |
3.3.2.8.5 |
The TSS Designer specifies the existing signal controller and detector interfaces in order to integrate a new TSS with existing signal controllers and detectors. |
3.3.2.8.6 |
The TSS User interfaces with external TSS's to access information regarding signal controllers, intersections and groups of intersections. |
3.3.2.8.7 |
The TSS User interfaces with external TSS's to allow the External System to access information regarding signal |
3.4 |
Alternative Strategies Considered |
3.4-1 |
This section describes in broad terms the alternative strategies that were considered. [These should include: no change, new system, or new custom system.] |
ConOps Reference # |
ConOps Sample Statement |
System Requirements |
|---|---|---|
4 |
User Needs |
|
4-1 |
This chapter describes the operational needs related to user interface, database management, monitoring, reporting, and maintenance activities. The main purposes of a traffic signal system are: to provide remote access to field infrastructure and signal timing databases, and to monitor and report system performance. |
|
4.1 |
System Configuration |
|
4.1.1 |
TSS Network Characteristics |
|
4.1.1.1 |
The TSS Operator needs to view and control up to XXX traffic signal controllers, at various locations within the (agency). |
3.1.3.1.1 |
4.1.1.2 |
The TSS Operator needs to organize the traffic signals in two (or more) groups for coordination purposes. |
3.1.3.1.2 |
4.1.1.3 |
The TSS Operator needs to change intersection grouping by time of day or other trigger. |
3.1.3.1.2 |
4.1.1.4 |
The TSS operator needs to receive current time from a source to ensure time synchronization between signals. |
3.1.8.1.1
|
4.1.1.5 |
The TSS Operator needs to coordinate traffic signals managed by another system. Note: Cross-jurisdictional heading. |
3.1.3.1.2
|
4.1.2 |
Adaptive Network Characteristics |
|
4.1.2.1 |
The TSS Operator needs to adaptively control up to XXX signals, up to XXX miles from the TMC (or specified location). |
3.1.3.2.1 |
4.1.2.2 |
The TSS Operator needs to be able to adaptively control up to XX independent groups of signals |
3.1.3.2.2 |
4.1.2.3 |
The TSS Operator needs to vary the number of signals in an adaptively controlled group to accommodate the prevailing traffic conditions. |
3.1.3.2.2 |
4.1.3 |
Traffic Performance Measurement Characteristics |
|
4.1.3.1 |
The TSS Operator needs to configure performance measurement operations. |
3.1.3.3.1 |
4.1.4 |
System Access and Security |
|
4.1.4.1 |
The TSS Operator needs to manage the system database from the following locations: (EDIT TO SUIT YOUR SITUATION)
|
3.1.1.1
3.1.1.2 |
4.1.4.2 |
Multiple system TSS Operators need to log on to the system simultaneously in order to do independent functions at different intersections or to view the same intersection. |
3.1.1.3 |
4.1.4.3 |
The TSS Operator needs to make changes to an intersection database, disabling the ability of other TSS Operators to simultaneously make changes to the same intersection database. |
3.1.1.4 |
4.1.4.4 |
The TSS Operator needs to view the status of an intersection or group of intersections even when another TSS Operator is editing the intersection database. |
3.1.1.3 |
4.1.4.5 |
The TSS Operator needs to view the status of multiple agency signals, edit the intersection databases, and/or create reports, as allowed by permission. |
3.1.1.3
3.1.2.5 |
4.1.4.6 |
The TSS Operator needs secure access to the system consistent with the existing agency network policies. |
3.1.2.4 |
4.1.4.7 |
The TSS Manager needs to have a security management and administrative system that allows access and operational privileges to be assigned, monitored and controlled by a TSS Manager, and conform to the agency's access and network infrastructure security policies. |
3.1.2.2
3.1.2.9 |
4.1.5 |
Overall Architecture |
|
4.1.5.1 |
The TSS Operator needs to operate the system with the following architecture (EDIT TO SUIT YOUR SITUATION):
Note: These interfaces are beyond the scope of the Model Systems Engineering documents, and responding to these needs will require additional systems engineering activities to develop needs and requirements related to these interfaces. |
3.1.3.4.5 |
4.1.5.2 |
The TSS Operator needs to access the system at all times to view status or manage the system. |
3.1.7.1.1 |
4.1.5.3 |
The TSS Operator needs to fully operate the system within a communications bandwidth limit of XXX Mbps. (SPECIFY APPLICABLE LIMITS) |
3.1.3.4.1 |
4.1.6 |
TSS Failure and Fallback Mode |
|
4.1.6.1 |
The TSS Operator needs the local traffic signal controllers to fall back to local control without causing disruption to traffic flow, in the event of equipment, communications, or software failure. |
3.1.6.2.1 |
4.1.6.2 |
The TSS Operator needs to maintain a complete log of alarms and failure events. |
3.1.6.1.4 |
4.1.7 |
Adaptive Failure and Fallback |
|
4.1.7.1 |
The TSS Operator needs to fall back to non-adaptive operation as defined in section 4.3, as specified by the operator, without causing disruption to traffic flow, in the event of equipment, communications and software failure. Non-adaptive operation is defined in the TSS needs and requirements. |
3.1.6.1.1
3.1.6.1.2.2
3.1.6.1.2.3 |
4.2 |
Managing Signal System and Field Device Database |
|
4.2.1 |
General Database Development |
|
4.2.1.1 |
The TSS Operator needs to quickly and efficiently configure local and coordinated signal timing parameters, by entering the values manually or copying and editing values. The database needs to be a complete and accurate representation of the local controller database. |
3.1.4.1
3.1.4.4 |
4.2.1.2 |
The TSS Operator needs to verify the validity of all parameters in the controller database, check for errors, and alert the TSS Operator before downloading it to the field controller. |
3.1.4.8
|
4.2.1.3 |
The TSS Operator needs to interface with Optimization Software (SPECIFY TYPE and VERSION) in order to develop and update coordinated timing plans. |
3.1.4.10
|
4.2.1.4 |
The TSS Operator needs to view and print timing sheets that include all the operational timing parameters, including phase diagrams. The timing sheets should be user customizable. |
3.1.4.9
|
4.2.1.5 |
The TSS Operator needs to develop, save and access timing parameters for a temporary condition (such as modifying phases during construction) or a new condition (such as new coordinated timings) without losing information in the original database. |
3.1.4.1 |
4.2.2 |
General Database Management |
|
4.2.2.1 |
The TSS Operator needs to quickly and efficiently upload and download timing parameters between the system and local controllers with no risk of data corruption or errors. |
3.1.5.1
The system shall download the entire intersection database to a controller. |
4.2.2.2 |
The TSS Operator needs to compare the field controller database with the central database and save all or part of the local controller database to the central database. |
3.1.5.14 |
4.2.2.3 |
The TSS Operator needs to upload and download timings to a single intersection or a group of intersections, such as to download a command for a special incident timing plan along a corridor or to change the offset at multiple intersections while fine tuning the coordinated timings. |
3.1.5.2 |
4.2.2.4 |
The TSS Operator needs to have a full and permanent record, created automatically, of any changes to data entered directly into a local controller, including a record of the date and time at which the each change is entered. |
3.1.5.10
3.1.5.15 |
4.2.2.5 |
The TSS Operator needs to search the system for each intersection database by using the intersection name or number or using the system map to point to and select the intersection. |
3.1.5.18
|
4.3 |
TSS Control |
|
4.3.1 |
The TSS Operator needs to operate all signals attached to the system based on their local time of day schedule. |
3.1.8.2.1 |
4.3.2 |
The TSS Operator needs to program commands for local operation based on central time of day schedule. |
3.1.8.3.1 |
4.3.3 |
The TSS Operator needs to send and receive data from another system that would allow the two systems to be coordinated. |
3.1.8.1.4
The system shall receive data from another system (SPECIFY DETAILS). |
4.3.4 |
The TSS Operator needs to override time of day, with a manual command, at an intersection or group of intersections at any time until manually set back to scheduled operation, or expiration of a timer to cancel the override. |
3.1.3.1.3 |
4.3.5 |
The TSS Operator needs to accommodate traffic in a network that displays predictable traffic patterns during variable periods. For example, the traffic pattern for the afternoon peak may be predictable enough to be served by a defined timing plan, but the time of day in which the condition appears may be variable from one day to the next. (Note: For operations not consistent with this need statement, consider using adaptive.) [When selecting this need, select one of the two child needs below. If you have no preference for the pattern selection method, select both, but include this text here: The Vendor may fulfill the requirements traced to either one of the child needs below.] |
3.1.8.3.1
|
4.3.5.1 |
The network is linear and displays inbound and outbound traffic patterns such that the TSS Operator needs to select patterns using an inbound and outbound threshold selection scheme. (This need is appropriate for agencies that have already decided to use traffic-responsive selection of coordination patterns using the threshold level selection method.) |
3.1.8.5.1.1 |
4.3.5.2 |
The network is not linear and does not display pronounced inbound and outbound traffic patterns, such that the TSS Operator needs to select patterns based on which pattern most closely matches the demand conditions, without regard to inbound or outbound emphasis. (This need is appropriate for agencies that have already decided to use traffic-responsive selection of coordination patterns using the pattern-matching selection method.) |
3.1.8.5.1.1 |
4.3.6 |
The TSS Operator needs to enable a diversion plan in case of an incident (or other activities). The TSS Operator needs to be enabled at an intersection or a group of intersections and select the appropriate operating plan based on:
|
3.1.8.3.1
|
4.3.7 |
The TSS Operator needs to keep local intersection controllers in synch with each other to operate coordinated timings and other operations that require a common time. |
3.1.8.1.2
The system shall allow the traffic signals to operate in coordinated mode. |
4.3.8 |
The TSS Operator needs to send manual commands to simulate vehicle and pedestrian detection and preemption calls. |
3.1.8.2.12 |
4.3.9 |
The TSS Operator needs to turn on and off external devices, such as message signs, by manual command, by time of day, or based on a user defined trigger (such as volume). |
3.1.8.2.21 |
4.3.10 |
The TSS Operator needs to accommodate centrally directed emergency vehicle preemption based on an external input from the emergency system. |
3.1.8.2.16 |
4.3.11 |
The TSS Operator needs to accommodate bus and light rail transit signal priority (USER SPECIFY FOR NECESSARY DETAILS). |
3.1.8.2.17 |
4.3.12 |
The TSS Operator needs to accommodate rail preemption based on an external input from the railroad. |
3.1.8.2.17 |
4.3.13 |
The TSS Operator needs to configure when local controllers time clocks are automatically re-synced from an external time source. [Specify conditions for triggering automatic re-sync] |
3.1.8.1.3 |
4.4 |
Adaptive System Operations |
|
4.4.1 |
Adaptive Strategies |
|
4.4.1.1 |
The system TSS Operator needs the ability to implement different strategies individually or in combination to suit different prevailing traffic conditions. These strategies include: |
|
4.4.1.1.1 |
Maximize the throughput on coordinated routes Note to user when selecting these requirements: Select from requirements in the 3.1.9.2 group when sequence-based systems are allowed (sequence-based systems explicitly calculate cycle, offset, and split). Select from requirements in the 3.1.9.3 group when non-sequence-based systems are allowed (non-sequence-based systems do not explicitly calculate cycle, offset, and split). (Select requirements from both groups when the vendor is given the choice of supplying one type of adaptive operation or the other.) |
3.1.9.1.1.7 |
4.4.1.1.2 |
Provide smooth flow along coordinated routes Note to user when selecting these requirements: Select from requirements in the 3.1.9.2 group when sequence-based systems are allowed (sequence-based systems explicitly calculate cycle, offset, and split). Select from requirements in the 3.1.9.3 group when non-sequence-based systems are allowed (non-sequence-based systems do not explicitly calculate cycle, offset, and split). (Select requirements from both groups when the vendor is given the choice of supplying one type of adaptive operation or the other.) |
3.1.9.1.1.7.4 |
4.4.1.1.3 |
Distribute phase times in an equitable fashion Note to user when selecting these requirements: Select from requirements in the 3.1.9.2 group when sequence-based systems are allowed (sequence-based systems explicitly calculate cycle, offset, and split). Select from requirements in the 3.1.9.3 group when non-sequence-based systems are allowed (non-sequence-based systems do not explicitly calculate cycle, offset, and split). (Select requirements from both groups when the vendor is given the choice of supplying one type of adaptive operation or the other.) |
3.1.9.1.1.7 |
4.4.1.1.4 |
Manage the lengths of queues Note to user when selecting these requirements: Select from the requirements in the 3.1.9.2 group when sequence-based systems are allowed (sequence-based systems explicitly calculate cycle, offset, and split). Select from requirements in the 3.1.9.3 group when non-sequence-based systems are allowed (non-sequence-based systems do not explicitly calculate cycle, offset, and split). (Select requirements from both groups when the vendor is given the choice of supplying one type of adaptive operation or the other.) |
3.1.9.1.1.7.2 |
4.4.1.1.5 |
Manage the locations of queues within the network Note to user when selecting these requirements: Select from requirements in the 3.1.9.2 group when sequence-based systems are allowed (sequence-based systems explicitly calculate cycle, offset, and split). Select from requirements in the 3.1.9.3 group when non-sequence-based systems are allowed (non-sequence-based systems do not explicitly calculate cycle, offset, and split). (Select requirements from both groups when the vendor is given the choice of supplying one type of adaptive operation or the other.) |
3.1.9.1.3.1 |
4.4.1.1.6 |
At an isolated intersection, optimize operation with a minimum of phase failures (based on the optimization objectives). |
3.1.9.1.1.8 |
4.4.1.2 |
The system operator needs to manage the coordination in small groups of signals to link phase service at some intersections with phase service at adjacent intersections. Note: Phase-based systems do not explicitly calculate cycle, offset and split at all intersections. |
3.1.9.5.2 |
4.4.1.3 |
The TSS Operator needs to change the operational strategy (for example, from smooth flow to maximizing throughput or managing queues) based on changing traffic conditions. |
3.1.9.1.1.7 |
4.4.1.4 |
The TSS Operator needs to detect repeated phase failures and control signal timing to prevent phase failures building up queues. The TSS Operator in this case is trying to prevent a routine queue from forming where it will block another movement in the cycle unnecessarily. For example, the TSS Operator may need to prevent a queue resulting from the trailing end of the through green from blocking the storage needed by an entering side- street left turn in the subsequent phase. An overall queue management strategy, particularly when congestion is present, is covered under 4.4.1.5. |
3.1.9.1.1.9 |
4.4.1.5 |
The TSS Operator needs to minimize the chance that a queue forms at a specified location. Note to user when selecting these requirements: Select from requirements in the 3.1.9.2 group when sequence-based systems are allowed (sequence-based systems explicitly calculate cycle, offset, and split). Select from requirements in the 3.1.9.3 group when non-sequence-based systems are allowed (non-sequence-based systems do not explicitly calculate cycle, offset, and split). Select from requirements in the 3.1.9.5 group when phase-based systems are allowed (phase-based systems do not explicitly calculate cycle, offset and split at all intersections). (Select requirements from two or all three groups when the vendor is given the choice of supplying the type of adaptive operation.) |
3.1.9.2.5.5 |
4.4.1.6 |
The TSS Operator needs to modify the sequence of phases to support the various operational strategies. |
3.1.10.6 |
4.4.1.7 |
The TSS Operator needs to fix the sequence of phases at any specified location. For example, the operator may need to fix the phase order at a diamond interchange. |
3.1.9.1.2.12 |
4.4.1.8 |
The TSS Operator needs to designate the coordinated route based on traffic conditions and the selected operational strategy. |
3.1.9.1.1.11 |
4.4.1.9 |
The TSS Operator needs to set signal timing parameters (such as minimum green, maximum green and extension time) to comply with agency policies. |
3.1.9.1.1.12 |
4.4.2 |
Adaptive Monitoring and Control |
|
4.4.2.1 |
The TSS Operator needs to monitor and control all required features of adaptive operation from the following locations: (Edit and select as appropriate to suit your situation.) |
3.1.2.8 |
4.4.2.1.1 |
Agency TMC |
3.1.2.8.1 |
4.4.2.1.2 |
Maintenance facility |
3.1.2.8.2 |
4.4.2.1.3 |
Workstations on agency LAN or WAN located at (specify) |
3.1.2.8.2 |
4.4.2.1.4 |
Other agency's TMC (specify) |
3.1.2.8.3 |
4.4.2.1.5 |
Local controller cabinets |
3.1.2.8.5 |
4.4.2.1.6 |
Maintenance vehicles |
3.1.2.8.7 |
4.4.2.1.7 |
Remote locations (specify) |
3.1.2.8.8 |
4.4.2.2 |
The operator needs to access to the database management, monitoring and reporting features and functions of the signal controllers and any related signal management system from the access points defined for those system components. |
3.1.2.10 |
4.4.3 |
Adaptive Coordination across boundaries |
|
4.4.3.1 |
The TSS Operator needs to adaptively control signals operated by (specify jurisdictions). |
3.1.17.1
|
4.4.3.2 |
The TSS Operator needs to send data to another system that would allow the other system to coordinate with the ASCT system. |
3.1.17.1
3.1.17.1.1 |
4.4.3.3 |
The TSS Operator needs to adaptively coordinate signals on two crossing routes simultaneously. (Include signals on crossing arterials within the boundaries of the adaptive systems mapped in Chapter 3.) |
3.1.17.1.8.4 |
4.4.3.4 |
The TSS Operator needs to receive data from another system that will allow the ASCT system to coordinate its operation with the adjacent system. |
3.1.17.1
3.1.17.1.8 |
4.4.3.5 |
The TSS Operator needs to constrain the adaptive system to operate a cycle length compatible with the crossing arterial. |
3.1.17.1.8.2 |
4.4.3.6 |
The TSS Operator needs to detect traffic approaching from a neighboring system and coordinate the ASCT operation with the adjacent system. |
3.1.17.1.8 |
4.4.4 |
Adaptive Queuing Interactions |
|
4.4.4.1 |
The TSS Operator needs to detect queues from outside the system and modify the ASCT operation to accommodate the queuing. |
3.1.9.1.3.1 |
4.4.4.2 |
The TSS Operator needs to detect queues within the system's boundaries and modify the ASCT operation to accommodate the queuing. |
3.1.9.1.3.1 |
4.4.4.3 |
The TSS Operator needs to detect queues propagating outside its boundaries from within the ASCT boundaries, and modify its operation to accommodate the queuing. |
3.1.9.1.3.1 |
4.4.4.4 |
The TSS Operator needs to store queues in locations where they can be accommodated without adversely affecting adaptive operation. |
3.1.9.1.3.1 |
4.4.4.5 |
The TSS Operator needs to prevent queues forming at user- specified locations. |
3.1.9.1.3.1 |
4.4.5 |
Adaptive Accommodation of Pedestrians |
|
4.4.5.1 |
The TSS Operator needs to accommodate infrequent pedestrian operation and then adaptively recover. (This is appropriate for rare pedestrian calls.) |
3.1.11.3 |
4.4.5.2 |
The TSS Operator needs to accommodate infrequent pedestrian operation while maintaining adaptive operation. (This is appropriate for pedestrian calls that are common but not so frequent that they drive the operational needs.) |
3.1.11.2 |
4.4.5.3 |
The TSS Operator needs to incorporate frequent pedestrian operation into routine adaptive operation. (This is appropriate when pedestrians are frequent enough that they must be assumed to be present every cycle or nearly every cycle.) |
3.1.11.2 |
4.4.5.4 |
The TSS Operator needs to accommodate the following custom pedestrian features. (Describe custom features in this need and then create appropriate requirements.) |
3.1.11.10 |
4.4.5.5 |
The TSS Operator needs to accommodate early start of walk and exclusive pedestrian phases. |
3.1.11.1 |
4.4.6 |
Adaptive Accommodation of Preemption and Priority |
|
4.4.6.1 |
The TSS Operator needs to adaptively accommodate railroad and light rail preemption (explain further) |
3.1.14.1 |
4.4.6.2 |
The TSS Operator needs to adaptively accommodate emergency vehicle preemption (explain further) |
3.1.14.2 |
4.4.6.3 |
The TSS Operator needs to adaptively accommodate bus and light rail transit signal priority (explain further) |
3.1.15.1
3.1.15.5.2
3.1.15.6
|
4.4.7 |
Non-Adaptive Situations |
3.1.9.1.1.1 |
4.4.7.1 |
The TSS Operator needs to detect traffic conditions during which adaptive control is not the preferred operation, and implement some pre-defined operation while that condition is present. |
3.1.9.1.1.1 |
4.4.7.2 |
The TSS Operator needs to schedule pre-determined operation by time of day. |
3.1.9.1.1.5 |
4.4.7.3 |
The TSS Operator needs to over-ride adaptive operation. |
3.1.9.1.1.3 |
4.4.8 |
Adaptive System Responsiveness |
|
4.4.8.1 |
The TSS Operator needs to modify the ASCT operation to closely follow changes in traffic conditions. |
3.1.9.6.1 |
4.4.8.2 |
The TSS Operator needs to constrain the selection of cycle lengths to those that provide acceptable operations, such as when resonant progression solutions are desired. |
3.1.9.6.3 |
4.4.8.3 |
The TSS Operator needs to respond quickly to sudden large shifts in traffic conditions. |
3.1.9.6.4 |
4.4.9 |
Adaptive Complex Coordination and Controller Features |
3.1.5.6 |
4.4.9.1 |
The TSS Operator needs to implement the following advanced controller features while maintaining adaptive operation: |
3.1.9.1.2.1
3.1.9.1.2.11
3.1.10.1
3.1.11.9 |
4.4.9.1.1 |
Service a phase more than once per cycle |
3.1.10.1 |
4.4.9.1.2 |
Operate at least XX overlap phases |
3.1.10.2 |
4.4.9.1.3 |
Operate four rings, 16 phases and up to three phases per ring (Edit to suit your needs). |
3.1.10.3 |
4.4.9.1.4 |
Permit different phase sequences under different traffic conditions |
3.1.10.6 |
4.4.9.1.5 |
Allow one or more phases to be omitted (disabled) under certain traffic conditions or signal states. |
3.1.9.1.2.6 |
4.4.9.1.6 |
Prevent one or more phases being skipped under certain traffic conditions or signal states. |
3.1.9.1.2.3 |
4.4.9.1.7 |
Allow detector logic at an intersection to be varied depending on local signal states |
3.1.10.15 |
4.4.9.1.8 |
Accommodate the following custom features used by this agency (describe the features) |
3.1.10.14 |
4.4.9.1.9 |
Allow any phase to be designated as the coordinated phase |
3.1.10.9 |
4.4.9.1.10 |
Allow the operator to specify which phase receives unused time from a preceding phase |
3.1.9.1.2.10
3.1.9.1.2.11
|
4.4.9.1.11 |
Allow the controller to respond independently to individual lanes of an approach. This may be implemented in the signal controller using XX extension/passage timers, which may be assignable to each vehicle detector input channel. This may allow the adaptive operation to be based on data from a specific detector, or by excluding specific detectors. |
3.1.10.12 |
4.4.9.1.12 |
Allow the coordinated phase to terminate early under prescribed traffic conditions |
3.1.10.10 |
4.4.9.1.13 |
Allow flexible timing of non-coordinated phases (such as late start of a phase) while maintaining coordination |
3.1.11.6
|
4.4.9.1.14 |
Protected/permissive phasing and alternate left turn phase sequences. |
3.1.9.1.2.1 |
4.4.9.1.15 |
Use flashing yellow arrow to control permissive left turns and right turns. |
3.1.10.11 |
4.4.9.1.16 |
Service side streets and pedestrian phases at minor locations more often than at adjacent signals when this can be done without compromising the quality of the coordination. (E.g., double-cycle mid-block pedestrian crossing signals.) |
3.1.10.13 |
4.4.9.1.17 |
Use negative pedestrian phasing to prevent an overlap conflicting with a pedestrian walk/don't walk |
3.1.11.9 |
4.4.10 |
Adaptive Alerts |
|
4.4.10.1 |
The TSS Operator needs to immediately notify maintenance and operations staff of alarms and alerts. |
3.1.6.1.3 |
4.4.10.2 |
The TSS Operator needs to immediately and automatically pass alarms and alerts to the (specify external system). |
3.1.6.1.3 |
4.5 |
Traffic and Operational Performance Measurement, Monitoring, and Reporting |
|
4.5.1 |
TSS Operational Reporting |
|
4.5.1.1 |
The TSS Operator needs to generate historical and real time reports that describe TSS operation. |
3.1.16.1.6
The system shall create standard reports [specify]. |
4.5.1.2 |
The TSS Operator needs a permanent record of each detected fault. |
3.1.16.1.7 |
4.5.1.3 |
The TSS Operator needs a time-stamped record of who accesses the system, all manual commands, and data changes made during a session. |
3.1.5.13
3.1.8.2.12 |
4.5.1.4 |
The TSS Operator needs a log of all software functions executed by the central system and local controllers. |
3.1.5.13
3.1.8.2.12 |
4.5.1.5 |
The TSS Operator needs to report the exact state of signal timing and input data for a specified period, to allow historical analysis of the system operation. |
3.1.5.19 |
4.5.2 |
Adaptive Operational Monitoring and Reporting |
|
4.5.2.1 |
The agency needs the (specify external decision support system) to be able to monitor the ASCT system automatically. |
3.1.17.1.3
|
4.5.2.2 |
The TSS Operator needs to store and report data used to calculate signal timing and have the data available for subsequent analysis. |
3.1.5.22
The ASCT shall store the following data in XX minute increments: (edit as appropriate)
The ASCT shall report measures of current traffic conditions on which it bases signal state alterations. |
4.5.2.3 |
The TSS Operator needs to store and report data that can be used to measure traffic performance under adaptive control. |
3.1.5.22
3.1.5.30
|
4.5.2.4 |
The TSS Operator needs to store all operational data and signal timing parameters calculated by the adaptive system, and export selected data to (specify appropriate external system). |
3.1.5.20
The ASCT shall store the event log for a minimum of XX days
3.1.5.28 |
4.5.2.5 |
The TSS Operator needs to report performance data in real time to (specify external system). |
3.1.17.1
3.1.17.1.1 |
4.5.2.6 |
The TSS Operator needs to generate historic and real-time reports that effectively support operation, maintenance and reporting of system performance and traffic conditions. |
3.1.5.23
3.1.5.26
3.1.5.27
3.1.5.29 |
4.5.3 |
Traffic Performance Collection and Storage |
|
4.5.3.1 |
The TSS Operator needs to collect and store high resolution data from traffic signal controllers. |
3.1.16.1.7
3.1.16.5.1 |
4.5.4 |
Traffic Performance Processing |
|
4.5.4.1 |
The TSS Operator needs the system to accept high resolution controller data in order to calculate and report intersection and system performance measurements that support operational objectives. |
3.1.16.3.5
3.1.16.6.1
|
4.5.5 |
Traffic Performance Reports |
|
4.5.5.1 |
The TSS Operator needs to view reports showing traffic operational performance. |
3.1.16.7.3
3.1.16.7.3.1 |
4.5.6 |
Alerts |
|
4.5.6.1 |
The TSS Operator needs to receive alerts about traffic operational performance. |
3.1.16.8.1 |
4.5.6.2 |
The TSS Operator needs to immediately know when a hardware or software fault occurs at a local intersection. |
3.1.16.2.1
3.1.16.2.2 |
4.5.6.3 |
The TSS Operator needs to immediately notify maintenance and operations staff of alarms and alerts. |
3.1.6.2.2 |
4.5.6.4 |
The TSS Operator needs to immediately and automatically pass alarms and alerts to the (specify external system). |
3.1.6.2.2 |
4.5.7 |
Real-Time Monitoring |
|
4.5.7.1 |
The TSS Operator needs to observe the operation of traffic signal field equipment. |
3.1.7.1.3
3.1.7.1.6 |
4.5.7.1.1 |
The TSS Operator needs to view real time display of an intersection and typical controller front panel information status of operating mode, phases, and detectors. |
3.1.7.2.1
3.1.7.2.4
3.1.7.2.5
3.1.7.2.6 |
4.5.7.1.2 |
The TSS Operator needs to select a predetermined group of intersections to monitor. |
3.1.1.6
3.1.7.1.14 |
4.5.7.1.3 |
The TSS Operator needs to quickly and efficiently set up the intersection status display on the map, including all inputs and outputs at the intersection. |
3.1.7.1.3
3.1.7.1.4 |
4.5.7.1.4 |
The TSS Operator needs to view real time communications status, operational status and equipment status for all equipment connected to the signal system. The status should be color coded to quickly see issues. |
3.1.7.1.3
3.1.7.1.6
|
4.5.7.2 |
The TSS Operator needs to view a real-time time-space-diagram of user defined intersection group, including real time splits, offsets and coordinated phase detector actuations of each intersection in group. |
3.1.7.1.10
|
4.6 |
Data Storage |
|
4.6.1 |
The TSS Operator needs to access the data on the system for (XX) months after which it will be archived. |
3.1.16.1.8 |
4.7 |
Constraints |
|
4.7.1 |
TSS Constraints |
|
4.7.1.1 |
The TSS Designer is constrained to using the following equipment: - Controller type (list acceptable equipment) - Controller firmware (list acceptable firmware) - Communication system (list acceptable equipment) - Cabinet type and size (list acceptable equipment) - Signal management system (list acceptable systems) |
3.1.3.4.1 |
4.7.1.2 |
The TSS Designer needs to use equipment and software acceptable under current agency IT policies and procedures (USER TO SPECIFY) |
3.1.2.4 |
4.7.1.3 |
The TSS Designer needs to use specific communications protocols (specify AB3418E, NTCIP, or other) to all existing and future traffic signal controllers connected to the system. |
3.1.3.4.1 |
4.7.1.4 |
The TSS Designer needs to communicate to traffic signal controllers using Ethernet protocol (OR SERIAL OR OTHER. USER TO SPECIFY). |
3.1.3.4.3 |
4.7.1.5 |
The TSS Designer needs to use equipment and software acceptable under current agency IT policies and procedures. |
3.1.18.1
|
4.7.1.6 |
The TSS Operator needs access to and operation of the system in all environmental conditions. |
3.1.3.4.7 |
4.7.1.7 |
The TSS Designer needs to fully implement the system with full capability within the available budget of $(USER TO SPECIFY). (or included in procurement documents but not in system requirements) |
3.1.3.4.8 |
4.7.2 |
Adaptive Constraints |
|
4.7.2.1 |
The TSS Designer is constrained to use the following equipment: |
|
4.7.2.1.1 |
Controller type (list acceptable equipment) |
3.1.18.3 |
4.7.2.1.2 |
Detector type (list acceptable equipment) |
3.1.13.1
3.1.13.2 |
4.8 |
Training |
|
4.8.1 |
TSS Training |
|
4.8.1.1 |
The TSS Manager needs all staff involved in operations and maintenance to receive appropriate training. |
3.1.19.1 |
4.8.2 |
Adaptive Training and Support |
|
4.8.2.1 |
The TSS Manager needs [Specify staff] involved in operations and maintenance of the adaptive system to receive appropriate training. |
3.1.19.4.4 |
4.8.3 |
Automated Traffic Signal Performance Measurement Training |
|
4.8.3.1 |
The TSS Manager needs [Specify staff] involved in operations and maintenance of the automated signal performance measurement system to receive appropriate training. |
3.1.19.4.5 |
4.9 |
External Interfaces |
|
4.9.1 |
The TSS Operator needs to align coordinated traffic signals in the system in question with coordinated traffic signals in an adjacent system. (The intent of this need is to maintain cycle-offset-split signal coordination across system boundaries. Basic coordination can be provided by using timings that are compatible in both systems, following compatible time-of-day schedules, and maintaining synchronization of the time-of- day clocks. Under this need, the system is responsible only for the clock synchronization, and the user is responsible for compatible timings and schedules.) |
3.1.17.1
3.1.17.1.1 |
4.9.2 |
The TSS Operator needs to select coordinated signal timing patterns (including cycle, offset, split, special functions, and phase sequence) based on the timing patterns in current operation in an adjacent system. (This user need addresses both time-of-day and traffic responsive coordination modes. In addition to the clock synchronization provided in 4.9.1, this user need also requires the system to align its timing pattern in use with an adjacent system automatically. This user need does not mean the system will create signal timings that are compatible — that is assumed to be the responsibility of the user.) |
3.1.17.1
3.1.17.1.2 |
4.9.3 |
The TSS Operator needs to provide signal operational data to an external display service, which may be a regional display map at another traffic management center. |
3.1.17.1
3.1.17.1.3 |
4.9.4 |
The TSS Operator needs to allow control of the system by the operator of an external system. (The envisioned scenario is a freeway management operator engaging a particular coordinated signal timing pattern to carry traffic diverting around a freeway incident or bottleneck on appropriate arterial streets. This engagement may need to be done through the traffic management system in use by the freeway management operator.) |
3.1.17.1
3.1.17.1.4 |
4.9.5 |
The TSS Operator needs to be able to turn on signs that control traffic or provide driver information when specific traffic conditions occur, when needed to support the adaptive operation, when congestion is detected at critical locations or according to a time-of-day schedule. |
3.1.12.1 |
4.9.6 |
The TSS Operator needs to react to commands issued by (specify an external control or decision support system, such as an ICM system or another signal system). |
3.1.9.1.1.6
3.1.17.1.6
3.1.17.1.8
3.1.17.1.12 |
4.10 |
Maintenance, Support and Warranty |
|
4.10.1 |
The TSS Manager needs the system to fulfill all the requirements for the life of the system. The agency therefore needs the system to be maintained to repair faults that are not defects in materials and workmanship. |
3.1.20.1 |
4.10.2 |
The agency needs the system to fulfill all requirements for the life of the system. The agency therefore needs support to keep software and software environment updated as necessary to prevent requirements no longer being fulfilled. |
3.1.20.2 |
4.10.3 |
The agency needs the system to fulfill all requirements for the life of the system. The agency therefore needs the system to remain free of defects in materials and workmanship that result in requirements no longer being fulfilled. |
3.1.20.3 |
ConOps Reference # |
ConOps Sample Statements |
|---|---|
5 |
Envisioned System Overview |
5.1 |
Proposed TSS Architecture |
5.1.1 |
An architecture diagram showing all the high-level elements of the TSS/ASCT system based on the appropriate Regional ITS Architecture. [Insert system architecture diagram to illustrate proposed system in this section. |
5.2 |
TSS/ASCT System Overview |
5.2.1 |
The agency plans to implement a traffic signal system comprising:
|
6 |
Operational Environment |
6.1 |
TSS Operational Environment |
6.1.1 |
The system will be operated and monitored from the [specify agency] [specify overall system name such as TMC]. |
6.1.2 |
The system will be operated and monitored from workstations located [specify who will have workstations and where they will be located]. |
6.1.3 |
The central server equipment will be housed at [specify location] in an [air-conditioned or non-air-conditioned] environment. |
6.1.4 |
The [in-house operators and/or on-call contract staff] will handle complaints or requests for changes in operation on an as-needed basis. |
6.1.5 |
Maintenance of all field equipment will be performed by [in-house and/or contract] staff |
6.1.6 |
Maintenance of the following field equipment will be performed by [in-house and/or contract] staff. [specify what equipment will be maintained by whom] |
6.1.7 |
Funding for maintenance of the TSS will come from [specify funding program or source]. An increase of [specify $] per year will be required to accommodate the additional equipment installed for the TSS. |
6.1.8 |
Additional communications equipment and annual fees will be incurred with the TSS. This will amount to approximately [specify $] per year, and will be covered by the [specify program or budget allocation details]. |
6.1.9 |
Replacement or repair of defective or failed equipment will be covered for [specify years] by the manufacturers' warranties. The labor cost of replacement during this period will be included in the purchase price. |
6.1.10 |
The agency expects maintenance of parts and equipment for a period of [specify years] will be included in the purchase price. |
6.1.11 |
The agency expects maintenance of all TSS management software for a period of [specify years] will be included in the purchase price. |
6.1.12 |
The agency expects to operate this system using the latest software for a period of [specify years]. |
6.1.13 |
The agency will seek technical support from the vendor for assistance in using the TSS management software for [specify years]. |
6.1.14 |
Operations and maintenance staff will have the ability to log in to the system from remote locations via the internet, and have full functionality consistent with their access level. |
6.1.15 |
Include any additional needs for support or information from the vendor that will be needed by your agency, and that will become requirements in the contract or purchase documents. |
6.1.16 |
The central server will be a standard platform maintained by the [specify agency department] and able to be replaced independently from the software. |
6.1.17 |
The agency selection of traffic signal equipment will not be constrained by the TSS software. |
6.2 |
Adaptive Operational Environment |
6.2.1 |
The system will be operated and monitored from the [specify agency] TMC. |
6.2.2 |
The system will be operated and monitored from the [specify agency] signal shop. |
6.2.3 |
The system will be operated and monitored from workstations located [specify who will have workstations and where they will be located]. |
6.2.4 |
An operator will be able to have full access to the system from each local controller or on-street master. |
6.2.5 |
The central server equipment will be housed at [specify location] in an [air-conditioned or non-air-conditioned?] environment. |
6.2.6 |
Equipment compatibility constraints |
6.2.6.1 |
The central server will be a standard platform [maintained by the agency IT Department] and able to be replaced independently from the software. |
6.2.6.2 |
The agency selection of controller will not be constrained by the adaptive software. |
6.2.6.3 |
The agency prefers specific detector technology. [Specify your selected detector types]. |
6.2.6.4 |
The agency prefers to use the following controller types. [Specify acceptable controller types.] |
6.2.7 |
The operators will already be experienced in setting up and fine tuning traditional coordinated signal systems. They will require training specific to the adaptive system, sufficient to allow them to set up, adjust and fine tune all aspects of the system. |
6.2.8 |
The set up and fine tuning of the system will be contracted out. A review of the system's operation will be performed quarterly [specify frequency]. |
6.2.9 |
Complaints or requests for changes in operation will be handled by the in-house operators on an as-needed basis. |
6.2.10 |
Complaints or requests for changes in operation will be handled by on-call contract staff on an as-needed basis. |
6.2.11 |
Maintenance of all field equipment will be performed by in-house [OR contract] staff |
6.2.12 |
Maintenance of the following field equipment will be performed by in-house [OR contract] staff. [specify what equipment will be maintained by whom.] |
6.2.13 |
Funding for maintenance of the adaptive system will come from [specify funding program or source]. An increase of $xxx per year will be required to accommodate the additional equipment installed for the adaptive system. |
6.2.14 |
Additional communications equipment and annual fees will be incurred with the adaptive system. This will amount to approximately $xxx per year, and will be covered by the [specify program or budget allocation details]. |
6.2.15 |
Replacement or repair of defective or failed equipment will be covered for xx years by the manufacturers' warranties. The labor cost of replacement during this period will be included in the purchase price. |
6.2.16 |
The agency expects maintenance of parts and equipment for a period of XX years will be included in the purchase price. (Note: May not be eligible for Federal funding) |
6.2.17 |
The agency expects maintenance of all adaptive system software for a period of xx years will be included in the purchase price. |
6.2.18 |
The agency expects to operate this system using the latest software for a period of CC years. |
6.2.19 |
The agency will seek technical support from the vendor for assistance in using the adaptive software for XX years. |
6.2.20 |
Operations and maintenance staff will have the ability to log in to the system from remote locations via the internet, and have full functionality consistent with their access level. |
6.2.21 |
The ASCT's operation will be able to be customized to suit the different situations that will be experienced in the different areas where it will operate. |
6.2.21.1 |
The agency's experienced operators will be able to write customized routines using the ASCT's API. |
6.2.21.2 |
The vendor will be able to provide customized routines that take advantage of the ASCT's API. |
6.2.22 |
Include any additional needs for support or information from the vendor that will be needed by your agency, and that will become requirements in the contract or purchase documents. |
7 |
Support Environment |
7.1 |
TSS Support Environment |
7.1.1 |
Institutions and Stakeholders |
7.1.1.1 |
Existing stakeholders of the TSS include: [list all stakeholders, such as:] Sponsoring agency Neighboring agencies that will access the TSS Etc. |
7.1.1.2 |
The stakeholders who will be affected by or have a direct interest in the TSS are: [list existing and include new stakeholders]. |
7.1.1.3 |
The activities that will be undertaken by the TSS stakeholders include: system operation, system monitoring and adjustment, system performance monitoring and evaluation. |
7.1.1.4 |
The organizational structures of the units responsible for installation, operation and maintenance are illustrated in the attached organization chart. The roles, responsibilities and required qualifications and experience are described below. [Describe as appropriate] |
7.1.2 |
Facilities |
7.1.2.1 |
Describe the current and/or proposed [TMC or TSS Center]. |
7.1.2.2 |
Will there be a satellite and/or backup [TMC or TSS Center]? |
7.1.2.3 |
Describe the locations elsewhere within the agency, such as on a LAN or WAN, from which access to the system will be required? |
7.1.2.4 |
Is air-conditioning required? |
7.1.2.5 |
Describe the location where a separate server will be located. (e.g., IT server room, TMC back room, remote hub) |
7.1.2.6 |
Describe who is responsible for providing and maintaining staff facilities (e.g., personnel, public works, building services, etc.?) |
7.1.2.7 |
Describe who is responsible for fire control facilities (e.g., part of operating group's responsibility, or the responsibility of another group, such as building services?) |
7.1.2.8 |
Describe who is responsible for secure access to the TMC, workshop, or office with TSS workstations? (e.g., Is it the responsibility of the operating group or another group, such as building services?) |
7.1.3 |
System Architecture Constraints |
7.1.3.1 |
The TSS processor/server will be protected within the agency's firewalls. The IT Department will provide resources, equipment and system management so that users/operators will have appropriate access to the system locally, from within the agency's LAN and from remote locations. |
7.1.3.2 |
The communications media available for use by the system will be: [List Available Media, Provide a map or block diagram as appropriate. Show locations of any gaps, bandwidth and latency constraints, protocols and available alternatives.] |
7.1.3.3 |
The [specify which State or Region] [Statewide or Regional] ITS Architecture provides the context for the TSS project. The TSS project fits within the ITS Architecture as illustrated in Figure XX. [Explain each architectural element and information flow in the CCTV System project. If additional elements or interfaces are added, explain why]. |
7.1.4 |
Utilities |
7.1.4.1 |
Are utilities the responsibility of the operating group, or are they the responsibility of another group, such as building services? |
7.1.5 |
Equipment |
7.1.5.1 |
Describe what test equipment is required to support the TSS (e.g., communications testers, fiber testers, signal equipment testers). Is this currently available or is additional equipment required? |
7.1.5.2 |
Will vehicles be the responsibility of the operating group or another group within the agency? What types of vehicles will be required, and how many? |
7.1.6 |
Computing hardware |
7.1.6.1 |
Describe the additional computing equipment required to support TSS operation, such as printer, copier, additional monitors, and scanner. |
7.1.6.2 |
Describe who is responsible for maintenance and repair of the computing equipment? |
7.1.6.3 |
Describe who is responsible for replacement of the computing equipment when it reaches the end of its useful life? |
7.1.7 |
Software |
7.1.7.1 |
Who is responsible for keeping software up to date? |
7.1.7.2 |
Who is responsible for keeping software licenses current? |
7.1.7.3 |
What controls are proposed governing software use and availability on workstations and other support computers? |
7.1.8 |
Personnel |
7.1.8.1 |
Describe how many users/operators will be available for routine operations. Will this be provided by existing staff or will additional staff be required? |
7.1.8.2 |
Describe what hours users/operators will be available. |
7.1.8.3 |
Describe what training users/operators will need. |
7.1.8.4 |
Describe what maintenance staff will be required. Will this be provided by existing staff or will additional staff be required? |
7.1.8.5 |
What qualifications and training will the maintenance staff require? |
7.1.9 |
Operating procedures |
7.1.9.1 |
Describe who will be responsible for backing up databases. How often will backups be required? Will backups be stored off-site? |
7.1.10 |
Maintenance |
7.1.10.1 |
Describe the arrangements for maintenance. (E.g., is it done in-house or contracted out? Is it 24/7? Is equipment repair done in-house or externally?) |
7.2 |
Adaptive Support Environment |
7.2.1 |
Institutions and Stakeholders |
7.2.1.1 |
Existing stakeholders of the traffic signal system include: [list all stakeholders, such as:]
|
7.2.1.2 |
The stakeholders who will be affected by or have a direct interest in the adaptive system are: [List existing and include new stakeholders] |
7.2.1.3 |
The activities that will be undertaken by the adaptive system stakeholders include: preparation of timing parameters, implementation and fine tuning, system monitoring and adjustment, system performance monitoring and evaluation. |
7.2.1.4 |
The organizational structures of the units responsible for installation, operation and maintenance are illustrated in the attached organization chart. The roles, responsibilities and required qualifications and experience are described below. [Describe as appropriate] |
7.2.2 |
Facilities |
7.2.2.1 |
Describe the current and/or proposed TMC. |
7.2.2.2 |
Will there be a satellite TMC (e.g., at Corp Yard, at a major event center, at a local EOC?) |
7.2.2.3 |
Describe the locations elsewhere within the agency, such as on a LAN or WAN, from which access to the system will be required? |
7.2.2.4 |
Is air-conditioning required? |
7.2.2.5 |
Describe the location where a separate server will be located. (e.g., IT server room, TMC back room, signal maintenance area, remote hub, remote on-street cabinet) |
7.2.2.6 |
Describe who is responsible for providing and maintaining staff facilities (e.g., personnel, public works, building services, etc.?) |
7.2.2.7 |
Describe who is responsible for fire control facilities (e.g., part of operating group's responsibility, or the responsibility of another group, such as building services?) |
7.2.2.8 |
Describe who is responsible for secure access to the TMC, workshop, or office with adaptive system workstations? (E.g., Is it the responsibility of the operating group or another group, such as building services? |
7.2.3 |
System Architecture Constraints |
7.2.3.1 |
The adaptive processor/server will be protected within the agency's firewalls. The IT Department will provide resources, equipment and system management so that operators will have appropriate access to the system locally, from within the agency's LAN and from remote locations. |
7.2.3.2 |
The communications media available for use by the system will be: [List available media, provide a map or block diagram as appropriate. Show locations of any gaps, bandwidth and latency constraints, protocols and available alternatives.] |
7.2.3.3 |
The Regional ITS Architecture is illustrated in Figure XX. The adaptive system will operate within the local ITS Architecture of [NAME THE AGENCY]. It will interact with the Regional ITS Architecture in the following manner. [Describe the physical architecture. Include information flows.] |
7.2.4 |
Utilities |
7.2.4.1 |
Are utilities the responsibility of the operating group, or are they the responsibility of another group, such as building services? |
7.2.5 |
Equipment |
7.2.5.1 |
Describe what test equipment is required to support the adaptive system (e.g., communications testers, fiber testers, controller testers). Is this currently available or is additional equipment required? |
7.2.5.2 |
Will vehicles be the responsibility of the operating group or another group within the agency? What types of vehicles will be required, and how many? |
7.2.6 |
Computing hardware |
7.2.6.1 |
Describe the additional computing equipment required to support the operation, such as printer, copier, additional monitors, and scanner. |
7.2.6.2 |
Describe who is responsible for maintenance and repair of the computing equipment? |
7.2.6.3 |
Describe who is responsible for replacement of the computing equipment when it reaches the end of its useful life? |
7.2.7 |
Software |
7.2.7.1 |
Who is responsible for keeping software up to date? |
7.2.7.2 |
Who is responsible for keeping software licenses current? |
7.2.7.3 |
What controls are proposed governing software use and availability on workstations and other support computers? |
7.2.8 |
Personnel |
7.2.8.1 |
Describe how many operators will be available for routine operations. Will this be provided by existing staff or will additional staff be required? |
7.2.8.2 |
Describe what hours operators will be available. |
7.2.8.3 |
Describe what training operators will need. |
7.2.8.4 |
Describe what maintenance staff will be required. Will this be provided by existing staff or will additional staff be required? |
7.2.8.5 |
What qualifications and training will the maintenance staff require? |
7.2.9 |
Operating procedures |
7.2.9.1 |
Describe who will be responsible for backing up databases. How often will backups be required? Will backups be stored off-site? |
7.2.10 |
Maintenance |
7.2.10.1 |
Describe the arrangements for maintenance. (e.g., is it done in-house or contracted out? Is it 24/7? Is equipment repair done in-house or externally?) |
7.2.11 |
Disposal |
7.2.11.1 |
Describe what material and/or equipment will need to be disposed of during the life of the project, and how it will be disposed. |
7.2.11.2 |
Describe how system components will be disposed of at the end of their useful life. |
8 |
Operational Scenarios |
8.1 |
TSS Operational Scenarios Overview |
8.1-1 |
The following operational scenarios describe how the TSS is expected to operate under various conditions. The proposed TSS is expected to be able to manage the following operational scenarios and issues envisioned for both the current and future project locations. Scenarios are described for the following operational conditions: [Edit to suit your situation.]
|
8.1.1 |
New Signal |
8.1.1.1 |
The agency is adding a new traffic signal to the system. They use the central system to enter the local timings to make the signal operational, including min and max times, ped timings, clearance timings, detector timings, preemption settings, phase sequencing, etc. The agency downloads the timing database to the controller in the office to bench test the timings. The controller is installed in the field and minor tweaks to the detector settings are made. The field timings are uploaded to the system and saved as the official database. The new signal is added to the map, which shows signal status at the highest level and detailed phase status at the intersection level. If the signal had coordinated timings, then the corridor level map would show coordination status. |
8.1.2 |
Time of Day Operation |
8.1.2.1 |
The agency has developed coordinated timing plans for all of its major arterials. The timing plans operate based on the time of day scheduler. The central system provides a time synch for all of the signals so that they have the same exact time of day. The system also monitors what timing plan each signal is operating and compares it to the central database. Any discrepancies are logged and the operator alerted via email. |
8.1.3 |
Normal Routine Operations and Responding to Citizen Calls |
8.1.3.1 |
The agency gets a call from a citizen about a signal "not working". In order to determine what the issue is, the operator logs onto the signal system to check the timings and verify that it operating as it is supposed to be. The signal status screen on the map shows that the signal has communication and it operating the a.m. peak plan. The operator uploads the timings from the controller and compares them to the timings in the central database. All timings are match. The operator then uploads the split logs and the operator finds that Phase 4 (side street) is serving the maximum time from 1 a.m. to 4 a.m. on some days. This leads the operator to suspect there is a problem with the video detection in the middle of the night. The maintenance technicians are dispatched to address this issue. For the next week, the operator uploads the split logs and sees that the split times look appropriate. Another example would be that the operator finds that the split time for Phase 1 is continually maxing out during the a.m. peak plan. Due to a new school in the area, traffic has increased and the phase needs additional time to serve the demand. The operator is able to adjust the a.m. peak splits and download them to the controller. The operator monitors the split logs for the next several weeks to see if the phase still maxes out. |
8.1.4 |
Event Plans |
8.1.4.1 |
There is a large stadium in town that hosts university football games and concerts. Some streets near the stadium are closed for two hours before big games. After the games, there are specific exit routes for traffic leaving the area. The operator has predetermined timing plans to operate during the pregame and the postgame time periods. The operator watches the CCTV cameras near the stadium to see when the streets are closed (or gets call from police) and then manually calls in the event timing plans, which operate until the start of the game. After the game, the operator manually calls in another set of event timings that operate for 30 minutes (which has been determined to be how long it takes for traffic to clear). Once the event is over, the timings revert to the regularly schedule timing plans. |
8.1.5 |
Incident Plans |
8.1.5.1 |
The agency has an arterial corridor that runs parallel to a freeway. Incidents on the freeway result in increased traffic on the arterial corridor as people avoid the congestion. The agency has developed special incident plans (flush plans) to handle the increase in traffic. The special plans can be called in by several different methods, including: manual override by the operator, volume trigger of a system detector(s) or an external trigger from the freeway management system. A request from an external system will send an alert to the operator who must confirm the requested action. Once the incident clears, the central system will call in the regularly scheduled timing plans via manual override by operator, volume trigger or external trigger. |
8.1.6 |
Detector Health Monitoring |
8.1.6.1 |
The agency has configured the signal system to report detector faults and failures. The detectors are configured to collect volume and occupancy on a cycle by cycle basis. If the detector is out of range (too high of volumes or too low of volumes), it will generate an alert which is accessible via a detector health report. Each morning, the operator reviews the detector health report to determine if there are any problem locations and then dispatches the signal technicians to address the issue. The operator may choose to download modified minimum or maximum green times if the detector issue cannot be fixed quickly. For detectors at critical intersections, the operator and lead technician receive a text alert (or email) of the problem (in addition to being logged in the detector health report). |
8.1.7 |
Performance Measurement |
8.1.7.1 |
The agency tracks several performance metrics with the central system. The agency has configured the detection and timing parameters to log data and the central system creates reports that are easy to read. On a monthly basis, the agency reviews the transit signal priority logs to see how many requests were received and granted and whether the result was early green or green extension. This report is reviewed with the transit agency to determine if any changes to the TSP timings is necessary. On a monthly basis, the agency reviews the percent arrival on green data and compares it to the previous month's data to see if there are any changes to the arrival patterns that need to be reviewed. |
8.1.8 |
Automated Traffic Signal Performance Measures |
8.1.8.1 |
The agency uses automated performance measurement tools to monitor operation on coordinated systems on a daily basis. They used a report like the Phase Termination Report to identify systematic max-outs of phases, or to identify detector faults. They use a report like the Purdue Coordination Diagram to monitor the effectiveness of offsets and cycle lengths. These and other reports are built from high-resolution data uploaded from traffic signal controllers every few minutes, and stored in a server. The reports mine the data stored in that server for the period in question, which can be as recent as the previous upload period. The agency user can adjust the length of the time period covered by the report, from a few cycles to days, weeks, and months. The performance measurement software will compile intersection reports to provide an overall view of arterial and network operations. Based on all these reports, agency users will make routine revisions to the signal timing settings to improve operations, using subsequent reports to verify that the improvements were effective. |
8.1.9 |
Updating Coordinated Timings |
8.1.9.1 |
The agency is updating the coordinated timings along a corridor that has 23 signals. To develop the existing Synchro model, the agency uploads the existing timing databases and corresponding phase diagrams and sends to the consultant. The consultant develops the timings and gives the agency the new cycle, split, offsets for each signal. The agency enters the new coordinated timings and time of day schedule into the database and labels it "new". The time of day schedule can be copied from one signal database to another to save time and reduce errors. As the timings are entered, the agency performs an error check of the coordinated timings to ensure they will operate in the field. The agency saves the existing timing databases as a back-up in case they need to revert back to them for any reason. The agency downloads the new databases to each signal and monitors that they are operating the appropriate plan. The agency and consultant drive the corridor to observe the timings and determine they need to make a few adjustments to splits and offsets. They log in remotely from a laptop to the traffic signal system and make the changes to the timing databases and download them to the signals. During the fine-tuning stage, the operator opens up the real-time time space diagram to see how the progression looks. The operator identifies one signal where the offset is 30 seconds off. The operator modifies the offset and downloads it to the controller. For the next several weeks, the operator and consultant log into the system and upload split logs and view the time space diagram to ensure that the timings are operating as they were designed to. |
8.1.10 |
Consultant (External) Access |
8.1.10.1 |
The agency receives a request for signal timing data from a consultant that is completing a traffic impact study. The consultant has remote access (read only) to the central system and is able to log into the system and retrieve the timing sheets. |
8.1.11 |
Adjacent Agency Access |
8.1.11.1 |
The local agency has a corridor that has two DOT-owned traffic signals on it. The DOT maintains the traffic signal equipment and operates the signal timing. The local agency is able to log into the system to view the operations of the DOT signals and under special circumstances, make changes to the timing (incidents, events, etc.) when the DOT is unable to do so. The system maintains a permanent log of all the changes (what was changed, when it was changed and who made the change). |
8.1.12 |
Loss of Communications or Server Fault |
8.1.12.1 |
If the central server goes down or communications to the traffic signals is interrupted, the local traffic signal controllers need to continue to operate safely. The local controllers will operate based on the time of day schedule. The central system provides remote access and the ability to monitor the signals, but it doesn't control the operations of the local controllers. |
8.2 |
Adaptive Operational Scenarios Overview |
8.2-1 |
The following operational scenarios describe how the ASCT system is expected to operate under various conditions. The proposed ASCT system is expected to be able to manage the following operational scenarios and issues envisioned for both the current and future project locations. Scenarios are described for the following operational conditions: [Edit to suit your situation.]
(For each scenario, as applicable, describe the following elements:
|
8.2.1 |
Typical Heavy (Congested) Traffic |
8.2.1.1 |
Example: Arterial Road with Diamond interchange |
8.2.1.1.1 |
Road network |
8.2.1.1.1-1 |
Broadway is an arterial road that passes through a diamond interchange. While the arterial primarily provides access to the freeway from residential areas to the east and west, it also serves a major shopping area, restaurants and office land uses adjacent to the freeway. Ramp meters are used on the freeway on-ramps during periods of heavy traffic on the freeway. |
8.2.1.1.2 |
Traffic conditions |
8.2.1.1.2-1 |
During the morning peak, traffic is heavy approaching the freeway from the residential areas. Congestion occurs at the freeway interchange and two other locations (A Street and B Street). During the afternoon commuter peak, traffic is heavy departing the freeway interchange, and congestion occurs at three locations, including east-bound left turns on Broadway east of the freeway at B Street and C Street. |
8.2.1.1.3 |
Operational objectives |
8.2.1.1.3-1 |
The agency has a policy of seeking smooth flow on arterial streets for routes that carry predominantly through traffic, and equitable distribution of green time at intersections that predominantly serve adjacent land uses. When congested, the agency seeks to avoid building queues on freeway off-ramps, and seeks to minimize queue spill out into through lanes. In the morning peak, the operation is designed to provide through progression approaching the freeway, and to maximize throughput at other intersections along Broadway approaching the interchange. During the afternoon peak, the operation is designed to control queue buildup on the northbound freeway off-ramp and frontage road in order to prevent queue backup onto the freeway. The operational objectives under these conditions are to:
|
8.2.1.1.4 |
Coordination and signal timing strategies |
8.2.1.1.4-1 |
The diamond interchange runs a TTI-four-phase operation from a single signal controller. The coordination approach for the morning peak is progression, maximizing bandwidth in the direction approaching the freeway interchange. This requires a 90-second cycle which provides good resonant progression in both directions, with 40% bandwidth efficiency in the peak direction, when side-street volumes are low. This cycle length also minimizes delay with no effect on throughput at the diamond, given that the lost time is offset by the internal double clearance, which means that increasing the cycle length does not increase throughput. The coordination approach in the afternoon peak is to maximize progression bandwidth leaving the interchange, except at X which is routinely congested and the agency seeks to allow queues to build on the side-street approach to maximize throughput on the arterial. Queue formation on the eastbound arterial approach to the freeway is allowed to maximize the green time and throughput for the northbound ramp approach. The signal timing strategies used by the system to accommodate this situation are:
|
8.2.1.1.5 |
Summary of Operation |
8.2.1.1.5-1 |
The actuated system will measure the traffic flow and determine when each of these operational objectives should be in force, and therefore which of the coordination and timing strategies to give priority to in making its adaptive decisions. The adaptive system will use the 90-second cycle in the morning peak to preserve resonant progression. The adaptive system will not alter the operation of the diamond interchange phase sequence. The adaptive system will seek to balance green time utilization when side-street demand is important, such as during the noon peak. The adaptive system will seek to minimize residual queuing at congested locations, preferring to build queue at x and y if demand cannot be accommodated. The adaptive system will prevent residual queue buildup on the freeway ramps. The adaptive system reports bandwidth, arrivals on red as a measure of bandwidth utilization, and phase utilization measurements that were used to adaptively adjust green times. |
8.2.1.2 |
Example: Arterial with one critical intersection |
8.2.1.2.1 |
Road network |
8.2.1.2.1-1 |
The section of Broadway Road to be coordinated using ASCT has six signalized intersections. It is a six lane arterial road with a two way left turn lane, and exclusive left turn lanes at each intersection. Most of the intersections provide access to local businesses and residential areas. However, one intersection (name of cross street) is an arterial road that accommodates regional traffic rather than providing local access. There are no nearby signals on this cross street that require coordination with this critical intersection. This is an eight-phase intersection with protected left turns on all approaches. The other intersections have permissive left turns on the side streets. Broadway is classified by the MPO as an arterial road of regional significance. |
8.2.1.2.2 |
Traffic conditions |
8.2.1.2.2-1 |
There is one critical intersection (Cross Street) that has heavier traffic than the other intersections at all times of the day. At its heaviest (typically during the AM and PM peaks) most movements are congested with occasional phase failures. Traffic is heaviest in one direction when these conditions are experienced, typically northbound during the AM peak and southbound during the PM peak. The traffic on Broadway is 50% heavier than the traffic on (Cross Street) during this condition. |
8.2.1.2.3 |
Operational objectives |
8.2.1.2.3-1 |
The operational objectives for this arterial under these conditions are to:
|
8.2.1.2.4 |
Coordination and signal timing strategies |
8.2.1.2.4-1 |
The signal timing strategies used by the system to accommodate this situation are:
|
8.2.1.2.5 |
Summary of operation |
8.2.1.2.5-1 |
Under these conditions, the ASCT system will select a phase arrangement and calculate phase times that accommodate traffic at the critical intersection. It will then set the timing at the other intersections to provide a green band in the direction of heaviest traffic along the arterial, to minimize the number of stops in that direction. The green time for the non-arterial phases at those intersections will be set to accommodate the traffic using those phases, while allocating the remaining time to the arterial road. The system will determine the sequence of phases on the arterial (lead-lead, lead-lag or lag-lag) that minimizes the stops in the non-coordinated direction under these conditions. |
8.2.1.3 |
Example: Arterial with several critical intersections |
8.2.1.3.1 |
Road network |
8.2.1.3.1-1 |
The section of Broadway Road to be coordinated using ASCT has ten signalized intersections. It is a six lane arterial road two way left turn lane, and exclusive left turn lanes at each intersection. Two intersections (name of cross streets) are arterial roads that accommodate regional traffic rather than providing local access. There are no nearby signals on the cross streets that require coordination with this critical intersection. One intersection provides access to a major shopping district. These are all eight-phase intersections with protected left turns on all approaches. The remaining intersections provide access to local businesses and residential areas. Those intersections have protected left turns on Broadway and permissive left turns on the side streets. Broadway is classified by the MPO as an arterial road of regional significance. |
8.2.1.3.2 |
Traffic conditions |
8.2.1.3.2-1 |
At times when traffic conditions are very heavy, one of the three key intersections is the critical intersection. This varies depending on the level of demand on the two crossing arterials or activity in the shopping district. When traffic is very heavy, it is typically heaviest on Broadway in one direction (such as northbound during the AM peak and southbound during the PM peak). In these conditions, Broadway carries higher volumes than the crossing arterials. |
8.2.1.3.3 |
Operational objectives |
8.2.1.3.3-1 |
The operational objectives for this arterial under these conditions are to:
|
8.2.1.3.4 |
Coordination and signal timing strategies |
8.2.1.3.4-1 |
The signal timing strategies used by the system to accommodate this situation are:
|
8.2.1.3.5 |
Summary of operation |
8.2.1.3.5-1 |
Under these conditions, the ASCT system will determine the critical intersection and select a phase arrangement and calculate phase times that accommodate traffic at that intersection. It will then set the timing at the other intersections to provide a green band in the direction of heaviest traffic along the arterial, to minimize the number of stops in that direction. The green time for the non-arterial phases at those intersections will be set to accommodate the traffic using those phases, while allocating the remaining time to the arterial road. The system will determine the sequence of phases on the arterial (lead-lead, lead-lag or lag-lag) that minimizes the stops in the non-coordinated direction under these conditions. |
8.2.1.4 |
Example: Crossing arterials |
8.2.1.4.1 |
Road network |
8.2.1.4.1-1 |
Broadway is an arterial road with seven signalized intersections. Cross Street is also an arterial road with five signalized intersections, and it crosses Broadway, as illustrated in the figure. |
8.2.1.4.2 |
Traffic conditions |
8.2.1.4.2-1 |
During heavy traffic conditions (such as AM and PM peak) the Broadway/Cross Street intersections is the critical intersection, and queues develop on all approaches. Typically the northbound direction on Broadway is significantly heavier than the southbound. Likewise, the eastbound traffic on Cross Street is significantly heavier that the westbound. |
8.2.1.4.3 |
Operational objectives |
8.2.1.4.3-1 |
The operational objectives for these arterials under these conditions are to:
|
8.2.1.4.4 |
Coordination and signal timing strategies |
8.2.1.4.4-1 |
The signal timing strategies used by the system to accommodate this situation are:
|
8.2.1.5 |
Example: Grid network |
8.2.1.5.1 |
Road network |
8.2.1.5.1-1 |
The intersections to be coordinated are on a grid network with relatively fixed intersection spacing. The roads typically have four lanes plus separate left turn bays at intersections. Based on the intersection spacing and typical mid-block vehicle speeds, there is a resonant cycle length of approximately 60 seconds that would provide coordination on most streets. This cycle length would also accommodate pedestrian movements at all intersections. |
8.2.1.5.2 |
Traffic conditions |
8.2.1.5.2-1 |
During heavy traffic conditions (such as peak shopping periods and PM peak hours), the demand at many of the intersections cannot be accommodated at the resonant cycle length. In addition, at key locations the block length is such that not all of the demand on some approaches can be stored in the approach block. |
8.2.1.5.3 |
Operational objectives |
8.2.1.5.3-1 |
The operational objectives for the streets in this network under these conditions are to:
|
8.2.1.5.4 |
Coordination and signal timing strategies |
8.2.1.5.4-1 |
The signal timing strategies used by the system to accommodate this situation are:
|
8.2.1.5.5 |
Summary of Operation |
8.2.1.5.5-1 |
The network will operate at a 60 second cycle length, because that has been determined to be a resonant cycle length at which two-way progression can be provided on the coordinated routes. The ASCT will select the most appropriate phase sequence at intersections where phase sequence is permitted to vary, and select phase times that accommodate all pedestrian activity and distribute green times to minimize phase failures, and implement offsets that provide progression along the coordinated routes. Because XX block is short, the offsets will be set so that when a coordinated platoon passes through A Street, it will always clear B Street, so the block is cleared and available to store turning traffic from A Street. |
8.2.2 |
Typical Heavy (Uncongested) Traffic |
8.2.2.1 |
Example: Isolated Intersection |
8.2.2.1.1 |
Road network |
8.2.2.1.1-1 |
A Road and B Road are two important limited access arterials that intersect and there are no other intersections sufficiently close that traffic flow would benefit from providing coordination. At the intersection, each road has three through lanes on each approach, dual left turn lanes and exclusive right turn lanes. Although pedestrian crosswalks are provided, there are rarely pedestrians at this isolated location. |
8.2.2.1.2 |
Traffic conditions |
8.2.2.1.2-1 |
Traffic is heavily directional during the commuter peaks. A Road is predominantly northbound during the AM and southbound during the PM, while B Road is predominantly eastbound during the AM and westbound during the PM. There is significant turning traffic in the peak directions. The left turn bays in the peak direction often overflow (east to north during the AM peak and west to south during the PM peak). There are occasional phase failures resulting in carryover queues at the end of phases. However, because of the high volumes and relatively long queues that form under vehicle-actuated (free) operation, there is a significant portion of each phase green during which the throughput is well below saturation flow, but not sufficiently low that phase gap-out occurs. The intersection delay (and therefore the LOS) would be improved by using a lower cycle length than can be achieved using normal vehicle-actuated operation. |
8.2.2.1.3 |
Operational objectives |
8.2.2.1.3-1 |
The operational objective for this case is to reduce delay by improving the efficiency of each phase. |
8.2.2.1.4 |
Coordination and signal timing strategies |
8.2.2.1.4-1 |
The signal timing strategies used by the system to accommodate this situation are:
|
8.2.2.1.5 |
Summary of Operation |
8.2.2.1.5-1 |
The adaptive system will measure the traffic flow and determine the appropriate cycle length and phase times to accommodate the current demand. When traffic volumes are sufficiently high, lead-lag operation will be selected for one or both approaches and unused time generally added to the phases serving the peak directions. |
8.2.3 |
Moderate balanced flows |
8.2.3.1 |
Arterial road with irregular spacing |
8.2.3.1.1 |
Road network |
8.2.3.1.1-1 |
The section of Broadway Road to be coordinated using ASCT has six signalized intersections. It is a six lane arterial road with a two way left turn lane, and exclusive left turn lanes at each intersection. Most of the intersections provide access to local businesses and residential areas. However, one intersection (Cross Street) is an arterial road that accommodates regional traffic rather than providing local access. There are no nearby signals on this cross street that require coordination with this critical intersection. This is an eight-phase intersection with protected left turns on all approaches. The other intersections have permissive left turns on the side streets. There is no regular spacing between the intersections and therefore no "resonant" cycle length. Broadway is classified by the MPO as an arterial road of regional significance. |
8.2.3.1.2 |
Traffic conditions |
8.2.3.1.2-1 |
During business hours traffic uncongested and the flows along Broadway are similar in both directions. At lunch time there is an increase in traffic turning into and out of the several side streets that service local shops and restaurants. There is little pedestrian activity except at Cross Street where there are bus stops and local shops. There is enough side street and turning movement traffic that most signal phases are called every cycle. The left turn volumes are sufficiently high that they need protected turn phases to provide sufficiently capacity and prevent phase failures. |
8.2.3.1.3 |
Operational objectives |
8.2.3.1.3-1 |
The operational objectives for this condition are to:
|
8.2.3.1.4 |
Coordination and signal timing strategies |
8.2.3.1.4-1 |
The coordination approach for these conditions is provide progression, maximizing bandwidth while providing two- way coordination. This can be done at a resonant cycle length of 80 seconds. The strategies applied while maintaining this cycle length are:
|
8.2.3.1.5 |
Summary of Operation |
8.2.3.1.5-1 |
The critical intersection will determine the minimum cycle length that can be used for the entire group. This cycle length will accommodate all phases and all pedestrian movements. Provided it is not higher than the 90 second resonant cycle length, the system will set the cycle length to be 90 seconds. It will detect the balanced flows and select offsets that provide a reasonable compromise between the two directions of travel. At the non-critical intersections, the non-coordinated phases will be set to accommodate pedestrians and vehicles, and all spare time will allocated to the coordinated phases to maximize the bandwidth for progression bands along the road. During periods (such as lunch time) when there is more turning traffic associated with local retail activity) extra time will be provided to those phases within the overall cycle length, at the expense of the coordinated phases on Broadway. |
8.2.4 |
Light Balanced Flows |
8.2.4.1 |
Arterial Road |
8.2.4.1.1 |
Road network |
8.2.4.1.1-1 |
The section of Broadway Road to be coordinated using ASCT has six signalized intersections. It is a six lane arterial road with a two way left turn lane, and exclusive left turn lanes at each intersection. Most of the intersections provide access to local businesses and residential areas. However, one intersection (Cross Street) is an arterial road that accommodates regional traffic rather than providing local access. There are no nearby signals on this cross street that require coordination with this critical intersection. This is an eight-phase intersection with protected left turns on all approaches. The other intersections have permissive left turns on the side streets. Broadway is classified by the MPO as an arterial road of regional significance. |
8.2.4.1.2 |
Traffic conditions |
8.2.4.1.2-1 |
During some periods of the weekdays and weekends traffic is light but predominantly passing along the arterial. There is little pedestrian activity and little side street and turning movement traffic. The left turn volumes are sufficiently light that they do not need protected turn phases to provide sufficiently capacity, and can normally be accommodated by permissive phases. There is a resonant cycle length of 45 seconds that will provide two-way coordination when the protected left turn phases are omitted. |
8.2.4.1.3 |
Operational objectives |
8.2.4.1.3-1 |
The operational objectives for this condition are to:
|
8.2.4.1.4 |
Coordination and signal timing strategies |
8.2.4.1.4-1 |
The coordination approach for this condition is to provide progression along the arterial, maximizing bandwidth while providing two-way coordination. The timing strategies applied to do this are:
|
8.2.4.1.5 |
Summary of Operation |
8.2.4.1.5-1 |
During light traffic conditions, protected left turn phases will be omitted and a cycle length of 45 seconds implemented. If traffic volumes decrease (such as during late nights), the 45 second cycle length and two-way coordination will be maintained unless the volumes fall below a minimum threshold, in which case the signals will be set to operate in free, vehicle-actuated mode. If traffic increases to the extent that it can no longer be accommodated within the 45 second cycle length, or left turning volumes can no longer be accommodated without the protected left turns, then a longer cycle length will be implemented and a new coordination strategy selected to match the current traffic conditions. |
8.2.5 |
Demand affecting event |
8.2.5.1 |
High travel day (e.g., Mothers' Day, Superbowl) |
8.2.5.1-1 |
During periods of major activity within or close to the ASCT's area of operation, the traffic characteristics are often similar to the peak periods, either oversaturated or unsaturated. The system will behave in a similar fashion to those periods, and the detection system will determine whether unsaturated or oversaturated conditions prevail. If there is heavily directional traffic before or after the activity, the system will determine the predominant direction and coordinate accordingly, with an appropriate cycle length and offset. If the event traffic is not as heavy as peak hours, but the traffic on the corridor is still highly directional, then the system will recognize this and provide coordination predominantly in the heaviest direction, even though the cycle length may be similar to business hours (with balanced flows) cycle lengths. |
8.2.6 |
Capacity affecting event |
8.2.6.1 |
Incident within the system (construction, maintenance, fire, weather) |
8.2.6.1-1 |
When an incident occurs on the coordinated route and temporarily reduces the capacity of the route (such as emergency vehicles stopped, unscheduled construction/maintenance, or traffic crash), there will typically be congestion upstream of the blockage, and lighter than normal traffic downstream. In such a situation, it is appropriate for the downstream signals to operate with different characteristics from the upstream signals. |
8.2.7 |
Fault Conditions |
8.2.7.1 |
Communications Fault Condition |
8.2.7.1-1 |
If a communication failure prevents the adaptive system from continuing to control one or more intersections within a defined group, all signals within the group will revert to an appropriate, user-specified fallback mode of operation, either time-of-day operation or free operation. The fallback mode will be specified by the user based on location and time of day. All communication failure alarms will be automatically transmitted to maintenance and operations staff for appropriate attention. |
8.2.7.2 |
Detection Fault Condition |
8.2.7.2-1 |
The system will recognize a detector failure and take appropriate action to accommodate the missing data. For a local detector failure, the local controller will place a soft recall or maximum recall (to be user-specified) on the appropriate phase, and issue an alarm. For a detector that influences the adaptive operation (e.g., a system detector), the system will use data from an alternate (user-specified) detector, such as in an adjacent lane or at an appropriate upstream or downstream location. If the number of detector failures within a specified group exceeds a user- specified threshold, the system will cease adaptive operation and go to a fallback operation specified by the user (such as time-of-day operation or free operation). The fallback operation will be specified by the user based on location and time of day. All detector failure alarms will be automatically transmitted to maintenance and operations staff for appropriate attention. |
8.2.8 |
Priority and Preemption |
8.2.8.1 |
Railroad Preemption |
8.2.8.1.1 |
EXAMPLE PREEMPTION SCENARIO. |
8.2.8.1.1-1 |
XX arterial runs north-south and there are gated railroad grade crossings on several of the east-west routes that cross XX Arterial, namely XX Blvd and XX St. The rail line is approximately XXft. to the east of XX Arterial. The railroad gated crossing preempts the signals at XX intersection and also XX (TWO INTERSECTIONS ON THE ARTERIAL). Upon preemption, the signals on XX arterial introduce a clearance phase, to ensure any vehicles queued on or close to the railroad tracks can clear before the gates descend. Upon completion of the clearance interval, the signal continues limited operation. The phases that would normally send traffic in the direction of the grade crossing are inhibited until the gates are raised. Once the clearance sequence is completed, the signal returns to normal operation. There is also a queue detector on the eastbound departure side of XX Arterial, which detects the presence of a queue approaching the grade crossing when the gates are lowered. If such a queue is detected, the phases that normally send traffic in the direction of the grade crossing are inhibited as long as the gates remain lowered. When an intersection responds to railroad preemption, all signals within the coordinated group are released to local control, and operate according to a time-of-day schedule. Once the preemption is released, all the signals in the coordinated group return to adaptive control. |
8.2.8.2 |
Light Rail Priority |
8.2.8.2.1 |
EXAMPLE LIGHT RAIL PRIORITY SCENARIO. |
8.2.8.2.1-1 |
LRT priority will be provided at each intersection on an LRT route. The input requesting priority will come EITHER from the centralized priority system The system will have the capability to extend the existing green if that will serve the LRV, introduce an early green by shortening or skipping other phases, or run a phase called exclusively by the LRV. |
8.2.8.3 |
Bus Signal Priority |
8.2.8.3.1 |
EXAMPLE BUS PRIORITY SCENARIO. |
8.2.8.3.1-1 |
Bus priority will be provided at each intersection on a bus route. The input requesting priority will come from the centralized priority system. |
8.2.8.4 |
Emergency Vehicle Preemption |
8.2.8.4-1 |
When an intersection responds to an EV preemption, other signals within the coordinated group continue to operate adaptively. The preempted signal returns to adaptive control once the preemption is released. |
8.2.9 |
Scheduled Events |
8.2.9-1 |
The system will recognize the increasing traffic as patrons arrive for the event and adopt an appropriate mode of operation. During the event, when there is little associated traffic, the system will recognize the traffic conditions and operate normally, then recognize the changing traffic pattern as patrons begin to leave the event and adopt the appropriate mode of operation until the traffic clears. |
8.2.10 |
Pedestrians |
8.2.10-1 |
Pedestrian crossing times must be accommodated. At locations with wide pedestrian crosswalks and a history of conflicts between turning vehicles and pedestrians, the pedestrian walk is displayed some seconds before the compatible vehicle green. At crosswalks with high pedestrian volumes, a pedestrian recall is used during the periods when the pedestrian volumes are high. Pedestrian recall is used for pedestrian phases that are adjacent to the coordinated movements. |
8.2.11 |
Installation |
8.2.11-1 |
During installation and fine tuning, the operator will calibrate all the user-defined values in the system. In order to understand the response of the system to changes in traffic conditions, it is necessary to examine the results of intermediate calculations, in addition to the overall outputs and changes of state commanded by the system. |
