# Presentation: 299794

## Developing and Using a Concept of Operations In Transportation Management Systems

*The Foundation for Effective System Development and Operations*

## Purpose and Project Sponsor

- Introduce the Concept of Operations and its role in transportation management systems
- Provide an overview of guidance document
- This project was sponsored by the Transportation Management Center Pooled-Fund Committee

**Notes:**
There are two key objectives that this presentation addresses:

It provides a very basic, high-level introduction to a Concept of Operations.  In particular, the presentation highlights the importance of developing and using a Concept of Operations in TMSs and identifies the benefits.
This presentation provides an overview of the document “Developing and Using a Concept of Operations In Transportation Management Systems” – developed as part of the National Traffic Management Center Pooled Fund Study Program.  This document is intended to serve both as a comprehensive introduction to the Concept of Operations and a reference document for professionals involved in developing and using a Concept of Operations  for transportation management systems.

This project was sponsored by the Transportation Management Center Pooled-Fund Committee

## Presentation Outline

- What is a Concept of Operations?
- Lessons Learned in Developing and Using a Concept of Operations In Transportation Management Systems
- Available Resources to Support Concept of Operations Development and Use

**Notes:**
The presentation will consist of  3 main sections:

What is a Concept of Operations?
High level description of the purpose, goals, and contents of a Concept of Operations.

Lessons Learned in Developing and Using a Concept of Operations In Transportation Management Systems
This section moves to detailed information concerning the use of concept of operations in TMSs.  The  focus of this section is on lessons learned by transportation professionals.

Available Resources to Support Concept of Operations Development and Use
This section will highlight the document’s foundation, philosophy, other deliverables/products associated with the project (primer, fact sheet, brochure), and other resources to support Concept of Operations development and use.

## What is a Concept of Operations?

**Notes:**
Let’s begin by discussing what a Concept of Operations is and how it fits within the development, implementation, and operation of a transportation management system.

## Concept of Operations

*The Concept of Operations should be a document available, and relevant, to all stakeholders in the system, no matter what their background or role within the system.  In the context of a TMS, it should be as readable and relevant to high-level decision makers as it is to the TMS manager as it is to the TMS operator.  The Concept of Operations answers the who, what, when, where, why, and how for the new or existing system.*

**Notes:**
While there is no single definition of a Concept of Operations, the one provided here is based on information provided in the ANSI/AIAA standard on the development of a Concept of Operations (used as the foundation for developing the guidance document).  The key points for an initial understanding of a Concept of Operations include:

The document should provide a viewpoint of all operations of the system.

A Concept of Operations should be written in non-technical language such that all stakeholders understand what the document is trying to convey.

The document should identify certain types of information concerning the system in question including:
	-The identification of system stakeholders
	-The formulation and documentation of a high-level system definition
	-The definition of all major user groups and activities
	-The identification of the environment in which the system will function 

## Role Within Systems Engineering

- Graphic provided by ASE Consulting LLC

**Notes:**
It is important to realize that the Concept of Operations does not exist in isolation.  It is the first step in the Systems Engineering process, where the concept of system will be formulated.  The system “life-cycle” continues throughout the development process until the system is fully functional.

The figure presented on this slide is the Systems Engineering “Vee” which is used in FHWA training courses commonly used to describe the systems engineering process in transportation applications.

The diagram illustrates that the Concept of Operations provides the foundation for the rest of the system development process.

The concept of operations is not only first step in the Systems Engineering process that provides the foundation for development for the system, it also provides the measure of how well the system is working once completed, since the Concept of Operations provides a description of the ideal state of system operation.

## What Questions Will the Concept of Operations Answer?

- What – What are the known elements and the high-level capabilities of the system?
- Where – What are the geographical and physical extents of the system?
- When – What is the time-sequence of activities that will be performed?
- How – What resources do we need to design, build, or retrofit the system?
- Who – Who are the stakeholders involved with the system?
- Why – What does your organization lack that the system will provide?

**Notes:**
The Concept of Operations will answer the following questions concerning the system in question.  These six questions give an outline of the information that the document will convey—providing answers to all these questions will result in a well formed Concept of Operations.  

What – What are the known elements and the high-level capabilities of the system?
Where – What are the geographical and physical extents of the system?
When – What is the time-sequence of activities that will be performed?
How – What resources do we need to design, build, or retrofit the system?
Who – Who are the stakeholders involved with the system?
Why – What does your organization lack that the system will provide?

## Goals of a Concept of Operations

- Stakeholder Identification and Communication
- High-level System Definition
- Foundation for Lower-level System Description
- Definition of Major User Classes and User Activities

**Notes:**
The Concept of Operations has the following major goals:

Stakeholder Identification and Communication—A major goal of a Concept of Operations document is to facilitate discussion, and eventually find middle ground, among the relevant groups associated with system design, development, and operation.

High-level System Definition—All stakeholders must understand, at a high-level, what the system is being designed to do.  This will include the major entities within the system, the flows of information among those entities, the information flow to any entity external to the system, the high-level capabilities of the system, and the main daily operational occurrences for the system.

Foundation for Lower-level System Description—The Concept of Operations is a starting point for the lower-level description of the system, beginning with a requirements document.  Although the Concept of Operations is not a requirements document, a well-formed Concept of Operations will be a source of information that can be decomposed into a first cut of high-level functional requirements. 

Definition of Major User Classes and User Activities  All stakeholders are made aware of the different types of users of the system and activities those users will perform.  This allows everyone who uses the document to get an idea of who is performing what task and what order they are performing those tasks.  This information then can be linked to the high-level capabilities of the system for traceability purposes (i.e. who is doing what activity, and which high-level capability is this activity supporting?)

## Elements of a Concept of Operations

**Notes:**
This diagram (from the ANSI/AIAA standard on the development of a Concept of Operations) provides a visual descriptions of the core elements contained in a Concept of Operations.  They include:

Scope
Referenced Documents
User-Oriented Operational Description
Operational Needs
System Overview
Operational/Support Environments (Note:  the ANSI/AIAA document separates these two sections, we have combined them as they share common characteristics of the information contained in the sections—this will be out recommendation for these sections)
Operational Scenarios

Next, we will highlight the information that should be contained in each of these core elements.

## Scope

- The Scope section will provide an overview of the entire Concept of Operations, including the following elements
- Outline the Contents of the Document
- Purpose for Implementing the System
- Highlight Major Objectives and Goals
- Identify the Intended Audience
- Set Boundaries on the Scope of the System
- Describe an Overarching Vision for the System

**Notes:**
The scope section of the Concept of Operations will introduce the document, as well as provide some high-level information about the system in the following areas:

Outline the Contents of the Document—This section identifies how the document is composed.  Since the document will be tailored to the specific TMS, it could look very different from a Concept of Operations that someone has seen before.  Thus, this section typically includes a description of the layout of the document and on the information that is contained in each section.

Purpose for Implementing the System—The scope section of the document briefly describes the rationale behind the system.  It explains the necessity of the system being described - often through the description of the lack of capability in the existing system or environment.

Highlight Major Objectives and Goals—This section briefly presents the main goals for the system.  Later sections detail the operations of the system and are traceable to particular high-level objectives for the system. 

Identify the Intended Audience—The intended audience is identified, including both internal stakeholders (those within the scope of the system) and external stakeholders (those outside the system scope that are affected by the system in some way).

Set Boundaries on the Scope of the System—The scope section defines entities or groups that will be included in the system, as well as identify groups that will require an external interface to the system.  

Describe an Overarching Vision for the System—The scope section includes a brief vision statement for the system.  A vision statement creates a picture of the future state of the system in which all the stakeholders’ needs are met to the greatest degree possible, and all stakeholders have a shared understanding of the purpose for the system. 

## Referenced Documents

- Referenced Documents –  this section identifies resources used when developing the document. Types of reference documents that are typically listed include:
- Business Planning Documents
- Concept of Operations for Related Systems
- Requirements for Related Systems
- Studies to Identify Operational Needs
- System Development Meeting Minutes

**Notes:**
In this section, authors of the Concept of Operations list the resources used when developing the document.  This can be useful to clarify the sources of information that went into the document as well as providing the reader with guidance to find additional information.  Types of reference sources that are typically listed include:

Business Planning Documents – Documentation and resources associated with business processes for an agency and region.

Concept of Operations – Other systems’ Concept of Operations that complement the design of the system in question.

System Expertise – Documentation of human resources – individuals who singularly added unique and valuable experience to the development of the system in question.

Requirements – The requirements documents of other systems - providing detailed insight into their workings. 

Studies to Identify Operational Needs – Reviewed documentation related to the system in question, or another anticipated-similar, system that addresses operational needs.

System Development Meeting Minutes – Documentation of most meetings associated with the development of the system in question.

## User-Oriented Operational Description

- This section describes the system from a user vantage point. Typical information in this section includes:
- User Activities
- Order of User Operations
- Operational Process Procedures
- Organizational/Personnel Structures

**Notes:**
This section of the document describes the intended system operation from a user vantage point.  It identifies how organization/system-specific goals and objectives are accomplished, including strategies, tactics, policies, and constraints.  This portion of the Concept of Operations is the main focus for the entire document, as it is intended to outline the landscape of the system, and provide a clear working image for each stakeholder.  Information that is often included in this section:  

User Activities – The document identifies who the users are and what the users do. This may take a form as simple as identifying, at a high level, the various classes of users and detailing what their role is relative to the system.  

Order of User Operations – Often there is a demonstration of step-wise processes of user activities within the system.  Such information assures the incorporation of event-specific information relative to the user, often providing additional insight.  

Operational Process Procedures – Operational process models are typically included to effectively demonstrate, through the use of graphics, the relationships of all parts, and given a temporal and event context, highlight the relationships through time.  

Organizational/Personnel Structures – System-specific and organizational hierarchic relationships are often included to convey how the users will interact.  

If should be noted that in the current state-of-the-practice in Concept of Operations, user-oriented system descriptions often are merged within scenarios.  It is clear that there will be overlap in the information contained in these two sections.  The guidance presented here is to create a separate user-oriented operational description, and then form operational scenarios to support the entire Concept of Operations effort.

## Operational Needs

- This section details agency- and region-specific goals and objectives that will drive the requirements for the system.
- The element is attempting to answer the question of what is necessary for the agency or region that would complement and improve the existing system.

**Notes:**
There are many possible names, or forms, and places within the Concept of Operations that one may find “Operational Needs” expressed.  In many ways, this is simply the justification for change to some current state of the practice – either to justify the development of an entirely new system, or the integration of additional services into an existing system.

Current practice in writing Concept of Operations does not demonstrate uniformity in conveying such needs ,since it would be very difficult to imagine how any given TMS would be able to develop completely similar way for expressing need.  The matter of significance is that some form of need should be expressed when writing these documents.  It was found that the most effective TMS Concepts of Operations were those that effectively conveyed the needs of the agency or jurisdiction. 

## System Overview

- This section provides a high-level description of the interrelationships of key system components, focusing on the interrelationships among the elements.  The areas this section should address include:
- Scope
- Interfaces
- System Capabilities (Functions)
- Goals and Objectives

**Notes:**
As the name suggests, the purpose of this section of the Concept of Operations is to provide a high-level description of the interrelationships of key system components.  All of the information contained in this section can be found in another section of the document, but this section is designed to focus on the interrelationships.  The areas in this section typically include:

Scope—The section contains the geographical boundaries of the system, and the breadth of participating stakeholders.

Interfaces—The section identifies and describes both internal and external interfaces:  how entities within the system relate to one another, and how different aspects of the system relate to entities outside the system. 

System Capabilities (Functions)—at a high level, this section should identify the major functional capabilities of the TMS.

Goals and Objectives—the goals and objectives of the system discussed previously should be conveyed by this section.

Note:  The section describes all aspects of the system at once. Often, this information is conveyed via a systems diagram since it provides a way to concisely communicate a large amount of information concerning both the components and functions of the system as well as the interfaces.  

## Operational and Supporting Environments

- This section describes the environment or “world” in which the system will operate, including information about the system’s environment in terms of the following categories:
- Facilities
- Equipment
- Hardware
- Software
- Personnel
- Operational Procedures
- Support Necessary to Operate the Deployed System

**Notes:**
The term “environment” is used to describe the “framework” in which the new or improved system will have to operate.  This section includes information about the system’s environment in terms of the following categories:

Facilities – The section identifies physical facilities necessary to meet the needs of the fully functional system (e.g. buildings, garages, etc.) through high-level descriptions.

Equipment – High-level descriptions provide identify the equipment necessary for the system to be operational (e.g. closed circuit TV cameras, variable message signs, etc.).
Hardware – Typically, this refers to the physical information systems that the users of the system access. These are also high-level descriptions.

Software – A high-level description of the information system applications necessary for system operations.

Personnel – The section describes the personnel necessary to staff all facilities needed for the system to be operational.  This typically includes a concise subset of the system users identified in the User-Oriented Operational Description.  Descriptions into the capabilities of these individuals are also sometimes generated.

Operational Procedures – If not already found within the User-Oriented Operational Description, a description of what the users, and system components, are performing and when under specific conditions is also included.  

Support Necessary to Operate the Deployed System – This category includes all other supporting labor that is not specifically designated by the operations of the system.  This support could include facility management, accounting/finance, human resources, etc.

This section entails many different aspects of the system as a whole, and it is likely that all of this information will not be in one place, especially if the Concept of Operations is separated into functional areas of the system, which constitutes a majority of documents reviewed in our research.  Ideally, the description of the operational and supporting environment will make a clear connection between functional, physical, and logical viewpoints.

## Operational Scenarios

- In this element, the authors place themselves in the users’ position, and detail how the new system would impact their activities under differing conditions including:
- Stress/Failure Scenarios
- Multiple Circumstances
- Effective scenarios include a variety of user classes

**Notes:**
In this section of the Concept of Operations, the system is described under various operating conditions relative to the core users and the stakeholders.  It is most effective if the conditions described in this section range from normal to stress and failure conditions.  The operational scenario tells different stories from perspectives of different user classes over a variety of circumstances including - 

Stress/Failure Scenarios – Such scenarios describe characteristics that are conceivable to cause the system great stress – even to push the system to the point of failure. 
Multiple Circumstances – More than one scenario with multiple associated sub-events is necessary to develop a rich enough picture and story to illustrate the full extent and capabilities of the system.  

Variety of User Classes – Incorporating many of the user classes related to the system is preferred in assuring system effectiveness (meeting the goals) and assuring stakeholder buy in.

## Lessons Learned in Developing and Using a Concept of OperationsIn Transportation Management Systems

**Notes:**
Now that we have discussed the content of a Concept of Operations – let’s turn our attention to what we’ve learned in developing and using the concept of operation in transportation management systems

## How to Develop a Concept of Operations

**Notes:**
This figure presents a high-level description of how to develop a concept of operations.  This is described in detail in Chapter 4 of the guidance document.  

Big issues identified on this figure:

Begin!  - This can seem like a huge task – but it has to start somewhere.  Start by building the stakeholder coalition.
Iterate – Don’t consider this a step-by-step process – rapidly produce more and more detailed material for inclusion in the document.  You will learn a tremendous amount in each iteration.
Use the Concept of Operations – developing the Concept of Operations is just a start – it needs to be used in requirements development, system operation, etc.

## Benefits of Developing and Using a Concept of Operations

- Stakeholder Consensus
- Create consensus on the priority of needs for an organization
- Bridge the gap between the technical and operational sides of an organization
- Provide continuity over the ebbs and flows of the economy and politics
- Reduction of Risk for the System
- Reduce the risk of schedule and cost overruns
- Improvement in the quality of operations
- Matching the agreed upon vision with the implemented, operational system

**Notes:**

These benefits were identified by TMS professionals based on their experiences with Concept of Operations development and use:

Stakeholder consensus — the overwhelming majority of transportation professionals interviewed for this document cited stakeholder agreement on interrelationships, information sharing, and roles and responsibilities for the system as the most important benefit of the Concept of Operations development process.  

Reduction of risk for the system—transportation professionals agreed that a major benefit from developing a Concept of Operations is the reduction of the risk of failure for the project.  The consensus supported with the Concept of Operations can reduce cost overrun by more accurately defining the system earlier in the development stage, and decreasing the chances that stakeholder dissatisfaction will terminate the project.

Improving the quality of operations for the system—Above all, a well-formed Concept of Operations will provide a clear vision, mission, and goals for the operations of a system, leading to a well managed, efficient, and productive operation.  Beyond listing operational procedures, a Concept of Operations will ensure that the focus of all aspects of the system is on the collective vision agreed upon by the stakeholders.

## Best Practices Identified

- Active Use of Concept of Operations
- A living document for the life-cycle of the system
- The document should be used and updated
- Use of Graphics
- Complex systems need diagrams to convey multiple types of information at once
- Graphics can communicate the vision, goals, and functionality of the system in a clear, non-technical manner

**Notes:**
The next two slides highlight key best practices identified by TMS professionals for developing and using a Concept of Operations for a TMS.

Active Use of a Concept of Operations—the systems engineering process is an iterative process, so every document that is developed in conjunction with every step of the systems process within a phase of the life cycle may be considered a living document.  TMSs that find themselves in the context of massive change – for example, the addition of a new function and its associated systemic burdens – need to update their overall Concept of Operations.  Most agencies do not update their Concept of Operations after initial development.  This limits their use as the system lifecycle moves forward.

Use of Graphics—many TMS Concept of Operations documents use graphics to highlight key points in a variety of sections in the document.  When systems diagrams are used, they tend to be thorough without such a high level of detail that the diagram is useless.  As the Concept of Operations should be accessible to many different backgrounds, a diagram showing functional flows and communication lines is a valuable tool in conveying the vision of the system to a diverse audience.  The main goal of the diagram is to set the scope of the system, which can be achieved without every function or module being detailed. Unfortunately, most Concepts of Operations are text heavy, which is reasonable considering the amount of information the authors must convey in the Concept of Operations.   

## Best Practices Identified

- Scenario Development
- A broad range of user classes and operational settings will enhance the reader’s understanding of the operations of the system
- Technical Writing
- Keep the level of technical jargon as low as possible
- Stakeholder Identification
- It is important to identify all those groups and individuals with a stake in the system, both within the scope and those that interact externally with the system

**Notes:**
Scenarios—Concept of Operations documents should provide scenario development from a variety of different user perspectives.  Some example documents obtained for this study have well developed descriptions of one user class, but left out other classes, while others include many types of classes without an in depth analysis of any.  Because of the diversity of the audience, including as many user types as possible will increase the effectiveness of the document, and through the development process, thorough scenario development will bring issues to light earlier when they are more easily solved.

Technical writing—the level of technical jargon should be kept at a minimum, especially at the beginning of the documents when the scope and vision are discussed.  However, when a document switches to specific functionality or operational descriptions, the level of technical expertise necessary to fully understand the document will increase.  TMSs are complex software/hardware integration projects with a large number of inputs and outputs, so naturally there will be some level of technical information included in the document.

Stakeholder Identification—It is important to include both internal and external stakeholders throughout the development process of the system.  Internal stakeholders will surface more quickly since system definition will begin with organizations that will use and interact within the system scope.  Identification of external stakeholders will become possible as the system definition continues.  A more detailed system concept will undoubtedly create more stakeholders, and once these are identified, they should be included in the development process and in the Concept of Operations.  Recall that the systems engineering process is iterative, and it is likely that all stakeholders will not be identified on the first try.  The Concept of Operations should be a living document throughout the systems engineering lifecycle, and as stakeholders are identified and included in the development process, the Concept of Operations should change along with those additions.

## TMC PFS Developing and Using Concept of Operations in Transportation Management Systems Document

## Document Philosophy

- Relate Concept of Operations standards  and guidance to transportation management systems
- Extensive use of examples of Concept of Operations documents developed for transportation management systems
- Convey guidance given by transportation professionals concerning Concept of Operations development and use

**Notes:**
This slide highlights the thought process for the overarching focus of the document as a whole.  First and foremost, the main goal of the document was to present example documents and expertise and experiences from TMS professionals who have developed or are currently working on a Concept of Operations.  The fundamental guidance on what a Concept of Operations is and what it contains is based on information in the ANSI/AIAA standard, but the real-world examples and experiences are meant to clarify and instruct developers in TMSs.

## Document Foundation

- Analysis of standards
- Guide for the Preparation of Operational Concept Documents. (ANSI/AIAA G-043-1992).
- Internet survey
- Analysis of TMS Concept of Operations documents
- Interviews with transportation professionals

**Notes:**
The information in the document came from the following sources:

Analysis of standards – Several systems engineering standards on how to develop and use a Concept of Operations were identified and examined. The ANSI/AIAA standard G-043-1992 was chosen as the chief reference on Concept of Operations development for this handbook.  It was selected given the facts that it was written in a simple fashion, yet the method outlined was rich enough to capture all of the considerations necessary in developing a Concept of Operations.  Note, the other standards may serve equally well, given the nature of an organizations’ situation. 

Survey – An internet survey was conducted to obtain experiences and guidance from transportation professionals that are, or have been, involved in the development of a Concept of Operations.  This served as an important source of expert information for this document.

Analysis of transportation documents – Example Concept of Operations documents were gathered from TMSs throughout the country.  These documents provided the examples given in this handbook of the different approaches to Concept of Operations development and use from real-world TMS professionals.

Interviews with transportation professionals – The internet survey described above gathered mostly general information.  These were followed-up with one-on-one interviews to acquire more detailed testimonials for guidance on specific sections of a Concept of Operations.  Interviews were conducted with professionals in conjunction with the example documents acquired so that the guidance given from the professional and results of the development process from that system would coincide.

## Document Chapters

- Introduction
- Role of a Concept of Operations in Systems Engineering
- What is a Concept of Operations
- How to Develop a Concept of Operations
- Using the Concept of Operations to Support Planning
- The Next Step – Using the Concept of Operations to Drive Requirements

**Notes:**
Chapter 1: Introduction – Managers, technical staff, and supporting engineering firms with or without systems engineering backgrounds and with or without TMS will find this chapter useful as it serves in part, to introduce the reader to the purpose of the overall guidance document, but also as an ‘executive summary’ where many of the highlights of the overall document’s findings have been detailed.  This is a good staring place for all readers to determine which section may be most appropriate for them.

Chapter 2: Role of a Concept of Operations in Systems Engineering – Managers, technical staff, and supporting engineering firms without systems engineering backgrounds will find this chapter useful as it demonstrates that the Concept of Operations serves a specific and critical function within the systems engineering 

Chapter 3: What is a Concept of Operations? – Managers, technical staff, and supporting engineering firms without systems engineering backgrounds and with or without TMS will be given guidance and best practices on what is a Concept of Operations and how they have been developed for TMSs.

Chapter 4: How to Develop a Concept of Operations – Managers, technical staff, and supporting engineering firms with or without systems engineering backgrounds and with or without TMS will be given guidance and best practices on how they should develop a Concept of Operations document.  The advice and examples come from real-world TMC documents and information acquired through interviews with officials involved with the development process.

Chapter 5: Using the Concept of Operations to Support Planning – Managers with or without systems engineering backgrounds and with or without TMS will have illustrated for them how the Concept of Operations can be used to support (and is supported by) a wide range of transportation planning activities.  

Chapter 6: The Next Step – Using the Concept of Operations to Drive Requirements – Managers, technical staff, and supporting engineering firms with systems engineering backgrounds and with or without TMS will have detailed for them the transition from the concept phase to developing high-level requirements for the system, and highlighting the assistance a well-formed Concept of Operations document can provide in this process.

## Other Project Resources

- Outreach Materials:
- Concept of Operations Primer
- Fact sheet
- Tri-fold brochure
- Available from TMC Pooled Fund Study Web Site @ _[http://tmcpfs.ops.fhwa.dot.gov/projects.htm](http://tmcpfs.ops.fhwa.dot.gov/projects.htm)_

**Notes:**
Other outreach materials are available to supplement the document.  These are shorter, more targeted documents intended to promote awareness of Concept of Operations.

Concept of Operations Primer - The intended audience of the primer is community leaders, executive managers, key interests that have the potential to allocate resources, influence local practices, or may manage programs or transportation management systems that should be incorporated into their programs, policies, procedures, or practices.  
Project fact sheet -  The intended audience of the fact sheet is any individual who is engaged with or responsible for the planning, design, implementation, management, operation or maintenance of transportation management systems. 
Tri-fold Brochure –The intended audience of the brochure is executives, senior managers, and other key interests that have the potential to allocate resources, influence local practices, or the participation of their agency or staff.  

## Other Concept of Operations Resources

- Guide for the Preparation of Operational Concept Documents (ANSI/AIAA G-043-1992)
- Transportation Management Center: Concepts of Operation. Intelligent Transportation Systems. Report No FHWA-OP-99-029
- _[http://www.itsdocs.fhwa.dot.gov/jpodocs/rept_mis/8v@01!.pdf](http://www.itsdocs.fhwa.dot.gov/jpodocs/rept_mis/8v@01!.pdf)_
- National ITS Architecture
- _[http://](http://www.its.dot.gov/arch/arch.htm)__[www.its.dot.gov/arch/arch.htm](http://www.its.dot.gov/arch/arch.htm)_

**Notes:**
The following documents and links provide additional information on Concept of Operations and TMSs:

Guide for the Preparation of Operational Concept Documents. (ANSI/AIAA G-043-1992). American National Standards Institute, 1992.  This report gives guidelines for creating a Concept of Operations document.  It includes practical information on applying and packaging the operational concept technique and an example of the process’s application to the development of a major NASA system.

Transportation Management Center: Concepts of Operation. Intelligent Transportation Systems. Report No FHWA-OP-99-029.  Dec 1999. This document focuses on Transportation Management Centers (TMCs) and concepts of operations.  It discusses the importance of concepts of operations, the reasons agencies need them, and the challenges a transportation management center faces when planning, maintaining, and operating the system.

National ITS Architecture. This resource is a comprehensive collection of information designed to aid in the development and implementation of intelligent transportation systems. The Theory of Operations within the architecture should be particularly helpful.  The Architecture is also useful in identifying most of the components that will be found within any TMS, as such, it serves as a terrific starting point for defining and refining a TMS concept.