Model Systems Engineering Documents for Central Traffic Signal Systems
Chapter 1. Concept of Use
Purpose
The primary objective of this Central Traffic Signal Systems (CTSS) Systems Concept of Use (COU) is to describe how the Systems Engineering (SE) Model Documents can guide the deployment of a central traffic signal system. The development of the COU ensures the procured and deployed CTSS is successfully meeting the user needs of the stakeholders who will be using the CTSS to convey information to the traveling public. The purpose of the SE Model Documents is to guide the user through the process of developing systems engineering documents for definition and procurement of a CTSS. The CTSS may be a brand-new deployment or an expansion of an existing system.
The Model Systems Engineering Documents for Central Traffic Signal Systems are intended for projects with the following characteristics:
- Relatively small, such that the project budget cannot be reasonably expected to fund systems engineering document development from scratch.
- Constrained to existing products in the market. The model documents are not intended to provide the detail necessary to support new significant software development.
- Applications of CTSS already well-defined in the transportation industry.
Agencies building large projects with custom software development or innovative applications will need to perform more detailed custom systems engineering, though these documents may provide an effective and time-saving starting point for that effort. For projects developing new approaches or new levels of integration, agencies should consider which systems engineering approach is best suited to the project. The approach contained in this document expects the user to fully understand their operational intentions, and to be able to find products already in the marketplace that support those intentions. For operational approaches where those intentions are not yet clear or where new products and approaches have to be developed, the agency may consider an iterative process as an alternative to approach used in these documents.
The reference architecture for a Central Traffic Signal System along with the scope of the CTSS Model Systems Engineering Documents is shown in Figure 1.
The scope of this diagram includes central system components, including the CRSS Management System and optional automated traffic signal performance measurement processors and adaptive signal control technologies processors. Those two optional processes may also be located on separate servers or be configured as independent software systems from the CTSS. The scope also includes any field-located adaptive traffic signal processors. Not included in the scope of this document are external probe data services, special detectors used for adaptive processing or performance measurement, external systems to which the CTSS may interface, connected-vehicle back-office processors, vehicle-based equipment, and field equipment including the signal controller. Subsequent text describes other aspects of this diagram.
Figure 1. Reference Architecture for a Central Traffic Signal System with the scope of the CTSS Model SE Documents
The scope of the architecture shown in Figure 1 includes central systems only, and generally not field equipment noted by the brown dashed line denoting the scope of these model documents. One exception is an adaptive processor located in a field cabinet. The requirements herein cover the adaptive operation handled by that processor, but assume regular signal systems functions will be performed in a central system. The black dashed lines around many of the surrounding boxes indicate optional capabilities/systems. Within the CTSS Management System are optional Automated Traffic Signal Performance Monitoring (ATSPM) and Adaptive Signal Control Technology (ASCT) functionalities that can be implemented internally to the CTSS Management System or separately as shown by the ASCT/Adaptive Processor and ATSPM systems.
Another variation on the scope concerns signal system master (SSM) controllers, if used. If a system uses a SSM, then the SSM is acting as a field-located surrogate for many functions of the central system, and many of the requirements that apply to the central system will also apply to the SSM. But this document does not address that architecture specifically. The user should reference the Protocol Requirements List in National Transportation Communications for Intelligent Transportation System Protocol (NTCIP) 1210, which covers needs and requirements for communications with field masters (and thus allows configuration of signal-system functionality that the SSM will manage) to tailor needs and requirements in this document for SSM architectures.
Vehicle-based technologies are not included in the scope of this document, but interfaces to it are shown in the reference architecture.
It should be emphasized that this document does not cover requirements related to selecting traffic signal controllers, though it does cover functionalities that local controllers will be expected to support. When faced with a local-controller selection task, the reader is encouraged to use the requirements herein to supplement whatever process is used to make that selection. Given the standard feature set generally available in the market, it is likely that any controller on the market will support the range of needs agencies face at the intersection level, though those agencies may have preferences about how those features are implemented. For cases that require special features, the reader is encouraged to develop requirements related to those special cases. One approach for doing this will be supported by NTCIP 1202, which is being updated as of this writing. The updated standard will include a Protocol Requirements List, which provides a tool for agencies to identify their needs as related to communications with local signal controllers. Given that most signal controllers work from signal timing parameters which are communicated via the interface covered by NTCIP 1202, that Protocol Requirements List will cover the vast majority of features and agencies, leaving the few special features to be handled separately. The reader will benefit from going through this model document for systems-related requirements before entering the Protocol Requirements List in the updated NTCIP 1202.
Process
The target audience for this COU includes transportation agency professionals needing to procure relatively small-scale central traffic signal systems by following a standardized systems engineering process without the need to hire a consultant. The COU will help an agency align their processes, operations and needs with the CTSS System Engineering Model Documents, allowing the tailoring of the model document content.
This process will lead to a set of user needs, requirements, verification plan and validation plan to support a successful procurement of a central traffic signal system. A successful procurement results in a central traffic signal system that not only meets the agency's needs but also provides a basis for ensuring that the procured system meets its advertised capabilities.
The overall framework for the set of SE Model Documents is depicted in Figure 2 below.
The inner Vee diagram contains the Concept of Operations on the top left followed by the Requirements below it, followed by Design with Implementation on the bottom of the Vee. Traversing up the right side of the Vee from Implementation is Subsystem Testing, followed by System Verification. followed by System Validation. There are two double sided arrows in the center of the Vee connecting Concept of Operations with System Validation and Requirements with System Verification. In the outer Vee diagram, there are four arrows with content in them pointing to the inner Vee diagram. The first arrow on the top left is labeled ConOps Guidance (Chapter 2) and Sample Statements (Appendix A) and is pointed to Concept of Operations. The second arrow on the bottom left is labeled Requirements Guidance (Chapter 3) and Sample Statements (Appendix B) and Sample Verification Methods (Appendix C) is pointed to Requirements. The third arrow on the bottom right is labeled Verification Plan Guidance (Chapter 4) and Sample Cases (Appendix D) and is pointed to System Verification. The fourth arrow on the top right is labeled Validation plan Guidance (Chapter 5) and Sample Cases (Appendix E) and is pointed to System Validation.Figure 2. Concept of Use Process for SE Model Documents
The CTSS SE Model Documents begin with creating a Concept of Operations capturing typical representative use cases, and operational scenarios involving central traffic signal systems. Use cases capture the system actors and activities to accomplish a specific purpose. An actor defines a role, which may be filled by a person, a group of people, or an external system. The actors form the foundation for the definition of the users of the system and are critical to the high-level use cases, operational scenarios and user needs. Operational scenarios provide examples in narrative form of how those users, activities and systems work together in actual practice.
The ensuing analysis of the use cases, and operational scenarios lead directly to draft user needs (all embodied in the Concept of Operations), and the beginning of system validation cases validating the user needs documented in the Validation Plan. The user needs drive the definition of the requirements and the requirements verification methods (residing in the Requirements document) and a requirements Verification Plan. These have been previously reviewed and validated by operational CTSS Subject Matter Experts (SMEs). The CTSS SE Model Documents walk the user through the process of selecting and tailoring the pertinent use cases and operational scenarios to arrive at a set of user needs. Since the systems engineering process is being used, there is forward and backward traceability between the resulting user needs and the requirements. The verification plan and the requirements verification methods are directly traceable back to the requirements being verified. Correspondingly, the validation plan is directly traceable back to the user needs being validated.
The CTSS Model Systems Engineering Documents will provide an agency with a means to describe their existing and planned central traffic signal system operations using substantive systems engineering products. The user will tailor the needs and requirements provided in the model. The process will provide meaningful systems engineering support for a CTSS procurement with far less effort than developing systems engineering documents from scratch. The user will still be expected to understand their processes in applying a CTSS to solve their transportation management problems, but the model documents will provide guidance to the user to help them do so.
Concept of Operations
The first product of the application of the model documents will be a Concept of Operations for a central traffic signal system. The Concept of Operations (ConOps) is written from the perspective of the system 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 that the stakeholder community 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 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, test procedures and processes and validation plan, 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. It is the basis for validating (via the Validation Plan) the system when delivered to ensure that the system is acceptable, with "acceptable" being defined as fulfilling all the user needs. The guidance for the Concept of Operations can be found in Chapter 2 of this guidance document.
Requirements Document
After the ConOps is defined, corresponding system requirements are captured in the Central Traffic Signal System Requirements Document. The requirements document targets technical staff, system users, system designers and vendors. The ConOps describes what the users will do, and the requirements define what the system must do. Each of the requirements listed in this document must be linked to a corresponding need described in the ConOps. Every need in the ConOps must be linked to one or more requirements in the Requirements Document. The forward and backward traceability between needs and requirements makes it possible to define needed requirements during procurement, and to defend requirements if they are challenged during procurement. The Requirements Document becomes the principal systems engineering document during the procurement process, providing the basis for selection, progress verification, (in some cases) payment, and system acceptance.
Once the user has selected and defined their user needs, the SE Model Documents provide system requirements that are linked to those user needs. The guidance in the model documents will assist agency users in tailoring the model needs and requirements as needed, including any needed iteration between needs and requirements. During tailoring, you will need to iterate between needs and requirements to ensure that they remain traceable and consistent. Traceability ensures that each need is fully represented in the requirements, and each requirement is fully driven by needs. Consistency ensures that what is stated in the requirements will satisfy the user needs to which they are traced. Once all the needs and requirements are tailored for the specific project and checked for traceability and consistency, the ConOps and the Requirements documents will be complete and correct.
The Central Traffic Signal Systems Requirement Document does not define the design of the system, nor does it determine what technologies to use or how to implement them. This document sets the technical criteria that will be used to evaluate design and technology choices. It is the basis for verifying (via the Verification Plan) the system during design and when delivered to ensure that the system is acceptable, with "acceptable" being defined as fulfilling all the requirements. The recommended approach is to have an Acceptance Test of the procured system based on the system requirements. The guidance for the Requirements Document can be found in Chapter 3 of this guidance document.
Verification Plan
This leads to the third document that the user will develop using the Model Documents, the Central Traffic Signal System Verification Plan. The Verification Plan is responsible for defining the verification testing that will demonstrate fulfillment of requirements. The target audience for
this document is the same as for the Requirements document. Generally, the implementing contractor will be responsible to fulfill the requirements. The Verification Plan describes the general verification effort including verification cases with corresponding requirements being fulfilled, including the method by which that determination will be made. It is critical that all requirements are verified within the scope of the Verification Plan. This is best done by tracing each requirement into a verification case and eventually into appropriate steps in the verification procedures. The Model Documents provide a direct mapping of verification cases to the requirements. The user simply needs to extract and tailor the corresponding verification cases related to the chosen set of requirements.
The Verification Plan does not describe detailed procedures for testing the Central Traffic Signal System. It is typical that the system developer/supplier/vendor will develop the verification test procedures that will map to the verification plan as part of the procurement process. The specific steps of a verification test procedure require a knowledge of the specific software and hardware technology and products that will be implemented. The guidance for the Verification Plan can be found in Chapter 4 of this guidance document.
Validation Plan
The fourth document that the user will develop using the Model Documents is the CTSS Validation Plan. The Validation Plan is responsible for defining the validation testing that will demonstrate that the system meets the user needs. The target audience for this document is the same as for the Concept of Operations (ConOps) document. Generally, the implementing contractor will not be responsible for validation. The Validation Plan describes the general validation effort including validation cases with corresponding user needs being fulfilled. The Model Documents provide a direct mapping of validation cases to the user needs categories. The user simply needs to extract and tailor the corresponding validation cases related to the chosen set of user needs.
The Validation Plan does not describe detailed procedures for validation testing of the Central Traffic Signal System. Typically, once the CTSS has been accepted, the users of the system will validate if the system meets their user needs according to the Validation Plan and subsequent validation procedures. The guidance for the Validation Plan can be found in Chapter 5 of this guidance document.
Procurement
Finally, the guidance within the model documents includes a general discussion of procurement approaches, and how the products of the systems engineering process support various procurement processes. The guidance for procurement can be found in Chapter 6 of this guidance document.
Assembling Your Documents
The finished product of your efforts will be several systems engineering documents. In order to successfully prepare these documents, you will need to take the following steps:
- Read this document completely.
- Begin to prepare the Concept of Operations. Establish chapters in accordance with the Concept of Operations Sample Statements in Appendix A. While you are free to format the document to suit your needs, the statements follow the outline suggested in American National Standards Institute (ANSI) standard G-043-1992. As an alternative, you may simply take the table of sample statements and check those statements you wish to include.
- Following the instructions in this document, copy and (only if necessary) edit relevant statements from the Table of Sample Statements for the Concept of Operations. Depending on how you answer each question in the guidance, select and edit each Concept of Operations statement. One should be cautious about editing the user needs too soon—the preferred approach is to make an initial selection first and then determine if gaps exist that require editing.
- Some sections of the Concept of Operations require you to write appropriate text in accordance with the instructions contained in this document.
- Each statement in the Concept of Operations table has a unique identifier. The needs statements (Chapter 4) each refer to at least one relevant System Requirement that should be considered to support the need statement. Each Concept of Operations statement also contains a reference to the relevant section of this Guidance Document.
- Begin to prepare the System Requirements. Establish chapters in accordance with the System Requirements template. As an alternative, you may choose to include the System Requirements as an appendix to the Concept of Operations. In this case, you may simply take the table of sample statements and check those statements you wish to include.
- For each need statement used from the Concept of Operations table, identify the System Requirements that are linked. Copy and edit each relevant requirement into the System Requirements document. Note that whenever you pick a "child" requirement, you should also select its "parent" requirement. You may also check off the requirements in the Model Requirements Document as they appear in the ConOps sample statements, rather than building a document from scratch.
- If you describe needs in the Concept of Operations that are not covered by these sample statements, then you must either also create new requirements related to those needs, or take separate actions to support those needs if they do not lead to system requirement.
- Prepare the Verification Plan. Establish chapters in accordance with the Verification Plan template. There is a suggested verification method for each System Requirement. Each high-level System Requirement also has an associated verification case name and description to get you started. Note that every System Requirement requires a verification test, which you will need to define to suit your situation.
- Prepare the Validation Plan. Establish chapters in accordance with the Validation Plan template. Note that every need expressed in the Concept of Operations requires a corresponding validation test, which you will need to define to suit your situation. If you define performance measurement in your requirements, some validation may be provided by the new system, while some may require separate off-line tests.
Summary
In summary, the Central Traffic Signal System Model Documents will provide documentation templates that will guide the user through the selection and insertion of applicable user needs, requirements, verification cases and validation cases that are consistent with each other. The Model Documents will provide guidance to the user on selecting operational CTSS system capabilities that fit within the use cases and operational scenarios. The focus of this guidance is to develop documents that will enable the agency to successfully procure a CTSS that is currently available in the product market. It should be stressed that the responsibility for preparation of these CTSS Systems Engineering documents rests entirely with the procuring agency.
