Arterial Management Program

Model Systems Engineering Documents for Adaptive Signal Control Technology (ASCT) Systems

A. PREAMBLE

WHY USE SYSTEMS ENGINEERING?

To deploy adaptive control will ultimately require the procurement of equipment and software. Requirements describe to vendors what the agency intends to purchase so that they can propose and bid a solution. Requirements are based on the agency's needs. Systems engineering is a tool that helps the agency articulate its needs.

Federal requirements described in 23 CFR 940 mandate that systems engineering analysis be performed for all ITS systems deployed using Federal funds, and that the level of effort be commensurate with the scale of the project. Also, many ASCT products are considered for proprietary purchase, which, when using Federal funds, requires justification in accordance with 23 CFR 635.411. Proper systems engineering documentation provides such justification. This document will help you respond to those requirements, but more importantly will inform your decision-making process and increase the potential for outcomes that are consistent with and meet the expectations of your system's stakeholders.

PURPOSE OF THIS DOCUMENT

The purpose of this document is to guide the user through the process of developing systems engineering documents for assessment and selection of adaptive signal control technology (ASCT) systems. This document provides a structure within which you can examine your current operation (or the operation you expect to have within the near future), assess whether or not adaptive control is likely to address your issues, and then decide what type of adaptive control will be right for you. Templates are provided for the development of the systems engineering documents that are appropriate for your situation. There are instructions on how to select appropriate answers to questions, how to select statements from the examples that are provided, and what additional information you need to gather and include in the documents. This may lead you to prepare a set of requirements and a specification against which vendors may propose a solution; or it may lead you to identify one system that is particularly suitable for your needs. It may also lead you to the realization that you are not yet prepared or capable of operating an ASCT system.

There are two primary situations in which this document is intended to be used:

  • During the Planning Process: When you are planning to install an ASCT system, need to define the overall objectives for the system, and need to define it sufficiently clearly that a project can be included in the regional TIP; and
  • During the Engineering Process: Once a project has been programmed and funded, this guidebook may be used to fully define the project and prepare detailed requirements that are suitable for use in the procurement process. The focus of this guidance is to develop documents that will enable you to procure an ASCT system that is currently available from a vendor. It does not provide sufficient guidance to develop procurement documents for the development of a custom-built ASCT system. That would require much more detailed specification of subsystems, physical equipment and user interfaces.

WHY CONSIDER ASCT?

So you think adaptive signal control may be the solution you are looking for to improve your traffic signal operation. There are many reasons why you may consider that your signal operation could be improved. Let's first look at why you are dissatisfied with the current operation, or expect that it could be operated more efficiently and effectively. You may have existing time-of-day coordination patterns, operating on a fixed cycle length. While these operate satisfactorily much of the time, there are times when the traffic demand varies from that used to develop the timing plans, such as when special events cause the traffic to change, or incidents reduce the available capacity. Even in normal operation, the cycle length in operation at any time tends to be higher than needed for the current traffic volumes, except in the peak of the peaks. This is generally done because there is some variation from day to day in the actual volumes and it is better to err on the side of too long a cycle than too short a cycle. Such variation is often due to: the peaks being of variable duration; daytime traffic varying depending on retail and commercial activity or the popularity of sporting events; numbers of commuters varying with the state of the economy; and the different levels of commuting on normal workdays, national holidays and the numerous partial public holidays.

Traditional coordination plans, whether they are selected by time of day (TOD) or traffic responsive pattern selection (TRPS), also require maintenance. In many communities, traffic patterns change sufficiently within three years that the cost of completely reviewing and updating the timing plans is justified by the improvement in efficiency that results. Although you should not expect adaptive control to be "set and forget", you should expect at least less deterioration in efficiency between timing reviews. Most adaptive control systems operate on top of or in conjunction with many of the most basic low level foundational traffic control settings. Therefore these systems cannot overcome the impact of poorly selected basic timing settings and parameters. It is also particularly important to have up to date, good quality traffic signal control settings and appropriate plans programmed as backup plans that will be invoked if the adaptive control system fails or traffic would be better served by non-adaptive operation.

There are also numerous situations in which coordination of adjacent signals on a fixed cycle length is less satisfactory than some form of free, actuated operation. This may apply where you have several closely spaced intersections with markedly different natural cycle lengths. In such situations, queues from one intersection often affect the adjacent intersection if they are all run on a single, fixed cycle length, and a better alternative is to have certain phases at the lower-cycle length intersections maintain a fixed relationship with the critical intersection while it runs in free, actuated mode.

There is also one situation in which there is no need for coordination; a major isolated intersection. While such an intersection is typically operated in free, actuated mode, relying on gapping and volume-density settings to terminate phases, there are times when a lower, controlled cycle length would be more efficient, particularly if storage lanes are of limited length and queues sometimes overflow into adjacent lanes.

In each of the situations described above, adaptive signal control may offer an improvement over the existing operation. Not all adaptive systems have the same operating philosophies; some are intended as improvements over fixed cycle length coordination; some are applicable to isolated intersection operation; while others extend the actuated, coordinated concept.

There are also various philosophies applied to the architecture of adaptive systems, which will lead to important decisions about the overall management of your traffic signal system. The adaptive operation may be fully integrated into a complete traffic management system. It may be a module within a complete traffic system, or reside in a separate server that is integrated with a complete system. It may be in a separate system that operates completely in parallel with another vendor's traffic management system, or it may be a separate system that takes over control of local signals when it is operating. This process will help you identify your traffic signal system management requirements and then design your system so you can have both the adaptive operation you want and the signal management capabilities you need.

This process will also guide you through the very important steps of system and sub-system verification and system validation. The verification process ensures that the implemented system meets all the requirements you will set, that is, it works as you intended. The validation process measures the extent to which the system achieves the objectives you have set for it. That is, the extent to which transportation is improved by the ASCT in support of your mobility objectives.

While the implementation of ASCT will generally be expected to improve the performance of your traffic system, it is important to bear in mind that, regardless of what system you select, a considerable level of commitment and expertise will be required to realize the full potential of the system. You cannot expect it to be a "set and forget" process. In particular, routine maintenance and periodic or continual performance evaluation will be important elements of the ongoing operation and maintenance of your system.

HOW TO USE THIS DOCUMENT

Systems engineering promotes increased up-front planning and system definition prior to technology identification, selection and implementation. Documenting stakeholder needs and expectations, the way the system is to operate (Concept of Operations), and WHAT the system is to do (the System Requirements) prior to implementation leads to improved system quality.1 Sections B and C of this document provide you with an overview of the process and a summary of what the final products will look like. Sections D through G will lead you through the development of the documentation by asking questions and requiring you to gather specific information about your agency situation. If you have an existing situation that you would like to improve, answer the questions based on what currently exists. If you know that conditions will change in the near future (e.g., a major new traffic generator is planned to be developed, the road network will change or gradual but significant changes in traffic patterns are expected), then answer the questions based on your expectation of the new situation. The relationships between the various sections of this guidance document are illustrated in Figure 1.

Figure 1. Sections of this document
Diagram shows that this document is broken into three parts: General Guidance, which compries the Executive Summary, Preamble, Overview of the Process, and Systems engineering Documents; Detailed Guidance for products of this process, which is broken down into chapters on Concept of Operations, System Requirements, Verification Plan, and Validation Plan; and the Appendices, which include templates, scenarios, and tables of sample statements.

You will identify constraints (limitations within which you must work), and you will develop requirements that respond to your documented needs and objectives. Be careful not to confuse constraints with requirements. This is a very important distinction, and requires careful differentiation. The requirements that you will select or develop as part of this process should be related entirely to the manner in which you want the system to operate and how you want to interact with the system.

The first phase of this process will help you define what the system needs to do, not how it will do it. The second phase of the process will allow you to identify the constraints that may be placed on the system design and/or selection, and will allow you to then decide whether some or all of those constraints can be overcome, or whether they will affect the design. At this point you will know what would be required to overcome a constraint, and what the trade-off will be if you decide to accept the constraint, which will then become a non-functional requirement.

A prime example of a constraint that is often initially (and incorrectly) identified as a requirement is the type of controller that will be used. An early decision to retain your existing controller under any circumstances unnecessarily constrains your considerations and hides the trade-off that you are implicitly making between system capabilities and non-functional constraints.

The third phase of the process will then allow you to decide how the system should achieve your objectives, and represents the design phase. A fourth phase will provide the program to verify and validate that the system you procure actually provides the service detailed in the Concept of Operations and Requirements or in other words ensures you get what you paid for.

While it is impossible to definitively estimate the amount of time it will take you to prepare these system engineering documents, and it will vary greatly depending on the size and complexity of the location(s) in which you are considering ASCT, an experienced traffic signal system operator should be able to make a first pass through the Concept of Operations statements and system requirements in one or two days. This first pass will give you a good indication of the likely suitability of ASCT to your situation, and also an indication of the type of ASCT that will be applicable. The length of time required to gather complete data to document your existing situation, needs, deficiencies and proposed operation will be very dependent on the quality and availability of information, the number of stakeholders involved and the complexity of the issues you wish to address.

1 CA Systems Engineering Guidebook for Intelligent Transportation Systems Version 3.0 November 2009 https://www.fhwa.dot.gov/cadiv/segb/


previous | next
Office of Operations