Model Systems Engineering Documents for Central Traffic Signal Systems

Chapter 2. Concept of Operations Guidance

The Model Concept of Operations can be found in Appendix A. The chapters of the Model Concept of Operations, which are described in the sections below, follow a standard outline for concepts of operation established by the American National Standards Institute (ANSI/AIAA-G- 043). There are competing standardized outlines for concepts of operations, but the ANSI outline was determined to be the most appropriate for infrastructure construction projects that establish new capabilities.

While the layout of the Concept of Operations described in this guidance will provide a logical flow for the intended readers, it is generally not prepared in this sequence. As practical traffic engineers, it is generally preferable to describe at an early stage the operational scenarios envisioned by the system users/operators. After initially describing the limitations of the existing system, you should describe all the situations in which you expect the system to provide benefit, and how you expect the system to operate in each situation. After describing the operational scenarios, you will then be in a position to better describe the specific system and user needs, the alternative strategies considered and why they were discarded, and the envisioned system. Then you will be able to revise the operational scenarios so they are consistent with the statements of needs and provide clear examples of the expected operation. The scenarios, however, come at the end of the Concept of Operations, and are used as examples of how the earlier parts of the document play out in real situations. Experienced traffic signal system operators will want to review those scenarios, but they can probably proceed through sample statements in the order in which they are presented in Appendix A.

For readers, not familiar with traffic signal systems operation, note that this document is not intended as a tutorial on traffic signal systems. Other literature already provides descriptions of what traffic signal systems do and generally how they work, and these are recommended for background reading for those who are not already familiar with the topic.

The Concept of Operations will be organized in the following chapters, following the structure recommended in ANSI G-043-1992:

1. Scope.
2. Referenced documents.
3. User-Oriented operational description.
4. Operational needs.
5. System overview.
6. Operational environment.
7. Support environment.
8. Operational scenarios.

Once you have completed the Concept of Operation, use this checklist to confirm that all critical information has been included:

• Is the reason for developing or procuring the system clearly stated? Note that operations planning documents should already establish that 1.) a traffic signal system is needed, and 2.) why it is needed, as the basis for programming the project, especially if it uses Federal funds. The user of this document might not enter this process until project development is underway, and so should reference the documentation used to justify the project for programming. If these planning documents do not exist, then it becomes especially important for the ConOps to freshly establish the problem to be solved by building the system. The sample statements are usually sufficient to reinforce planning documents with references thereto and minimal amplification.
• Are all the stakeholders identified and their anticipated roles described? This should include anyone who will operate, maintain, build, manage, use, or otherwise be affected by the system. It is, however, limited to users—those who do have a role in actual use. Thus, it is about the agency's management of traffic signals more than it is about the operation of the traffic signals as perceived by travelers. The management of field devices is the principal reason for having a system. The exception to this perspective concerns adaptive operation, where the adaptive algorithm has a true operational role, rather than simply a device management, configuration, and monitoring role.
• Are alternative operational approaches (such as maintaining the current system capabilities or no system, as appropriate to your situation) described and the selected approach justified?
• Is the portion of the regional Intelligent Transportation System (ITS) architecture being implemented identified?
• Is the external environment described? Does it include required interfaces to existing systems, both internal and external to your agency?
• Is the support environment described? Does it include maintenance? Does it explain where the users will sit, and from where they must be able to access the system?
• Is the operational environment described?
• Are there clear and complete descriptions of normal operational scenarios?
• Are there clear and complete descriptions of maintenance and failure scenarios?
• Do the scenarios include the viewpoints of all involved stakeholders? Do they make it clear who is doing what?
• Are all constraints on the system identified?

Scope (Chapter 1 of the Concept of Operations Document)

The first product of the application of the model documents will be a Concept of Operations for a CTSS system. The Concept of Operations (ConOps) is written from the perspective of the system user/operator, and it establishes the activities of the user in solving the transportation management problem at hand, using CTSS, as the basis for defining and defending requirements. The primary audience for the ConOps includes stakeholders who will participate in the operation of the system or be directly affected by it. The ConOps is responsible for capturing the stakeholder needs and expectations in a manner that is easily understandable to the stakeholder community, so they can be confident that it properly models what they will do.

The needs and expectations must be defined succinctly enough to determine what functions the proposed system must be capable of fulfilling. Stakeholders who may play a role in tailoring or reviewing the ConOps may include system users/operators, maintenance staff, system managers, administrators, decision-makers, elected officials, and other non-technical readers. Every element of the subsequent documents in the project, including the requirements, verification plan, designs, and test procedures and processes, must be able to be traced to statements of user need in the Concept of Operation. Ultimately, the ConOps describes how the agency will use the system, and in that manner, could be considered a prototype for an operating policy and procedure.

Document Purpose and Scope

The first part of this chapter is a short statement of the purpose and scope of this document. This will briefly describe contents, intention, and audience. Sample statements that may be used in this chapter are contained in the Concept of Operations sample statements table in Appendix A. These statements should be customized to explicitly apply to your situation. One or two paragraphs will normally suffice.

Project Purpose and Scope

The second part of this chapter gives a brief overview of the purpose and scope of the system to be built. It includes a high-level description; describes what area will be covered by the project; and identifies which agencies will be involved, either directly or through interfaces. Sample statements that may be used in this chapter are contained in the Concept of Operations Sample Statements table. These statements should be customized to explicitly describe your project. One or two paragraphs will usually suffice. This section should be written late in the process, after the envisioned system has been described. It will be a summary to introduce the reader to the proposed system. Note that this section can (and should) reference and summarize planning documents that established the need for this project. Concepts of Operation are project documents, not planning documents, but must be built on a foundation of planning. Otherwise, the ConOps will have to include some remedial planning in the form of justifying why the project needs to be built. The intention is that this section can be a brief citation and a summary.

Procurement

The final section of this chapter will be a brief discussion of the proposed procurement process. The method of procurement should be determined early in this process, because it will have an impact on the format and content of the system requirements document. See Chapter 6 herein for additional information.

Referenced Documents (Chapter 2 of the ConOps Document)

This chapter is a place to list any supporting documentation and other resources that are useful in understanding the operations of the system. This could include any documentation of current operations and any operations plans that drive the objectives for building the system under development. In particular, it should include documents that define the overall goals and objectives of your agency that will be supported by the CTSS System, and the documents that justified funding for the project. These documents may be ITS strategic plans, Traffic Signal Management Plans, or similar. This includes local and regional transportation program and policy documents and relevant inter-agency, management and labor agreements and memoranda of understanding. It should reference the applicable statewide and/or regional ITS Architecture(s) and include relevant codes and standards, such as ANSI, Institute of Electrical and Electronics Engineers (IEEE), NTCIP, National Electrical Manufacturers Association (NEMA), Code of Federal Regulations (CFR) and National Electrical Code (NEC). It should also include references to detailed documentation of any required interfaces to other systems such as an Integrated Corridor Management (ICM) system. However, do not treat this as a bibliography. Only include documents that are referenced directly in the Concept of Operation, and that allow this document to summarize rather than reiterate. Sample statements that may be used in this section are contained in the Concept of Operations sample statements table (Appendix A).

User-Oriented Operational Description (Chapter 3 of the ConOps Document)

This chapter describes the operational problem to be solved and how a CTSS System helps the agency solve it. This is where we define the use cases related to application areas. When the use cases are selected in Chapter 3, it will guide you to which groups of user needs you need to select in Chapter 4, User Needs.

In the case of CTSS, the problems to be solved involve the agency's need to manage and maintain its traffic signal field infrastructure efficiently, which usually requires a remote access capability for programming and monitoring local traffic signal controllers. It also includes the agency's need to observe operational effectiveness in a way that supports improvement of the signal timings stored in local controllers. Finally, it includes the problem of tracking changes in traffic conditions that occur in ways traditional signal timing approaches cannot follow.

General Actors

The general actors represent the various roles and systems that interact with the CTSS System. 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 CTSS System Maintainer and a CTSS System User could be the same person or they could be different people.

Use Cases

Use cases capture the high-level typical interactions between an actor and a computer system. A use case needs to address a discrete goal of the actor/user. Besides the common use cases of system support (e.g., configuration, maintenance, etc.) the CTSS System use cases describe the user's activity in monitoring traffic signal effectiveness, making improvements in signal timing based on that monitoring, or in providing a system that monitors operation and makes improvements automatically.

Operational Needs (Chapter 4 of the ConOps Document)

Traffic signals are built to safely assign right of way to motorists, pedestrians, cyclists, and other users at intersections where lesser forms of control are inadequate. At the intersection, most operators seek to distribute the green time fairly and efficiently, according to a variety of optimization objectives. Operators also seek to move as many vehicles as possible through the intersection during periods of congestion, when the signal leaves growing residual queues. When intersections and the traffic they serve interact with each other, operators seek to coordinate the timing to provide smooth flow, or in congested conditions when smooth flow is not possible, to manage queues so that they form where they do the least damage at the network level.

Traffic signals may also be used as part of a corridor strategy to manage traffic diverting away from a freeway that is congested, usually as a result of an incident.

To attain these objectives, signal operators need to be able to manage the database of signal timings in local controllers, maintain the operational effectiveness of local controllers, monitor that operational effectiveness, and monitor the effectiveness of the signal timings. Agencies generally expect such operation to be performed remotely in addition to in the field.

This chapter captures the stakeholder (including actual user/operator) needs and expectations answering the question "How will we use a traffic signal system to attain our goals and objectives?" which sets the foundation for the system requirements. The stakeholder needs and expectations must be defined in a manner that is easily understandable to the stakeholder community, so they can be confident that it properly models what they will do.

Each high-level grouping of user needs in Chapter Four of Appendix A includes the statement "Choose the user needs in this group if you chose [any on this list of use cases] in Chapter Three". This is how the user needs relate back to the use cases. In most cases, the user needs were categorized specifically by their corresponding use case.

Some user needs and their corresponding system requirements will require that the user of this document provide additional specification and tailoring to their CTSS environment. The user needs indicate where this is necessary by square brackets "[specify]".

Envisioned CTSS System Overview (Chapter 5 of the ConOps Document)

This chapter is an overview of the envisioned CTSS. It describes, at a high-level, the main features, capabilities, and the scope of its coverage. The reader should describe its conceptual

architecture at a block diagram level with a high-level data flow diagram, which can be derived from the reference system architecture in Figure 1, or from a project architecture derived from the Regional ITS Architecture. This should not show design details. This description should reflect the needs described in the previous chapter. It should illustrate, either graphically or in words, each of the following categories of needs that are relevant:

• Network characteristics.
• Traffic signal system operating modes (i.e., will it require coordination, traffic-responsive plan selection, adaptive control, high-resolution performance measurement, etc.?)
• Interfaces to other systems.

A good way of illustrating the system is to draw out the activities undertaken by stakeholders in a specific situation, and highlight those that are anticipated to be augmented with the operation of the CTSS. An example of such a diagram, based on the typical physical architecture in NTCIP 1202, NTCIP 1210 and generated from the Regional Architecture Development for Intelligent Transportation (RAD-IT) (in which tool the project architecture can be derived from the Regional ITS Architecture), is illustrated in Figure 3.

Each interface between ITS elements in the architecture diagram can have multiple communications standards associated with it. Using the Systems Engineering Tool for Intelligent Transportation (SET-IT) tool and converting the CTSS System Project Architecture results in a set of standardized communication protocol stacks for each “triple” (a combination of source element, information flow and destination element). An example of one of these communication protocol stack diagrams is shown in Figure 4. The entire set of standardized communication protocol diagrams for each interface can be found in Appendix F.

CTSS System Operational Environment (Chapter 6 of the ConOps Document)

This chapter describes both the operational environment and the physical environment within which the CTSS will operate.

Operational Environment

Describe the stakeholders. These should include all existing stakeholders who have an influence on the operation of the proposed CTSS. This will include Traffic Management Center (TMC) operations staff, signal systems operators that may not be housed in a TMC, maintainers, and staff of other agencies whose operation and duties may be affected by the envisioned CTSS.

The activities related to CTSS operation should be described, such as configuration, signal controller database management, system monitoring, traffic performance measurement, system performance monitoring, security, and inter-agency staff interactions.

The organizational structure should be described, highlighting any changes from the existing arrangements that are envisioned. An overview of the qualifications and experience of personnel should be presented along with clear definition of any roles and responsibilities that would be undertaken by contractors, vendors, consultants and staff of other agencies.

Sample statements that may be used in this section are contained in the Concept of Operations sample statements table (Appendix A).

Physical Environment

This section describes the facilities within which equipment and personnel will be housed, additional furniture and equipment that will be required, new computing hardware and software that will be required, operational procedures for operating the system and any additional support that will be needed.

For example, describe whether the equipment will be located in a TMC, at City Hall, at the maintenance yard or signal shop and/or in the field. Will field equipment need to be field hardened or located within an air-conditioned environment? Will existing power supplies be adequate or will additional service, uninterruptible power supply (UPS) and battery backups be required?

Will the operators be on duty or available 24/7 or during limited hours? Describe their required experience, skills and additional training needs.

Sample statements that may be used in this section are contained in the Concept of Operations sample statements table (Appendix A).

CTSS Support Environment (Chapter 7 of the ConOps Document)

This chapter describes the current and planned physical support environment. Describe what support equipment, personnel, training and procedures currently exist, and explain those that need to be acquired or implemented.

Describe any additional test equipment and repair tools that will be needed to support CTSS operation. Where will test equipment be located? Staff and equipment for maintaining the system may or may not be located at a signal shop that maintains and repairs field controllers.

Describe additional staff or contractors who will not be involved in the day-to-day operation of the system, but will be needed to support the operators and maintenance staff. This should include staff from the system vendor and/or consultants, who will provide additional on-going training, periodically audit the system setup and performance and support expansion of the system in the future.

Where multiple agencies are involved, describe the support that will be provided by or to other agencies. This should include any existing or proposed memoranda of understanding or operations and maintenance agreements that will affect the CTSS, or will need to be modified to include reference to the CTSS. This may include modifying the policies and procedures of those agencies in addition to developing new policies and procedures within your agency.

Sample statements that may be used in this chapter are contained in the Concept of Operations sample statements table (Appendix A).

Proposed Operational Scenarios Using a CTSS (Chapter 8 of the ConOps Document)

The purpose of this chapter of the Concept of Operations document is to provide examples that illustrate how the system will be expected to operate and interface with the operators in typical circumstances. It is not intended to comprehensively describe the operation under all conditions. It is intended to illustrate to vendors, managers and decision-makers alike how you see your objectives being met by the system. This description is practically oriented and considers the practical limitations of available systems, which you expect to tolerate. It should not be a description of how you would like some imagined system to operate with no regard for the practical limitation of candidate systems, nor should it depend on staff resources and capabilities that are unlikely to be available when the system is in operation.

Each statement in a scenario should relate to a user need, although not all needs will be further described in a scenario. The statements in the description of each scenario do not directly generate requirements. Requirements are only generated from needs. The scenarios in the Concept of Operations sample statements table (Appendix A) simply provide examples of how the system meets some of the needs.

Once you have written the scenarios, if you are not satisfied that they describe an operation that will be adequate, you should then review your needs statements. If you wish to describe elements of the proposed operation that are not described by needs, then additional needs should be written.