Model Systems Engineering Documents for Dynamic Message Sign (DMS) 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 established 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 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?
• 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.
• 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 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?
• 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 Conops Document)

The first product of the application of the model documents will be a Concept of Operations for a DMS 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 DMS, 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 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 brief summary to introduce the reader to the proposed system.

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 of this Model SE Document for DMS Systems document 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 strategic plans that drive the goals of 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 DMS System. 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 American National Standards Institute (ANSI), Institute of Electrical and Electronics Engineers (IEEE), National Transportation Communications for Intelligent Transportation System Protocol (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. 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 DMS 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.

General Actors

The general actors represent the various roles and systems that interact with the DMS 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 DMS System Maintainer and a DMS 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 DMS System use cases give the system operator the ability to better judge a transportation-related situation.

Operational Needs (Chapter 4 of the Conops Document)

In order to effectively manage the surface transportation system, operators need to be able to see the current conditions in order to detect problems, verify problems and ensure proper mitigation of the problems through various transportation management operations. A DMS System provides the operators with ability to inform the traveling public with a variety of information. This information can include advisory information such as incidents, road closures, estimated travel times, as well as regulatory information such as speed limits and available high occupancy vehicle (HOV) lane access requirements.

This chapter captures the stakeholder (including actual user/operator) needs and expectations answering the question "Why is a DMS System Needed?" 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 that the stakeholder community 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 additional specification and tailoring to the DMS System environment. The user needs indicate where this is necessary by square brackets “[specify]”.

Envisioned DMS System Overview (Chapter 5 of the Conops Document)

This chapter is an overview of the envisioned DMS system. It is a high-level description that will describe the main features and capabilities and the scope of its coverage. You should describe its conceptual architecture at a block diagram level with a high-level data flow diagram. This should not show design details. This description should reflect the needs that are 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.
• Type of DMS System operations.
• Interfaces to other systems (if any).

A good way of illustrating the system is to draw out the activities undertaken by stakeholders in a particular situation, and highlight those that are anticipated to be augmented with the operation of the DMS System. An example of such a diagram, based on the typical physical architecture in NTCIP 1203 and generated from RAD-IT, 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 DMS System Project Architecture results in a set of standardized communication protocol stacks for each triple (source element, information flow and destination element). An example of one of these communication protocol stack diagrams is shown in 4. The entire set of standardized communication protocol diagrams for each interface can be found in Appendix F.

DMS Document System Operational Environment (Chapter 6 of the Conops Document)

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

Operational Environment

Describe the stakeholders. These should include all existing stakeholders who have an influence on the operation of the proposed DMS System. This will include Traffic Management Center (TMC) operations staff, and staff of other agencies whose operation and duties may be affected by the envisioned DMS System.

The activities related to DMS System operation should be described, such as configuration, DMS sign characteristics, DMS message characteristics, system performance monitoring, 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 need.

For example, describe whether the equipment will be located in a TMC, at City Hall, at the corporation 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, 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).

DMS System Support Environment (Chapter 7 of the Conops)

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

Describe any additional test equipment and repair tools that will be needed to support DMS System operation. Where will test equipment be located?

Describe additional staff or contractors who will not be involved in the day-to-day operations 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 DMS System, or will need to be modified to include reference to the DMS System. 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 DMS System (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 takes into account the practical limitations of available systems, which you expect to be live with. 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.

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 enunciated.