The Concept of Operations

The role of the ConOps in the SEP is to describe how the delivered system will work in lay terms from the stakeholders’ viewpoint. Typically, system operation is described from four stakeholder viewpoints: the system user, the system operator, the system maintainer, and the system manager. The purpose of the ConOps is to convey to the stakeholders a vision of how the system will be implemented and what impact it will have on them. When done properly, the ConOps is instrumental in achieving consensus among the stakeholders on the vision for the system and a common set of user needs. This needs to be done very early in the SEP and is usually accomplished within two months of the project start. The process of developing the ConOps is described in detail in Section 5 and a template is provided in Appendix R of this document for the ITS project engineer’s use.

3.3.3.4.1 Regional Concept of Operations

A ConOps can be developed on any level, from project specific to statewide and regional, and its focus will shift depending on what level it is developed for. The white paper titled Regional Concepts of Operations for Transportation System Management and Operations26 discusses the ConOps from the regional level and focuses more on operating relationships among the regional ITS stakeholders. The type of ConOps described in Florida’s Statewide SEMP is project level, and should be used to refine stakeholder expectations and obtain consensus on a project vision.

3.3.3.4.2 Project Concept of Operations

A project ConOps states the problem to be solved and creates a hypothetical system composed of functions that are used to describe how the system will address stakeholder needs. Writing the ConOps is an iterative process that generates functional requirements from the system level down to the component level and below, and verifies them with the stakeholders. Often, portions of the ConOps become outreach materials to educate the public and others about what is being designed and built.

26 _{Federal Highway Administration, White Paper: Regional Concepts of Operations for Transportation System}

Version 2 – March 7, 2005 34 The recommended way to write a project ConOps is to do it while the HIPO analysis process is being used to decompose the system functions into lower level components. Create the first two levels of the system HIPO analysis using the RITSA market packages as much as possible, and then start writing a description of how it works, what data flows into the boxes, and what happens to the data to become outputs. As the writing progresses, the engineer will think of additional functional details that needs to be addressed. Often, the engineer will discover that certain inputs are needed external to the system to support a process within the system, or the engineer will reach an impasse in describing system operation based on the functions as they are diagrammed. This could be an indication that the system boundaries and constraints have not yet been fully identified, and a further examination of the RITSA or even the SITSA is needed, or the conceptual architecture needs to be discussed with the stakeholders.

The ConOps document states the problem to be solved, assumes a system has been built that meets all the stakeholders’ needs, and describes its operation based on the four stakeholder viewpoints. It is important that this section be read and understood by all the stakeholders, so it should be easy to read and understand, and should not be too technical. What has been effective in previous ITS ConOps documents is to write the description of the system operation like a short story that takes the time line of the story and shows it from the viewpoint of each of the four stakeholder groups. Consideration should be paid to the system operation description in all conditions of the environment in which it will operate.

3.3.3.4.3 Utilization Environment

The SEP requires that the ITS project engineering team define the utilization environments for each of the operational scenarios. All environmental factors, natural or induced, that may affect system performance should be identified and defined. Factors are identified that ensure that the system minimizes the potential for human or machine errors, or failures that cause injurious accidents or death, and that pose minimal risk of death, injury, or acute chronic illness, disability, or reduced job performance of the humans who support the system life cycle.

As applied to ITS, defining utilization environments could include, for example, operating a traffic management system under normal, incident, and emergency conditions; or operating a transit system during weekdays, weekends, or special events.

Version 2 – March 7, 2005 35 After the hypothetical system’s operation is described, the HIPO analysis diagrams and the appropriate market packages that were integrated in the diagrams are presented to show how the system can do everything that was described in the story line. In the SEP, these diagrams are called system functional block diagrams. This will tie system capabilities to system functional components in the mind of the stakeholder. Stakeholder expectations may also be tempered by cost considerations, so the ConOps is an excellent way to convey the expected cost of the system to the stakeholder and offer alternative approaches. The cost data in a ConOps is called a rough order of magnitude (ROM) price and is intended to give a ballpark estimate of what the system could cost. Typically, a ROM reflects a higher price than what is really expected so as not to surprise the stakeholders as the system is procured. Finally, the ConOps should restate the user needs and the top-level system requirements that satisfy those needs. Typically, the draft ConOps is reviewed at the SRR. (Refer to Section 4.6.1.1.3 of this document.)

At this point in the SEP, the ITS project team should have a solid understanding of the stakeholder needs and a functional system architecture that satisfies that need along with a set of top-level system functional requirements linked to the stakeholder needs. The next step in the SEP is to use the SITSA to structure the system architecture and select the applicable standards. There are two ways to proceed in defining the ITS project architecture. The FHWA’s Rule 940 requires that it use the NITSA and other derivations of it to develop the ITS architecture for a particular project. (Refer to Appendix D.) If the ITS project is based on a RITSA, the architecture may already be defined and easily used for the particular project. If the ITS project engineer has a good understanding of the SEP and is comfortable using the Turbo Architecture tool, then the specific ITS project architecture can be refined using the SITSA with the Turbo Architecture software along with data flows, requirements, and other elements of ITS design. However, if the fundamental structure of the NITSA and RITSA, and the use of the Turbo Architecture software tool are not well understood, it is better for the ITS project engineer and the team to continue with the SEP manually to arrive at a definition of the project’s ITS architecture, and subsequent functional design and attendant requirements. Both ways reference the NITSA, the Florida SITSA, and the appropriate RITSAs to satisfy Rule 940. (Refer to Appendix D for a discussion of Rule 940.) This is graphically depicted in Figure 3.4. (Also, refer to Section 1.4.1.)

Refer to Appendix C for a guide to using the Turbo Architecture software tool to define a local ITS project architecture. The following sections discuss the manual process of developing the ITS project architecture.

Version 2 – March 7, 2005 36 Figure 3.4 – Defining the ITS Project Architecture