3. Virtual TMC Implementation Guidelines

This section presents a set of guidelines and considerations that aim to help in the implementation a Virtual TMC, keeping in mind that there are similar steps between implementing a Virtual TMC and a traditional TMC. Although the steps may be similar in both cases, the implementation and design approach will be different between the two. The main difference between both models is the absence of a main facility with a control room. Presented here is a list of steps that should be followed during the Virtual TMC implementation process, including the initial planning and design stages, system security and training program.

3.1. Virtual TMC Implementation Steps

Once the decision has been made to implement a Virtual TMC or hybrid derivation thereof, the following are the recommended steps that should be executed along with a description of each task that should be completed.

1. Develop Existing Systems and Needs Assessment

A description should be prepared for each system that will become virtualized. This includes the individual agency subsystems and any multi-agency connections, if the Virtual TMC deployment is to be a multi-agency model.

A high level needs assessment should be prepared to describe the following areas:

• Physical Communications
• Logical Communications
• Data and Information Needs
• Operational Needs
• Software System Needs

A high-level logical architecture should be prepared during this stage.

2. Develop Virtual TMC Concept of Operations

The Concept of Operations serves as the foundational document that addresses the who, what, when, where, why, and how for the new system. It should be accessible to all stakeholders in the system, regardless of their background or role in the system. High-level decision makers and Virtual TMC operators alike should find the document relevant and readable.

The Concept of Operations document is produced early in the requirements definition process to describe what the system will do (not how it will do it) and why (rationale). It should also define any critical, top-level performance requirements or objectives (stated either qualitatively or quantitatively) and system rationale.

The Concept of Operations document should present at a minimum:

• Identification of system stakeholders
• Definition of the high-level system
• Description of key sub-systems
• Identification and functions of user groups
• Description of the environment in which the system will operate

The Concept of Operations is also the critical initial component of the Systems Engineering approach to project development, which is recognized as the preferred method for facilitating the development, maintenance, refinement, and retirement of dynamic, large-scale systems consisting of both technical components (machines, information systems, etc.) and human components (users, stakeholders, etc.). The Systems Engineering method in the context of planning and developing Virtual TMCs. Figure 18, also known as The System Engineering "Vee" diagram illustrates the foundational role the Concept of Operation plays in the System Engineering life cycle. It defines goals and objectives, creates basis for defining functional requirements, helps to validate the finished system, and generally supports all other system engineering elements by providing a guiding vision for the system.

Figure 18. Graph. Business Plan Steps and Process. Concept of Operations in the System Engineering Development Context²⁰

There are two standard frameworks commonly used in the ITS field to help develop concept of operations documents. The first is the Institute of Electrical and Electronics Engineers (IEEE) Standard 1362-1998 ("Concept of Operations IEEE Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document"). The second is the American National Standards Institute (ANSI) Standard ANSI/AIAA G-043-1992 ("Guide for the Preparation of Operational Concept Documents").

Both standards can be used to capture the operational characteristics of the Virtual TMC system adequately. However, the ANSI framework is more typically used when planning completely new systems whereas the IEEE framework tends to be used more for upgrades or modifications to existing systems.

ANSI/AIAA Standard G-043-1992

The ANSI/AIAA Concept of Operations standard recommends that a Concept of Operations Document "...describes system characteristics from an operational perspective," and, for each stakeholder, answers the question, "What does it [the system] look like from my point of view?" The components of the standard are summarized below.

1. Scope – An overview of the entire Concept of Operations
   1. Outline the Contents of the Document
   2. Purpose for Implementing the System
   3. Highlight Major Objectives and Goals
   4. Identify the Intended Audience
   5. Set Boundaries on the Scope of the System
   6. Describe an Overarching Vision for the System
2. Referenced Documents – resources used when developing the document
   1. Business Planning Documents
   2. Concept of Operations for Related Systems
   3. Requirements for Related Systems
   4. Studies to Identify Operational Needs
   5. System Development Meeting Minutes
3. User-Oriented Operational Description– system description from a user vantage point identifying how organization or system-specific goals and objectives are accomplished, including strategies, tactics, policies, and constraints.
   1. User Activities
   2. Order of User Operations
   3. Operational Process Procedures
   4. Organizational/Personnel Structures
4. Operational Needs – details agency- and region-specific goals and objectives that will drive the requirements for the Virtual TMC system ("What is necessary for the agency or region that would complement and improve the existing system?")
5. System Overview – a high-level description of the interrelationships of key system components.
   1. Scope
   2. Interfaces
   3. System Capabilities (Functions)
   4. Goals and Objectives
6. The Operational and Support Environments – describes the environment or "world" in which the system will operate.
   1. Facilities
   2. Equipment
   3. Hardware
   4. Software
   5. Personnel
   6. Operational Procedures
   7. Support Necessary to Operate the Deployed System
7. Operational Scenarios – Details how the new Virtual TMC system would impact their activities under differing conditions, ranging from normal conditions to stress and failure conditions. The operational scenario should tell different stories from perspectives of different user classes over a variety of circumstances.
   1. Included User's Perspectives
   2. Variety of User Classes
   3. Stress/Failure Scenarios
   4. Multiple Circumstances

IEEE Standard 1362-1998

The IEEE Standard 1362-1998 identifies the minimal set of elements that should appear in all Concept of Operations documents. However, other elements may be incorporated by appending additional clauses or subclasses to the Concept of Operations document, by direct incorporation, or by reference to other supporting documents.

1. Scope – What is the scope of the project, what is to be developed and documented?
   1. Identification
   2. Document overview
   3. System overview
2. Referenced documents
3. Current system or situation – What is the current state of the practice related to applications or systems that may or may not be performing the functions expected from the Virtual TMC?
   1. Background, objectives, and scope
   2. Operational policies and constraints
   3. Description of the current system or situation
   4. Modes of operation for the current system or situation
   5. User classes and other involved personnel
   6. Support environment
4. Justification for and nature of changes – Why does the Virtual TMC need to be developed and, at a high level, what will it do?
   1. Justification of changes
   2. Description of desired changes
   3. Priorities among changes
   4. Changes considered but not included
5. Concepts for the proposed system – Who are the users of the system, where will it be deployed, and under what constraints? What systems and subsystems are involved, how do they operate, when does the sequence of events occur within the Virtual TMC system?
   1. Background, objectives, and scope
   2. Operational policies and constraints
   3. Description of the proposed system
   4. Modes of operation
   5. User classes and other involved personnel
   6. Support environment
6. Operational scenarios – What are the operational scenarios used to demonstrate the capabilities of the Virtual TMC?
7. Summary of impacts – What operational impacts will the Virtual TMC have on the users, developers, and support organizations? What will the temporary impacts be on these system users as the new system is being developed, installed, and trained for?
   1. Operational impacts
   2. Organizational impacts
   3. Impacts during development
8. Analysis of the proposed system – What improvements will be realized through the Virtual TMC? What disadvantages and trade-offs were considered?
   1. Summary of improvements
   2. Disadvantages and limitations
   3. Alternatives and trade-offs considered

3. Prepare Virtual TMC System Security Design

A secure and reliable Virtual TMC system will be made possible only through a long-term commitment to ongoing design, implementation, review, improvement and funding. However, early adoption of security best practices will greatly improve the effectiveness and resiliency of the system(s). At a minimum, VTMC stakeholders should consider the security measures listed below, in addition to the Secure System development Life Cycle guidelines provided in the following section. Organizations should also consider implementing an audit schedule for all VTMC systems by external agencies.

• Layered Security: Virtual TMC adoption poses unique security challenges created by complex, multi-location architecture, user mobility, and requirements to integrate and deploy a variety of systems and applications. To address these concerns, VTMC stakeholders must implement layered security methods including:
  • Deploy network and application firewalls providing technologies that prevent, detect, and respond to targeted threats in an adaptive manner.
  • Firewall functionality should also be deployed to provide additional layered security to protect critical devices within the Virtual TMC as well as to protect mobile devices that are placed directly onto external networks.
  • Principles of least-access should be implemented and enforced for the entire Virtual TMC infrastructure.
  • The National Institute of Standards and Technology (NIST) Special Publication 800-41 provides Guidelines regarding Firewalls and Firewall Policy which offers preliminary guidance when designing a Virtual TMC.
• Secure Communications: The Virtual TMC model mandates interconnected systems. Cryptography should be considered for all Virtual TMC communications both internal and external, and all data stores that are considered sensitive, provide high value, or are vulnerable to unauthorized disclosure. Encrypted communications between the Virtual TMC and remote operators, and traffic devices connected through wireless networks are vulnerable to attack. Communications between a Virtual TMC and remote devices should be encrypted and secured. NIST Special Publication 800-21 provides guidance for implement Cryptography.
• Log Management: It is critical in the Virtual TMC environment to maintain an accurate record of all systems, security, and performance events. Security flaws and system failures have the potential to impact multiple agencies and public safety in significant ways. Centralized logging and reporting provides data on security trends, performance trends, and gives VTMC stakeholders the information needed to investigate any failures or prove compliance with any applicable regulations or mandates.
• Consolidated System Logs: System logs should be automatically consolidated to a centralized and secure location. Event log archives should match any mandates or regulations for data retention applicable to the VTMC.
• Defined audit policies: Stakeholders should define which system events should be recorded. A few examples include:
  • Operator login and logout: This should be recorded for all perimeter devices, systems, and applications within the VTMC infrastructure.
  • System performance metrics: Should be collected for all servers, storage devices, network devices, and field devices.
  • File, database, configuration changes: Should be collected for all servers, storage devices, network devices, and field devices.
  • Communications between all internal and external systems.
• Defined alerts and notifications: Define and configure alerts and notification for specific log events that will affect VTMC security or performance.
• Defined and automated log analysis and reporting: System logs are typically very large and it can be difficult to obtain and analyze important information. Developing improved reporting and analysis tools for the VTMC will provide more efficient analysis for TMC stakeholders. (NIST) Special Publication 800-53 provides guidelines for selecting and specifying security controls for information systems applicable to VTMC operations.
• High-Availability Systems: In the Virtual TMC model, high-availability systems may be significantly more important than in the traditional TMC. In a traditional TMC, operators may still be able to manage a subset of system assets when communication or system failures occur. In the VTMC model, system and communication failures could potentially prevent remote access to all TMC systems, leaving remote operators with no ability to address events until operations are restored.

Virtual TMC stakeholders should agree upon and commit to eliminating any single point of failure in the Virtual TMC model. Typically this includes:

• Resilient communication paths should be implemented
• High availability cluster server and application pools
• Active/passive or active/active network devices

In some instances it may not be practical or cost-effective to implement redundant communications, or active/passive traffic devices. In these cases replacement units and methods to efficiently restore operations should be considered and implemented.

4. Develop Virtual TMC Communications Architecture

There are various challenges associated with the concept of implementing Virtual TMCs and the implementation of effective communication systems is one of them. However, with the introduction of improved and modern communication technologies, concepts and the supporting network security systems, this challenge can be overcome with relative ease. As depicted in Figure 19, TMCs must communicate often with a multitude of ITS field elements via dedicated field communications in addition to a number of external systems via what is commonly called Center-to-Center (C2C) Communications.

Figure 19. Graph. VTMC Communication Connections

The challenge with field communications is that a great many existing communication systems have been physically designed with the TMC (control center) being the nucleus of the system. This often includes physical hardline communications between the TMC buildings and the field infrastructure, e.g. spoke and wheel type architectures. These architectures must be updated to allow for a Virtual TMC model.

Table 8 provides a list of the various types of communications that can typically be encountered in a transportation management system. Each communication system type should be evaluated for how it should be modified for Virtual TMC operations. Although there is no physical facility or control room, the Virtual TMC servers and other equipment must still be hosted and be able to communicate with field devices.

Table 8. Field Communications

Communication Method	Architecture/Technology	Typical ITS Field Devices
Fiber Optics	Synchronous Optical Network (SONET) GigaBit Ethernet Frequency Division Multiplexing (FDM) Time Division Multiplexing (TDM) Asynchronous Transfer Mode (ATM)	CCTV Cameras Vehicle Detectors Ramp Meters Dynamic message Signs ATM Devices Tunnel Systems Traffic Signals
Cellular Wireless	Cellular Digital Packet Data (CDPD) General Packet Radio Service (GPRS) Code Division Multiple Access WiMax 1G, 2G, 2.5G, 3G, 4G, LTE	Portable ITS Devices oPortable DMS oPortable HAR oPortable TMS oPortable HAR Transit Vehicles, SSP Vehicles, Snow Plows ESS Traffic Signals
Microwave	Licensed Unlicensed Spread Spectrum	CCTV Cameras Vehicle Detectors Ramp Meters Dynamic message Signs ATM Devices
Satellite	Direct Broadcast Satellite Very Small Aperture Terminal	CCTV Cameras
Radio	Trunked Radio (APCO25, TETRA, etc.) Spread Spectrum ARDIS	CCTV Cameras SSP Vehicles Police and Fire Transit Vehicles
Leased Telecommunications	POTS T-1 DS-0 DS-1 DS-3 MPLS Dial-up Telco (POTS)	Vehicle Detectors Traffic Signals Dynamic message Signs ESS HARParking Systems
Direct Cabling	Twisted-Pair Coaxial Cable	Traffic Signals
Dedicated Short Range Communications (DSRC)	802.11 wireless LAN Bluetooth HIPERLAN Infrared	Connected Vehicles (V2V) and V2I) Snow Plows Transit Vehicles Traffic Signals

Agencies must select one of three recommended paths or guidelines to implement C2F communications in the Virtual TMC Model:

• Establish a C2F communication hub where remote virtual communications can be established using secure communications (e.g., firewalls, web application firewalls, and VPN appliances).
• Modify the C2F communications network to enable communications from any virtual position.
• Establish a hosted TMC Model using hosted services.

Figure 20 represents one migration model. In this model, the existing C2F communication system can remain in place as long as remote secure communications can be established between this centralized location and the VTMC operators. In this model, a centralized TMC facility is not needed, but a communication hub or computer serving center is still in place.

Figure 20. Graph. Hosted Virtual TMC

A more ideal VTMC model is represented in Figure 21. In this solution, the C2F communications network is established in a manner where no physical connections are made to any single facility; instead, more "openly accessible" means are established using secure methods. For example, 4G cellular communications provides acceptable bandwidth and can be used for most typical ITS field devices. In addition, other leased services such as Multiprotocol Label Switching (MPLS) can be used to enable communications from any location, as long as there is a central hub serving point. In this example, the communications with these devices is secured using password authentication and data encryption methods. Included within this architecture are the hosted computing services where the ATMS applications used by the VTMC operators can be accessed from any location where secure World Wide Web connections are available.

Figure 21. Graph. Virtual TMC Model

Establishing Center-to-Center (C2C) /External Communications for Virtual TMCs

When establishing a Virtual TMC model, whether it is single agency, multiagency or multiregional, a key aspect of the communications is how information transfer occurs between regions. This includes the methods for real-time operational data to be exchanged between operational entities (DOTs, counties, municipalities), emergency responders, traffic data feeds, computer aided dispatch systems, ISPs, and the media among others. The recommended method to do this is via a data hub, also referred to as a data gateway or portal. Figure 22 is one such example data gateway in which information is exchanged in a common manner between multiple agencies using standard methodologies and data formats.

This data gateway is essential a single location where all information that must be exchanged between agencies is shared. A typical example involves each agency "pushing" their data into this common location in a common format, e.g. using a TMDD standard, or the data is provided to the gateway and then converted into a common format for everyone to share. With this being in place any TMC, especially a virtual one, can obtain the information it needs to operate and in turn share its information with other agencies so they may also perform their multiagency operating functions.

Figure 22. Graph. C2C Communication Hub or Gateway²¹

These data hubs should be created taking into account the common C2C standards used in the ITS market today:

• NTCIP 2306 – Application Profile for XML in ITS Center-to-Center Communications – This standard is the application Profile for XML Message Encoding and Transport in ITS Center-to-Center Communications (C2C XML). This standard allows transportation agencies and center managers the ability to specify and implement communications interfaces for transmitting information encoded in the Extensible Markup Language (XML) between their center and an external center.
• ITE TMDD 3.03 – Traffic Management Data Dictionary (TMDD) and Message Sets for External Traffic Management Center Communications (MS/ETMCC). This standard contains data elements for roadway links and for incidents and traffic-disruptive roadway events. The standard includes data elements for traffic control, ramp metering, traffic modeling, video camera control traffic, parking management, and weather forecasting as well as data elements related to detectors, actuated signal controllers, vehicle probes, and dynamic message signs. The standard also contains the message sets for communication between traffic management centers and other ITS centers, including information service providers, emergency management systems, missions management systems, and transit management systems.

5. Develop ATMS Implementation Plan

In order for a Virtual TMC to become a reality, either a common ATMS should be developed or the existing system(s) that are in place should be enhanced. Many ATMS solutions are designed as enterprise solutions or client-server type applications based around the use of a physical TMC facility and its communication networks. To implement Virtual TMC functions, an integrated solution, typically web-based and thin-client should be considered. This could be hosted by the agency or by a software-as-a-service (SaaS) model.

The ATMS Implementation plan should include the following components:

• ATMS Purpose
• Mission Statement
• ATMS Functionality Description
• Existing and Proposed ATMS Architectures
• Implementation Procedures/Steps
• Roles and responsibilities for executing the plan
• Implementation Schedule
• Costs

6. Develop Standard Operating Procedures

The TMC Standard Operating Procedures (SOPs) will need to be modified or developed to accommodate the new Virtual TMC model. Each of these SOPs should include the following:

• Virtual TMC Procedure Overview – Provides decryption of each individual procedure and its purpose.
• Area or Responsibility – Who is responsible for implementing this procedure given the new VTMC model; i.e., who is responsible for doing what.
• Procedure Steps – An actual description of the steps that will be followed in the new VTMC model.
• References – References to any other procedures that will be used in association with this specific Virtual TMC procedure.

7. Modify Staffing Plan

In the absence of a physical facility in a Virtual TMC scenario, there is still room to consider the implementation of additional or "hybridized" staffing models (i.e., combining features of more than one approach). Staffing will largely depend on the agency's needs and the scope of operations.

Currently, these are the most common staffing approaches for Virtual TMCs:

• Staffed and operated by the managing entity – no dedicated TMC staff, rather the entity staff also perform TMC functions.
• Staffed and operated by the managing entity – dedicated staff for TMC functions but not working in a typical physical TMC environment (i.e., staff working remotely).
• Managed by a single entity with the operational support of partner agencies.

The staffing plan should address each of these functions given the new Virtual TMC model, noting that several will have little or no modification to those that would be performed in a standard TMC model.

8. Develop Training Plan

Many traditional TMC training programs involve a classroom type setting. The training session is usually led by the system trainer and is accompanied by a PowerPoint presentation, specific manuals, and hands-on exercises.

Training sessions may take anywhere between 2 and 4 hours each and have 8-10 personnel in attendance. Usually a training session may be separated into different training sessions; operator and system administrators. System administrators participate in the operators training, as well as receiving a more detailed system training.

For Virtual TMCs, this training model needs to have some specific modifications. As described above, training sessions are tailored to the specific users (operators, maintenance, administrators). There are no clearly defined "roles and responsibilities" for a Virtual TMC operator. This TMC operator needs to be able to be an operator, an administrator, and a maintenance user. The training model for a Virtual TMC must be able to satisfy the flexible roles and responsibilities.

A training modification is for the combining roles and responsibilities into a single operator, or at least most of the common TMC functions. Many TMCs have multiple operators, who have specific regions or responsibilities (i.e. contact maintenance, coordinate with roadway work crews, etc.). With the Virtual TMCs, these responsibilities are now within a single operator. This operator needs to be able to handle any of the various operations. Therefore the training session has to detail all the responsibilities, no matter the designation (operator or administrator).

Another distinctive modification is the classroom setting. In a physical TMC, there are multiple, dedicated workstations, as well as a training room. This may not be the situation for the Virtual TMC. Classroom training could now be performed as a one-to-one training or as part of a teleconference (WebEx, join me, GoToMeeting, etc.) with multiple users. One-to-one training may not be cost or time effective, as the trainer must now perform the same training numerous times, rather than a single classroom session. A teleconference may be a more effective training tool for the Virtual TMC operators.

A useful training tool is the use of scenarios. Real-life examples allow the trainees, whether they are operators or administrators, to perform all actions needed for real-life scenario. Scenarios should include unplanned events with minor lane blockage, unplanned events with major lane blockage with injuries and fatalities, and responses to planned closures. Other scenarios should also include the more day-to-day activities, i.e. daily reports for events. Scenarios should also include the not so normal activities, i.e. the workstation has crashed or the internet connection has been lost. Training must include the actions that an operator needs to take to remain an active participant in the TMC operations.

Since an operator may be responsible for contacting other agencies, as well as making decisions in regards to notifying media personnel; training sessions and manuals must include the associated personnel. Again as part of the training sessions, information must be made available to allow the Virtual TMC operators to contact the necessary personnel. This list of personnel could be other agency contacts, maintenance contacts, and even IT personnel.

9. Perform Risk Assessment

In order to mitigate risks associated with establishing a Virtual TMC, it is important that each agency identifies, assesses, and evaluates risks associated with this model. With risk being defined as a "potential problem," the key is to identify the possible issues beforehand and prevent the actual issue from occurring by implementing mitigation steps, tasks, or plans designed to prevent the problem from actually occurring.

For the risks identified in the Risk Identification and Register (Table 3-2), each risk should be given two types of rankings:

1. Likelihood of Occurring, rated as:

L = Low Likelihood
M = Medium Likelihood
H = High Likelihood
E = Extreme Likelihood
NA = Not Assessed or Not Applicable

2. Impact if issue becomes a reality

L = Low Impact
M = Medium Impact
H = High Impact
E = Extreme Impact
NA = Not Assessed or Not Applicable

With a combined ranking of likelihood and risk together, Table 9 offers a potential grade for each risk, with a grade ranking of "A" requiring immediate attention, those with a "B" grade requiring secondary attention, and so forth.

Table 9. Risk Identification and Register

Rating for Likelihood and Seriousness of Each Risk

L	Rated as low
M	Rated as medium
H	Rated as high
E	Rated as extreme (used for seriousness only)
NA	Not assessed

Grade: Combined effect of likelihood/impact

		Impact
		Low	Medium	High	Extreme
Likelihood	Low	E	D	C	A
	Medium	D	C	B	A
	High	C	B	A	A

Recommended Actions for Grades of Risk

Grade	Risk Actions
A	Actions to reduce the likelihood and seriousness to be identified and implemented as soon as the project commences.
B	Actions to reduce the likelihood and seriousness to be identified and appropriate actions implemented during project execution.
C	Actions to reduce the likelihood and seriousness to be identified and costs developed for possible action if funds permit.
D	To be noted – no action is needed unless grading increases over time.
E	To be noted – no action is needed unless grading increases over time.

Project Identification

Project:	Virtual TMC
Client:	DOT XXXX
Project Manager:	John Doe, Project Manager
Project Scope:	Phase 1 Scope
Version/Date:	Version 1

Table 10 is a sample Virtual TMC risk table with some commonly anticipated risks that could be faced by an agency attempting to implement a Virtual or hybrid TMC solution.

Table 10. Risk Identification Matrix

Project Task	Description of Risk	Likelihood	Impact	Grade	Change	Actions/Mitigation	Responsible Party	Status
All	Agency partners do not have common operational concept	High	High	A		Establish common multi-agency Concept of Operations
All	Agency security policies do not allow for virtual TMC concepts to be deployed, e.g. firewalls for multi-agency, multi TMC connections cannot be configured to enable VTMC Operations	Medium	High	B		Review all agency security policies, review with IT staff and obtain modifications or waivers as necessary.
All	Center-to-Field Communication Systems are not conducive for VTMC Operations	High	Low	C		Review details of C2F communication architecture.  Establish local communication node or server system.  Reconfigure C2F network as necessary.
All	Center-to-Center Communication System is not conducive for VTMC Operations	High	Medium	B		Design common C2C communication gateway, portal or hub using agreed standard data exchange mechanism
All	Operators are not trained for VTMC Operational Model	High	Medium	B		Establish a training program for virtual TMC Operations.  Implement training based upon agreed schedule
All	Existing software management and TMC management tools are not designed for VTMC Operations.	High	High	A		Execute systems engineering process to design or upgrade existing system tools to perform VTMC operational functions.
All	Regional ITS Architecture does not support VTMC model	High	Low	C		Begin process to update Regional ITS Architecture accordingly.
All	Complete DOT IT Security Breach compromises the VTMC Network	Low	Extreme	A		Perform full security assessment and implement security measures and components to prevent such a complete breach.

10. Develop Operations & Maintenance (O&M) Plan

An O&M plan for Virtual TMCs should be developed. This plan may be an enhancement to the existing TMC O&M Plan. It should include:

• A list of the hardware and software items that will be maintained
• How will these various systems be maintained
• Who will be responsible for the maintenance activities
• Descriptions of the routine maintenance
• Descriptions of preventive maintenance tasks
• Description of non-critical O&E activities
• How will emergency repairs be handled
• What spare parts will be kept and how will these stock piles be used and access
• A discussion of required service level agreements.

3.2. The Planning Process

3.2.1. Objectives

The planning process applies to agencies wanting to deploy a new center or agencies wanting to add new virtual functionality or virtual capabilities to their current operations. Its objective is to describe the process for developing, implementing and deploying a Virtual TMC or a TMC with virtual capabilities. Through this process agencies will need to:

1. Establish goals;
2. Address existing and potential issues and challenges;
3. Consider operational and technological capabilities;
4. Explore opportunities for improvement; and
5. Create Memoranda of Understanding (MOU) in the case of multi-jurisdictional operations or the partner agency support model.

3.2.2. Operational Considerations

When considering a new virtual deployment or the implementation of new virtual features, it is crucial to evaluate the agency's TMC requirements and needs, funding, communication infrastructure, and security protocols as well as the functions envisioned for the center. Operational considerations include, but are not limited to:

• Stakeholder Identification
• Coordination
• Staffing

3.2.2.1. Stakeholder Identification

Stakeholder identification will largely depend on a series of factors unique to the context of the Virtual TMC scope, including:

• The jurisdiction's road networks;
• The operating environment;
• The organizational structure; and
• The functions to be performed.

A thorough understanding of the future system or the system at hand will facilitate the identification of a wide variety of key players. Many stakeholder groups are easily identifiable in the early stages of system planning, while others are identified later in the process as the scope becomes more detailed.

The USDOT's 2005 report Developing and Using a Concept of Operations in Transportation Management aggregates survey results from transportation professionals and identifies several different classes of stakeholders. The most frequent categories of stakeholders cited were:

• Departments of Transportation (DOTs)
• Local government (city, county, etc.)
• Authorities (bridge, port, etc.)
• Local law enforcement
• Emergency response (EMS, fire rescue, etc.)
• Transit operators, State agencies and authorities
• Contractors working on the system
• The public

It is often effective to classify stakeholders into internal and external groups. Internal stakeholders are those individuals, groups and organizations that are considered within the scope of the system, and external stakeholders are those individuals, groups, and organizations that are outside the defined scope of the system but interact with the system. Identification of external stakeholders will become possible as the system definition continues.

Below in Table 11 are some general attributes of each class, identified in USDOT's 2005 Report on Developing and Using a Concept of Operations in Transportation Management:

Table 11. Attributes of Internal and External Stakeholders

Internal Stakeholders	External Stakeholders
Within the primary organization(s) that is developing or operates the system Play a significant role in system function Are significantly affected by changes in system design and function Examples: System engineers and architects Operators System users Maintainers Public Agencies (partners)	Interact with the system but are outside the scope of the system Play a secondary role in system function or are only affected by system function Examples: Private entities Media Legal advisors  Technical advisors Financial institutions

Stakeholders may be identified and should be included in all stages of the planning and the development processes.

Although the operational, organizational, and technological context of each Virtual TMC implementation will require a unique set of stakeholders, in general all projects will share the same categories of stakeholder groups. The ANSI Concept of Operations standard identifies the following high-level categories of system implementation stakeholders:

• Users – This is a very broad category; it includes any individual, organization, or system that interacts with the system.
• Operators – Staff members or partner agencies who actively manage the system from its core.
• Maintainers – Staff within the organization or contracted staff that deal with system upkeep, including software, hardware, sources for collecting information (i.e. ESS, CCTV, etc.), and data storage.
• System Engineers and Architects – Those internal and/or contracted staff members who design the system from the Concept of Operations stage throughout the system lifecycle.
• System Implementers – Those in charge of building the system or implementing new functionality to an existing system. This can include software coding, implementation of data collection sources, and integration among various sub systems.
• Customers and Buyers – Any group that is purchasing some aspect of the system from organizations or contractors outside the scope of the system
• Testers – Entails all staff members that test all aspects of the system, from the component level of software development to the completed, working system for user acceptance.
• Customer and Developer Organization Management – Managerial-level members of the organizations (commercial or non-commercial) involved in the development or operation of the system in question.

As illustrated above, there is a wide range of entities that can and should be considered as stakeholders. It is important to take the necessary time to identify the right mix of stakeholders and to involve them early on in the Virtual TMC planning process. Early participation can build goodwill and trust among the stakeholders by making them feel that they are an important part of the development process.

3.2.2.2. Coordination

As discussed in USDOT's comprehensive 2005 report Developing and Using a Concept of Operations in Transportation Management, active participation among stakeholders is essential for the planning and deployment of a transportation management system. Due to the multi-jurisdictional and multi-system features often inherent to TMC virtualization, the coordination effort to involve the various stakeholders becomes particularly important to ensure their involvement.

One of the main causes cited for stakeholder non-participation or even hostility is when stakeholders do not feel like their mission or goals are being met. This is not to say that all parties necessarily have to agree on every aspect of the system, but stakeholders must not be made to feel that their major goals as an organization are being compromised by agreeing to some aspect of the system. Clearly, goal-alignment becomes increasingly difficult as the number and variety of stakeholders increases, but stakeholder consensus is necessary in order for the final system to gain acceptance and be used as designed.

3.2.2.3. Staffing

In the absence of a physical facility in a Virtual TMC scenario, there is still room to consider the use of additional or "hybridized" staffing models (i.e. combining features of more than one approach). Staffing will largely depend on the agency's needs and the scope of operations.

Currently, the most common staffing approaches for Virtual TMCs include:

• Staffed and operated by the managing entity—no dedicated TMC staff, rather entity staff also performs TMC functions.
• Staffed and operated by the managing entity—dedicated staff for TMC functions but not located in a typical physical TMC environment (e.g. staff working remotely)
• Managed by a single entity with the operational support of partner agencies.

Traditionally, the four models presented in this section apply to TMCs with physical facilities. However, these approaches can provide a useful framework for evaluating staffing options. Each model offers a range of ownership options, operational requirements, performance, and cost, and have been used in various settings nationally.

Model 1: Private Sector - Concession Operations

In this option, systems are contracted and privately owned, remaining in the contractor's ownership after the contract period. Operations are also contracted out, usually as part of the same system provision contract. The Contractor is responsible for the systems, staff, and for maintaining services through Service Level Contracts and performance monitoring.

Deployment Example: The Utah Department of Transportation 511 system is fully outsourced.

This model is viable in a traditional TMC approach, and it may not be applicable to a Virtual TMC scenario since the latter does not require typical TMC operations.

Model 2: Joint Private-Public Partnerships / Application Service Provider (ASP)

This option is similar to the Concession Operations, where systems are contracted, privately owned, and remain in the contractor's ownership after the contract period. The main difference is that the system is operated by in-house operations staff (public employees).

Deployment Examples: Washington State, New England states of Rhode Island, Vermont, and New Hampshire, Kansas, the Dakotas, Nevada and Montana.

This model is viable in a Virtual TMC scenario, since it uses in-house staff to operate the system. The system will need to meet the agency's security protocols.

Model 3: Private Sector - Contracted Operations

In this option, operations are contracted out to a Private Sector service provider. The Contractor is responsible for staff and for maintaining services through Service Level Contracts and performance monitoring.

Deployment Example: The Virginia Department of Transportation (VDOT) used contracted operations for its Regional TMCs.

This model is viable in a traditional TMC facility, but it may not be applicable to a Virtual TMC scenario.

Model 4: Public Operations

In this option, the system is publicly owned, and it may exist or it may be created as part of a separate contract. The system is operated by in-house operations staff in the TMC.

Deployment Example: Arizona's 511 system.

This model is viable in a Virtual TMC scenario, since it uses in-house staff to operate the system. Depending on the scope of work, it may not require full time staff.

Table 12 summarizes the high-level ownership and cost distinctions among the four deployment models:

Table 12. Staffing Models

Model	System Ownership	System Operation	Cost Focus	In Virtual TMC Model
1. Private Sector Concession Operations	Private Contractor  to the Agency	Private	Operating	No
2. Joint Private-Public Partnership	Private Contractor to the Agency	Public	Operating	Yes
3. Contracted Operations	Public (Agency)	Private	Operating and/or Capital	No
4. Public Operations	Public (Agency)	Public	Capital	Yes

3.2.3. Organizational Considerations

3.2.3.1. Typical Virtual TMC Organizational Needs

This section discusses the common business processes and services typically supported by Virtual TMCs; roles, responsibilities, and capabilities; inter-agency collaboration; and programmatic integration.

As presented by USDOT in a 2004 presentation titled "A National Campaign for Improving Regional Transportation Operations," the following are key organizations related to planning may be applied to a Virtual TMC and must be considered in developing the Concept of Operations.

Figure 23. Graph. Key Organizations in Planning a TMC or Virtual TMC²²

Figure 23 above illustrates how a Virtual TMC relates to and provides a platform for a variety of other services. A Virtual TMC is highly likely to have links and synergies with other policies and services. Areas with particularly strong synergies include:

• Safety and security: video cameras play a key role within a TMC operation, which can be combined with improvements in safety and security management. A Virtual TMC deployment is especially well suited to supporting safety- and security-related video distribution owing to its distributed system architecture.
• Incident management: A Virtual TMC can be used to mitigate the impacts of incidents, reducing the effects of traffic collisions upon the overall transportation network flows and conditions.
• Public transportation operations: A Virtual TMC can be used to improve the movement of buses and other public transportation services that use the transportation network (e.g., by facilitating transit signal priority operations along bus routes).

3.2.3.2. Operational Coordination

This section addresses operational aspects that need to be implemented to achieve a more consistent, timely, and efficient incident response and management of large-scale events, including coordination with other agencies that affect TMC activities.

As presented by USDOT in a 2004 presentation titled A National Campaign for Improving Regional Transportation Operations, Figure 24 illustrates the key TMC functions that are relevant to planning a Virtual TMC.

Subjects that need to be addressed include:

1. Creating and reviewing operational policies and practices;
2. Addressing issues of common concern among the partner agencies;
3. Facilitating training, drills, and exercises;
4. Reviewing infrastructure (where applicable), maintenance, and other operational resource requirements; slated
5. Performing debriefings following major incidents; and
6. Proactively planning for major events and emergency scenarios.

It is important to promote peer-to-peer information exchange, open participation, and relationship building among the stakeholders.

Implementing effective regional transportation management and operations in a collaborative manner is a critical component of a Virtual TMC deployment to ensure that it supports and continues to support the various entities and services to which it's connected and performs the functions required of it.

Figure 24. Graph. Key TMC Functions in Planning a Virtual TMC²³

One approach to facilitating such coordination is described in USDOT's 2011 Practitioner's Guide to Regional Concept for Transportation Operations. In this report, the USDOT highlights successful cases of regions using a Regional Concept of Transportation Operations (RCTO), a management tool used by planners and practitioners to define a strategic direction for improving regional transportation management and operations in a collaborative manner. The authors observed that successful implementations of RCTOs shared these common features:

• Strong and persistent leadership to guide the effort and maintain momentum for developing and implementing an RCTO.
• An iterative process for bringing participants into the RCTO process as the RCTO objectives are formulated and agreed to by all participating agencies.
• Leveraging and building upon existing relationships to gain support for an RCTO.
• Focusing on current or anticipated needs.

It was found that the RCTO process can be an effective mechanism for incorporating operations considerations into the planning process so that funds needed to implement operations strategies can be integrated into regional capital investment plans.

Figure 25 illustrates how an RCTO could be developed in three distinct phases. As shown, the motivation element is not created during the development of an RCTO. It is an issue observed by the partners that prompts the initiation of an RCTO and is then recorded. The first phase is largely driven by values and needs, and it consists of forming the operations objective, which establishes the desired outcome.

The second phase identifies possible approaches to achieving the operations objective and culminates in the selection of a particular course of action. The third phase translates the approach into more specific, tangible elements that guide joint or coordinated actions including system design, resource allocation, and interagency and multi-jurisdictional agreements.

Figure 25. Graph. RTCO Development Phases²⁴

The Practitioner Guide cited the example of the city of Tucson's use of an RCTO to improve its operational policies and practices related to arterial management operations, traveler information, and work zone management—all key focus areas of TMCs and Virtual TMCs. For each focus area, the RCTO team established operational objectives and agreed upon associated performance measures. Table 13 illustrates how the RCTO established the traveler information focus area.

Table 13. Example of RTCO Focus Areas, Objectives and Measures²⁵

RCTO Focus Area	Operations Objectives	Performance Measure
Traveler information Motivation: The stakeholders saw the need to coordinate traveler information systems in the region, reduce duplicative efforts, and make better use of the existing systems in disseminating information.	Reduce traveler delay by improving the quality, quantity, accessibility, and use of multi-modal traveler information services in the region. Improve the data management and storage of traveler information. Educate roadway users to improve driver habits. Provide current and accurate information to Tucson metropolitan area traveler information services (work zones, incidents, other closures).	Number of calls placed to 511 telephone system from the Tucson metropolitan area and number of website hits for Tucson-specific travel information. Number of events (incidents and planned events) that are entered into HCRS per year for the Tucson metropolitan area. Number of media outlets using traveler information to distribute to the public.

Another example specific to the incident management responsibilities of a TMC is the case of the Hampton Roads RCTO, which coordinated incident response operations among:

• Virginia State Police,
• Local fire and rescue,
• Local traffic engineers and public works staff,
• Local law enforcement,
• Environmental and hazardous materials (hazmat) staff,
• Local emergency medical services, and
• Members of the towing and recovery community.

In the 2½ years following the development of the RCTO, Hampton Roads RCTO participants from local and State DOTs, local and State public safety agencies, and the Hampton Roads Transportation Planning Organization continue to meet on a quarterly basis as the Hampton Roads RCTO subcommittee. Despite fluctuations in participation level and staff changes, the group continues to make progress on the actions identified in the RCTO. As of early 2011, a memorandum of understanding (MOU) was being developed to formalize the commitment of the agencies participating in the RCTO to collaboratively advance traffic incident management in the region.

Table 14 depicts an example approach for meeting the consensus incident management operations objectives.

Table 14. Sample Approaches for Meeting Operations Objectives²⁶

Operations Objective	Approach
Increase Responder Safety	Start a regional public awareness campaign concerning the "Slow Down, Move Over" law and the "Move It" law. Encourage optimal lighting and traffic control equipment for secondary responder vehicles.
Decrease incident clearance times	Implement the use of intermediate reference location signs. Pursue the use of incentive based towing contracts or other innovative towing initiatives.
Decrease secondary incident occurrences	Provide Virginia Port Authority (VPA) and other regional entities information regarding major incidents in Hampton Roads. Enhance the dissemination of incident-specific information to the motoring public.
Improve inter-agency communication during incidents	Improve external and internal communication related to traffic incident management. Explore the possibility of multiple agencies being co-located at the Hampton Roads Traffic Management Center (HRTMC).
Identify existing regional incident management resources and establish plan for inter-agency utilization and acquisition	Conduct cross-agency training Provide more total station equipment to be utilized in investigations.
Establish a regional incident management pro-active and post-incident review consortium	Hold meetings of the post-incident review consortium following any problematic incidents.

Establishing an inter-agency coordination and planning process similar to the RCTO examples described above is good way to ensure that operational policies and practices are continually reviewed and improved, common concerns among partner agencies are addressed quickly and openly, and infrastructure, maintenance, personnel, and other operational requirements are regularly assessed.

3.2.3.3. Reporting Relationships

In an operational setting, communications occur for a number of purposes and at varying frequencies. It is important to establish well-defined project responsibilities, comprehensive system oversight, and clear communications and reporting structures as well as to explain the basis for work day and off-hour communications and identify where additional resources are needed, including:

• Management responsibilities and staff reporting;
• Meeting schedules and communications issues;
• Quality assurance;
• Problem resolution;
• Documentation and record keeping requirements;
• Routine reporting requirements;
• Implementation of timelines and procedures; and
• External communications with other agencies and the public.

3.2.3.4. Finding the Right Organizational Fit

Every Virtual TMC deployment will have its own unique functions and responsibilities. However, most will share some common elements. FHWA's 2004 Report on TMC Operator Requirements and Position Descriptions found that the most commonly referenced groups of functions applicable to Virtual TMC implementations include:

1. Traffic monitoring
2. Control of ITS devices
3. Maintenance, repair, and troubleshooting
4. Disseminate information
5. Personnel management (if appropriate)
6. Data analysis
7. Interface with media and public
8. Plan, recommend, and implement system, and procedural upgrades
9. Coordination with incident response agencies
10. Coordination with other local and regional transportation agencies

The following tables are adapted from FHWA's 2004 report on TMC Operator Requirements and Position Descriptions and are applicable to the skills and knowledge required of a Virtual TMC operator. However, due to the distributed nature of the Virtual TMC functional architecture, it is more likely that a particular resource will need to have greater knowledge and be required to do more tasks than his centralized TMC counterpart. For this reason, it is expected that the Virtual TMC operator will more often be in the Full Performance or Advanced categories rather than Entry Level.

Human Resources: Generic Activity Group 1

Monitors, classifies, assesses, and archives data and other inputs regarding traffic accidents, road surfaces, traffic density, weather, traffic signal operation/malfunctions, construction projects, major disasters, and special events to maintain constant awareness of traffic system operation.

	Entry Level	Full Performance	Advanced
Knowledge	TMC metro area road system. Use of Common language/terms used to describe traffic conditions.	Road locations that are critical to traffic safety and/or traffic flow. TMOT's manual, including policies and procedures. Traffic system terminology. Principles of technical traffic engineering (e.g. queuing, capacity).	Traffic signal timing selection plans. HAZMAT policies, procedures and codes. Overheight vehicle control regulations and response plans. Rail crossing traffic signal controls and response plans.
Skills / Abilities	Skill in visualizing map locations (i.e., map reading skill). Skill in reading and listening to detailed or technical information. Ability to communicate orally and in writing to provide information clearly and succinctly. Ability to learn a body of material consisting of regulations, and /or procedures. Demonstrated success in dealing with pressure situations.	Ability to analyze multiple source data from equipment and people under time pressure. Ability to communicate effectively with transportation system audiences (e.g., police, highway helpers, public).	Ability to interpret conflicting or ambiguous traffic incident/congestion information. Ability to make a disciplined and timely assessment of information on potential for major disasters and emergencies.

Human Resources: Generic Activity Group 3

Evaluates data on the severity of traffic conditions and other factors affecting the traveling public and selects the appropriate response plan in order to ensure the best possible flow of traffic using TMC policies, procedures, and precedents. Takes the necessary steps to implement the response plan and ensures that the conditions and responses are recorded into the data system of the TMC. Track and evaluate performance measurement data for use in modifying operations or recommending traffic systems operational changes.

	Entry Level	Full Performance	Advanced
Knowledge	Computer equipment/software with Microsoft Windows or equivalent systems.	Software programs/equipment capabilities and limitations used in TMC operated systems.	Techniques to respond to and correct minor equipment/software performance problems.
Skills / Abilities	Demonstrated general automation skill by use of moderately complex software used in spreadsheets, word processing, databases, or Internet applications. Demonstrated ability to operate and integrate audio, video, or other moderately complex electronic equipment.	Skill in operating software and equipment used by a TMC. Ability to clearly communicate with ITS staff regarding how the equipment and software is performing.	Ability to independently troubleshoot and correct minor performance problems with equipment and software. Ability to train/mentor other operators about equipment and software capabilities. Ability to recommend improvements to traffic information systems and network operations.

Human Resources: Generic Activity Group 4

Coordinates with or dispatches other traffic management personnel and organizations such as police, fire and rescue squads, emergency assistance personnel, transit services, highway patrol, or traffic signal repair crews to resolve traffic system problems or repair parts of the transportation management system. Participates in transportation planning activities as required.

	Entry Level	Full Performance	Advanced
Knowledge	English usage and grammar, demonstrated by successful completion of relevant high school courses. In specific TMCs, conversational Spanish - - test or structured interview. Mathematical concepts, demonstrated by successful completion of related high school courses in geometry, algebra or trigonometry.	Principles of technical traffic engineering (e.g., queuing, capacity, etc.). TMC operations manual including policies, precedent and procedures. Intelligent transportation measuring systems (e.g., heuristic).	HAZMAT policies, procedures, and codes. Area emergency evacuation policies and procedures.
Skills / Abilities	Ability to solve problems (e.g., demonstrated good judgment about career and life situations). Demonstrated success in dealing with stressful situations. Apply quantitative skills such as percentages, numerical ratios, and speed and distance formulas.	Ability to diagnose and assess the severity of traffic incidents. Ability to develop and implement effective and disciplined response plans within established policies under time pressures. Skill in timely and effectively addressing customer service needs.	Ability to recognize when to override/modify automated system generated plan. Ability to make timely and independent decisions to respond in unprecedented situations or major disasters (e.g., plane landing on highway, atypical HAZMAT spills). Ability to independently develop traffic management plans for special events and/or other areas of potentially chronic congestion. Ability to independently evaluate meter queues and adjust timing of ramp meters. Ability to recommend systems operational changes.

Human Resources: Generic Activity Group 5

Disseminate information to the public through message signs, advisory radio, web sites, and other media to improve the flow of traffic.

	Entry Level	Full Performance	Advanced
Knowledge	English grammar and usage. Conversational Spanish (optional to specific position where metropolitan area has large Spanish-speaking population)	Traffic system terminology Web site management	Not applicable.
Skills / Abilities	Ability to speak and write succinctly.	Ability to clearly communicate technical information in layman's terms. Skill in displaying courtesy and sensitivity to the motorist and public needs.	Not applicable.

3.2.3.5. Inter-Departmental and Inter-Agency Agreements

In a Virtual TMC it is critical to establish processes for agreements, formalize partnership with other departments and agencies and develop institutional arrangements and agreements.

Table 15 summarizes the key agreement content with content providers and other system partners:

Table 15. Inter-Agency Agreements

Entity	Agreement Content
Content Providers	Data Sharing Requirements Data Exchange Standards Data Quality Agreements System Interface Requirements Troubleshooting/Maintenance Cost Sharing
Adjacent Agencies/States	Agreement and standards to facilitate mutual data transfer Cost sharing agreement Standards for future integration
Marketing Partners Providers	Marketing/co-branding agreements Cost sharing agreements

Data sharing agreements will play a critical role in Virtual TMC implementations owing to the significant amount of data exchange in terms of both inputs and outputs that is involved with a virtual setup. Strong data sharing agreements should be drawn up between all parties during the implementation stage in order to ensure that there are no contractual breaches throughout the lifespan of the Virtual TMC. If data feeds are to be supplied by a private sector partner (e.g., Inrix traffic data), consideration needs to be given to how these data are paid for and also what level of return could be achieved through such investments.

3.2.4. Business Models for a Virtual TMC

3.2.4.1. Key Factors to Consider

In order to develop a Virtual TMC business plan, it is necessary first to consider how the Virtual TMC is organized and the functions it serves for the region. Such aspects define the TMC's business model.

In its 2005 TMC Business Planning and Plans Handbook²⁷ the FHWA identified several different types of organizational and functional options for a TMC that factor into the business model. These options are applicable to virtualized TMC functionality as well. The key factors to consider when developing a business model for a Virtual TMC include:

• Functions or services provided;
• Geographic area covered;
• Number and types of agencies involved; and
• Operating mechanism.

The typical options for these factors are summarized in Table 16 and are discussed in greater detail in the following sub sections.

Table 16. Organizational and Functional Options for a VTMC

Geographic Area	Number and Type of Agencies	Operating Mechanism
Single jurisdiction Multiple jurisdictions Regional/district Statewide	Single agency Multiple agencies Multiple agencies and disciplines	Public sector operated (single agency) Public sector operated (consortium) Separate public sector operating entity Public-private partnership Contracted operation

Local and regional conditions, institutional arrangements, system capabilities, and needs will necessarily impact the design of any Virtual TMC implementation. However, the factors listed above will help establish at a high level the basic organizational, functional, and institutional relationships that comprise various options for structuring a Virtual TMC.

While virtualization of operations can benefit a number of the TMC business models summarized above, it is most beneficial when one or more of the following criteria apply:

1. Coordination and decision making in a group setting is rare;
2. System users do not have common needs for more developed functional shared facilities (e.g., emergency operations room, media room, etc.);
3. User groups require common information, but do not use this information directly for coordinating real-time decisions that are core of their operations. The information is instead more complementary in nature;
4. Visual or verbal access among user groups is of little or no value to the work being performed;
5. Due to the nature of the TMC (e.g., rural coverage area) there is no extended benefit for improved coordination and communications with other user groups;
6. There is no need to cross-train or back-fill positions, even in a temporary or casual capacity; or
7. Computer or communications equipment for different user group systems is sufficiently different, or carries enough security risks, that it cannot readily be integrated into one room or be maintained, repaired, or configured by common staff.

3.2.5. Planning for a Virtual TMC vs. a Centralized TMC

The implementation of a TMC, virtual or centralized, requires a broad set of criteria to be addressed during the planning stages. These criteria include the stakeholders' long-term vision and goals; objectives; relationships, roles, and responsibilities; functional needs; performance targets; infrastructure; technology; costs; and future needs.

Figure 26 depicts the process for developing a TMC Business Plan, which is applicable to both virtual and centralized environments.

Figure 26. Graph. Business Plan Steps and Process²⁸

Table 17 further expands upon the key components that should be contained in the Virtual TMC Business Plan.

Table 17. Virtual TMC Business Plan Core Components

VTMC Business Plan Core Component	Recommended Content and Focus
Identify Stakeholders	Summarizes the key points of the Business Concept, Strategies, Partnerships, Organization and Financial Plan Used as a tool to sell the Business Concept and Plan to high level agency managers, local and regional elected officials, and TMC partners
Define Business Concept	Functions and description of key functions or needed functions Strategic objectives, goals, future trends Services – within the TMC and how the TMC relates or supports other agency operations and regional TMS, emergency management, safety, regional connectivity, information management, etc. Vision and TMC description (current state, future end state) Partnerships, including existing and desired or needed partners or alliances Risks and dependencies
Define Value Proposition	Define benefits and how they will be measured, how progress will be monitored and reported Who benefits – who stands to benefit from achieving strategic objectives The Value Proposition helps to market and 'sell' the Business Concept to target audience and decision makers
Strategy Sets	Actions – What needs to happen (projects, implementations, changes or enhancements that need to occur) Who is responsible (to lead, champion, produce, develop, implement or manage) Timeframes and priorities Dependencies
Financial Plan	Budget and timeframes Funding mechanisms Funding processes Procurement issues/requirements
Organization and Management	Who owns, who manages, who participates Personnel, staffing (numbers and types of staff, training and experience requirements, etc.) Organization structure, chain of command, resource requirements TMC relationships to external agencies, how it functions in the "bigger picture," and what are the critical agency relationships and partnerships

In addition, during the planning process, consideration should be given to current and future regional ITS programs and establish ITS processes to help define the Virtual TMC objectives. Figure 27 illustrates the relationship between ITS planning processes and the TMC business plan.

Figure 27. Graph. Relationship of the TMC Business Plan to other Plans and Processes²⁹

It is important to align plans for a Virtual TMC deployment—including its funding—with the regional ITS architecture. The regional ITS architecture focuses on specific, measurable, and outcome-oriented objectives in the planning and operations of a Virtual TMC.

Figure 28. Graph. Regional ITS Architecture to Suppport Planning and Operations³⁰

Following the National ITS Architecture

With the passage of the Transportation Equity Act for the 21st Century (TEA-21), ITS projects funded through the Highway Trust Fund were required to conform to the National ITS Architecture and applicable standards. Conformance with the National ITS Architecture was interpreted to mean using the National ITS Architecture to develop a regional ITS architecture and requiring all subsequent ITS projects to adhere to that regional architecture as well. The National ITS Architecture is to be used as a resource in the development of the regional ITS architecture (as discussed above), and the subsequent regional ITS architecture is to be on a scale commensurate with the scope of ITS investment within the region. (Refer to https://ops.fhwa.dot.gov/publications/tptms/handbook/chapter_3.htm for additional information.)

This legislation imposed the following requirements:

• All ITS projects funded by the Highway Trust Fund must be based on a systems engineering analysis on a scale commensurate with the project scope.
• Compliance with the regional ITS architecture must be in accordance with United States Department of Transportation (USDOT) oversight and Federal-aid procedures, similar to non-ITS projects.
• ITS projects funded by the Highway Trust Fund and the Mass Transit Account must conform to a regional architecture.
• Projects must use USDOT-adopted ITS Standards as appropriate.
• Regions currently implementing ITS projects must have a regional architecture in place in 4 years, while regions not currently implementing ITS projects must develop a regional ITS architecture within 4 years from the date the first ITS project advances to the final design.
• Major ITS projects should move forward based on a project-level architecture that is coordinated with the development of the regional ITS architecture.
• The concept of operations document should identify the roles and responsibilities of participating agencies and stakeholders for the regional ITS architecture developed for the TMS.

Figure 29 depicts the various systems, sub-systems, and interconnects that comprise the National ITS Architecture.

Figure 29. Graph. National ITS Architecture Interconnect Diagram³¹

The National ITS Architecture considers Traffic Management a Service Package Group containing numerous Service Packages designed to reflect the current definition of ITS and the evolving implementations of ITS. Service packages are defined by sets of equipment packages required to work together (typically across different subsystems) to deliver a given transportation service and the major architecture flows between them and other important external systems. In other words, they identify the pieces of the National ITS Architecture required to implement a service. Service packages are not intended to be tied to specific technologies, but of course depend on the current technology and product market in order to actually be implemented. As transportation needs evolve, technology advances, and new devices are developed, service packages may change and new service packages may be defined.

Although the National Architecture does not distinguish between a virtual and traditional TMC, all the identified Service Packages within the Traffic Management Service Package Group may be applicable to a Virtual TMC. As identified in the Key Concepts of the National ITS Architecture report (available at the link: http://www.iteris.com/itsarch/documents/keyconcepts/keyconcepts.pdf), these include:

• Network Surveillance
• Probe Surveillance
• Traffic Signal Control
• Traffic Metering
• HOV Lane Management
• Traffic Information Dissemination
• Regional Traffic Management
• Traffic Incident Management System
• Traffic Decision Support and Demand Management
• Electronic Toll Collection
• Emissions Monitoring and Management
• Roadside Lighting System Control
• Standard Railroad Grade Crossing
• Advanced Railroad Grade Crossing
• Railroad Operations Coordination
• Parking Facility Management
• Regional Parking Management
• Reversible Lane Management
• Speed Warning and Enforcement
• Drawbridge Management
• Roadway Closure Management
• Variable Speed Limits
• Dynamic Lane Management and Shoulder Use
• Dynamic Roadway Warning
• VMT Road User Payment
• Mixed Use Warning Systems

The National ITS Architecture also identifies communication and information-based standards. Such standards are especially relevant to a Virtual TMC, as its distributed architecture places a heavy emphasis on efficient and reliable communication. Among the pertinent national ITS standards development activities in process are the suite of standards being developed under the National Transportation Communications for ITS Protocol (NTCIP) effort. There are also a number of other existing communication and information-based standards that are applicable to ITS projects. The following list some of the applicable ITS standards with respect to data elements, message sets, and communication protocols.

Data elements:

• Traffic Management Data Dictionary (TMDD) - reference the Institute of Transportation Engineers (www.ite.org/TMDD).
• NTCIP standards for the communications with the various ITS devices such as traffic controllers, dynamic message signs, environmental monitoring stations, CCTV cameras and switches, ramp controllers, etc. (reference www.ntcip.org) and refer to document NTCIP 9001 for a guide to these standards.
• Advanced Traveler Information System (ATIS) data dictionary (SAE J2354).

Message sets:

• Transit Communication Interface Profile (TCIP) (APTA).
• Message Sets for External Traffic Management Center Communications (MS/ETMCC - now part of the ITE TMDD effort).
• Incident Management Message sets (IEEE-1512).
• Advanced Traveler Information System (ATIS) message sets (SAE J2354).

Communication protocols:

• National Transportation Communications for Intelligent Transportation Systems (ITS) Protocol (NTCIP). These protocols identify center-to-center and center-to-field communications protocols for a variety of media (e.g., analog telephone, Ethernet).

In addition to the ITS-specific standards involving communications data, messages, and protocols, existing and emerging standards are available for many ITS devices and/or their interfaces (e.g., signal controllers, video cameras, dynamic message signs, etc.). These standards can be reviewed and considered for incorporation into the Virtual TMC Project based on the appropriate engineering analyses.

3.2.6. Relevant Factors to Virtual TMC Planning

Other factors to consider in planning a Virtual TMC include:

• Virtual private networks (VPN) – Are they required to support agency IT guidelines or security preferences?
• Center-to-Center (C2C) systems – Which connections with other agencies are required and how technically will this be accomplished?
• CCTV and video feed sharing – Will video sharing be allowed and what technical solutions should be put in place if it is?
• Upgrade of field devices to current standards – Should the field communication network be upgraded to be more conducive to Virtual TMC Operations?
• Procurement of a common software application (e.g. ATMS system) to perform transportation management functions – Should new software packages be procured that better enable Virtual TMC Operations?
• Adequate levels of IT support. Support needs are likely to be greater than in a typical TMC setting – What kind or additional IT support may be required and how much?
• Well defined Memoranda of Understanding - Are any supplemental agreements between agencies needed (when a multiagency Virtual TMC model is being considered)?

3.2.7. Establishing a Core Management Team

Ensuring Key Stakeholder Representation

The implementation of a Virtual TMC requires a focused team to manage the project all the way from inception through the launch. This core management team should be answerable to and reflect the needs of the project's key stakeholders, including:

• Public/agency authorities: responsible for providing traffic management services and initiation of the project. These stakeholders are the driving force behind the Virtual TMC.
• Virtual TMC operator: responsible for providing the day-to-day Virtual TMC operations. Operators may be a public or private sector partner.
• Emergency services: key, highly-visible users of the Virtual TMC systems.
• Private sector: providing project support in various ways, from implementation (including ITS, materials, or personnel) or providing professional knowledge and expertise as a consultant.
• Technical advisors: responsible for providing expert technical advice and services as required.
• Legal advisors: responsible for providing legal advice, constructing contractual agreements, and continued legal support.

While the context of each Virtual TMC implementation is unique—each with different operational needs, institutional structures, and political environments—in all cases, it is critical to identify these key stakeholders and to bring them together around one table to ensure that the implemented project addresses the needs of the region.

Forming a Focused Core Project Team

It is important to ensure that the Virtual TMC project receives input from a variety of stakeholders, but the core project team itself should be small and focused in order to manage the project from inception through launch and to the full operation.

Since TMCs (and Virtual TMCs in particular) must rely on the integration of various technologies and data communication, it is important to establish an appropriate composition of partners in this core team with clear understanding of how each party will work within the management and administrative structure. This becomes especially important in public-private partnerships.

3.2.8. Implementing Data Storage and Archiving

Effective data management and data archiving for TMC and Virtual TMC operations is a critical component needed to improve coordinated operations and increase return on investment (ROI) for TMC projects. To maximize ROI for data storage and archiving it is recommended to initially approach data management through an agency and public benefit analysis as opposed to a typical functionality- and requirements-driven perspective.

In 2013 the Permanent Citizens Advisory Committee (PCAC) to New York City's Metropolitan Transportation Authority (MTA) provided several realized and projected benefits impacting internal and external stakeholders.³² In one example the PCAC stated that data analytics can help management make improvements across a series of stations. A software program that captures data from multiple departments, for example, could reflect the total rider experience at each station by displaying multiple metrics like ridership, service frequency, wait assessment, maintenance, capital improvements, injuries, and crime. If these data were then presented in a uniform way through a medium like data visualization, management could quickly identify stations that need attention as well as highlight stations that are excelling in a comprehensive way.

Figure 30 illustrates typical benefits.

Figure 30. Graph. Typical Transportation Data Benefits³³

The ability to collect and provide visual or analytical traffic data offers significant potential for improved services offered by traffic agencies. Once an agency has defined what data warehousing and analytical functions should be fulfilled by the system, the performance requirements and scalability for data storage and archiving can be evaluated more effectively.

The operational and functional requirements of a TMC data solution will dictate which agency data should be collected, and retention requirements for each data set. Typically storage requirements encompass diverse data types including:

• Congestion data (freeway and Arterial)
• Signal and Ramp Meter Status
• Vehicle Location Data
• Transit signal priority data
• Travel Time data
• DMS/CMS records
• Incident/Event Data
• Response plan data
• Environment data (ESS)
• CCTV Control Data
• CCTV Recordings

Many cloud hosting providers provide scalable storage for small and large data sets which are integrated with Business intelligence and visualization application platforms. This may be an attractive option for smaller agencies, multi-agency collaborations, or where long term usage and data size is not fully known.

Agencies that require on premise data warehousing due to security or functional requirements should be careful to select scalable storage and database solutions which can accommodate unexpected data growth and constantly evolving performance requirements.

For a large scale urban TMC, data storage capacity needs are typically in the range of 1 GB per week. A de facto guideline for TMC data storage is 13 months, although with the highly decreased cost of data storage drives, many years of data (e.g. 5 years or more of archived data) are now typically kept online for many TMC facilities, virtual or otherwise. The recommended data storage size for Virtual TMCs is 10 Terabytes to hold a minimum of 5- years of data.

3.2.9. Determining a Financial Model

Before determining the appropriate Financial Model to fund a Virtual TMC, a Financial Plan must be developed during the planning process. According to the TMC Business Planning and Plans Handbook, the Financial Plan "needs to address the TMC-specific funding requirements, and tie these requirements back to the Business Concept, Value Proposition, improvements required to develop the capabilities required, and the strategies and services needed to manage, operate, and maintain a TMC."

The Financial Plan is also the place where potential funding sources—typically Federal, State, and local—need to be identified. However, there may be opportunities to form Public-Private Partnerships (PPP) as well. Funding will largely depend on the Virtual TMC's jurisdiction, scope of services, functions, and coverage area. Traditionally, government funding has been provided for capital expenditure of new or renovated TMC facilities. There are a number of general funding programs available as shown in Table 18

Table 18. Available Funding Sources³⁴

Funding Resources	Eligibility		Qualifying Conditions
	Capital Expenditures	Operating Expenditures
National Highway System (NHS)	✓	✓	80/20 percent federal/local match with no time limit on operations
Surface Transportation Program (STP)	✓	✓	80/20 percent federal/local match within the initial project scope.
Interstate Maintenance (M)	✓	✓	90/10 percent federal/local match
Congestion Mitigation and Air Quality Improvement Program (CMAQ)	✓	✓	80/20 percent federal/local match for 2 years or longer if improvements are demonstrated.
SAFETEA/TEA-LU (TEA-21 Reauthorization)	✓	✓
ITS Integration	✓		50% federal integration funds 20% local funds 30% other federal or non-federal funds
National Corridor Planning and Development Program and Coordinated Border Infrastructure Program	✓		80/20 percent federal/local match
State Funding	✓	✓	Criteria varies per program
Local Funding	✓	✓	Criteria varies per program
Moving Ahead for Progress in the 21st Century – MAP 21			Criteria varies per grant
TIGER Grants			Safety, economic complexity, state of good repair, livability and environmental sustainability
DOT Grants			Criteria varies per grant
Source: FHWA, Transportation Management Center Business Planning and Plans Handbook, "Chapter 9. Financial Plan" (Washington, DC: 2005).

All of the programs listed above may become financial sources for the implementation and operation of Virtual TMCs. The programs are described in further detail below:

National Highway System (NHS) – Provides for capital and operating costs for traffic monitoring, management, and control facilities and programs. Funds provided on an 80/20 percent Federal/local match basis with no time limit for operations.

Surface Transportation Program (STP) – Provides for capital and operating costs for traffic monitoring, management, and control facilities and programs. Funds provided on an 80/20 percent Federal/local match basis within the initial project scope.

Congestion Mitigation and Air Quality Improvement Program (CMAQ) – Provides funds for the establishment or operation of a traffic monitoring, management, and control facility or program in nonattainment areas. Explicitly includes, as an eligible condition for funding, programs or projects that improve traffic flow. Funds are provided for O&M on an 80/20 percent Federal/local match basis for 2 years, or longer if the project demonstrates air quality improvement benefits on a continuing basis.

Interstate Maintenance – The Interstate Maintenance Program was created to provide funds to States to maintain previously completed sections of the Interstate System. Some states have used these funds for capital investments in Traffic Management Centers and operations that serve the Interstate System. Funds are provided on a 90/10 percent Federal/local match basis.

SAFETEA/TEALU (2004 Reauthorization Bill) – will also authorize several additional Federal funding mechanisms, which are available specifically to aid in the deployment and operation of ITS.

ITS Integration – This component of the ITS Deployment Program provides funding for activities necessary to integrate ITS infrastructure components that are either deployed (existing) or will be deployed with other sources of funds. This may include the integration of different ITS systems or subsystems (e.g., freeway management, arterial management, etc.) or the integration of ITS components across jurisdictions. Eligible activities include tsystem design and integration, creation of data sharing/archiving capabilities, and deployment of components that support integration with systems outside of metropolitan areas. The ITS Integration Program can fund up to 50 percent of an integration project's costs with a minimum of 20 percent of the local match to come from non-federally derived sources. The other 30 percent match could come from other Federal funds or nonfederal funds.

The National Corridor Planning and Development Program and Coordinated Border Infrastructure Program – was established under Sections 1118 and 1119 of the Transportation Equity Act for the 21st Century (TEA21). The Coordinated Border Infrastructure Program aims to improve border infrastructure and transportation telecommunications to facilitate the safe and efficient movement of people and goods at or across the U.S.-Canada and the U.S.-Mexico borders. The National Corridor Planning and Development Program provides DOT authority to allocate dollars to states and metropolitan planning organizations (MPOs) for coordinated planning, design and construction of highway corridors. Criteria under which the Border Program project funding applications will be reviewed include reduction in travel time through a major international facility, potential for improvements in border crossing vehicle safety and cargo security, and the applicability of innovative techniques and technology to other border crossing facilities. The Federal share for projects funded through these programs is 80 percent (sliding scale applies).

The following section provides an overview of the most common Financial Models available.

Financial Models

Single Agency Funding – In this model one agency funds the entire implementation and operations costs. Under this model, the agency has full control and no interagency coordination is required. However, it makes the single agency responsible for obtaining all funding.

Deployment Example: INFORM, Long Island New York

Funding Allocation Based On TMC Utilization – In this model costs are shared amongst various agencies including operating costs for facilities, computer system and telecommunications. Agencies co-located in the facility pay a utilization cost based on shared resources used. Depending on the agreement, some agencies may share the cost of pooled personnel (e.g. IT support, building security). This model is used in some large TMCs.

Deployment Example: Regional Traffic Management Centre, British Columbia

Funding Allocation Based on TMC Coverages – In this model, multiple agencies use one TMC, and cost is shared among the agencies based on the number of field devices in each jurisdiction that is sharing the TMC.

Deployment Example: FAST, Las Vegas Nevada

Funding from User Fees or Dues – This model largely depends on the nature of the TMC functions, and the services provided to end users (e.g. general public, transportation agencies, private entities) as it will be supported by user fees.

Deployment Example: TRANSCOM's Traffic Operations Center, New York and New Jersey.

Public-Private Partnerships (P3s) – This models involves a contractual agreement between a public agency and the private sector in the delivery of projects that can be mutually beneficial. In this collaboration it is crucial to identify each partner's responsibilities and budget sharing arrangements. This relationship is illustrated in Figure 31:

Figure 31. Graph. Public-Private-Partnerships Options³⁵

3.3. Security

The Virtual TMC (VTMC) model mandates a highly networked environment. This design may translate to a substantial increase in system exposure and potential risk when compared with a traditional TMC Model. This is especially true when the Virtual TMC model provides remote access to users and agencies through the internet, connecting to traffic devices over public networks, and interconnecting multiple agencies. A functional VTMC will require interfaces and possibly modifications to existing or planned ATMS systems. System security must be considered holistically for both VTMC and ATMS systems.

The potential impact to public safety and traffic operations which would be caused by an attack or availability failure of any Traffic Management System is very high. As such the security requirements between traditional TMCs and Virtual TMCs are similar. However, given the increased exposure to external risks presented by the Virtual TMC model, and risks associated with connection data system for multiple agencies, real consequences from security flaws are more likely to occur. Additional security measures will be needed to protect systems from external access, including robust firewalls, Intrusion detection systems, and encryption technologies. Stakeholders at each level of the agency must make a fundamental commitment to system security, from project initiation through end-of-life procedures.

The requirements for security each system will vary, it is therefore imperative that each agency or agencies agree upon a Risk Management process at project inception that will guide the creation of security requirements, and risk analysis throughout the project design and implementation. Risk Management and Defense in depth (RMDID), is a commonly used and well documented approach to system security which may benefit any agency seeking to improve or implement new security architecture. The following sections provides a high level path for implementing RMDID measures for Virtual Traffic Management Systems as part of the Systems development life-cycle (SDLC) guided through recommendations provided by The National Institute of Standards and Technology (NIST) 800 series publications. The NIST 800 series publications provide workable and cost-effective methods for optimizing the security of information technology (IT) systems and networks in a proactive manner.

Figure 32 demonstrates Key Risk Management tasks which should be addressed at each SDLC phase of a VTMC Project.^{36, 37} NIST SP 800 publications and additional reference documents which should be referenced during each phased of a Virtual TMC project development life-cycle are provided below.

Figure 32. Graph. Project Development Life Cycle³⁸

Risk Management Integration into SDLC

It is crucial that a security and risk management architecture is selected and implemented during the initial stages of any VTMC project. Risk Management measures must be balanced against agency requirements and cost limitations. Failure to address risks measured before procurement will have a significant impact on project budgets.

Senior leaders and executives must be committed to making risk management a fundamental mission requirement. This top-level, executive commitment ensures that sufficient resources are available to develop and implement effective risk management for a Virtual TMC.³⁹

Assignment of risk management responsibilities to senior leaders and executives should be completed at project inception.

Security planning should begin in the initiation phase with the identification of key security roles to be carried out during system development.

The information to be processed, transmitted, or stored should be identified and evaluated for security requirements, and all stakeholders should have a common understanding of the security considerations. Guidance is provided by NIST through two documents: NIST 800-60, Guide for Mapping Types of Information and Information Systems to Security categories (Revision 1), and FIPS 199, Standards for Security Categorization of Federal Information and Information Systems.

Beyond selection of key security roles and risk management process selection, the methods and depth of system security architecture will vary based upon project and agency requirements. The following reference documents provided by NIST SDLC may be adapted in whole or part by agencies when implementing a Virtual TMC system. Documents are available at http://csrc.nist.gov/publications/PubsSPs.html#800-30

Phase 1

SDLC P1 Task	Reference Document
1	SP 800-35 Guide to Information Technology Security Services
1	SP 800-27 Engineering Principles for Information Technology Security (A Baseline for Achieving Security)
2	SP 800-47 Security Guide for Interconnecting Information Technology Systems
3	SP 800-14 Generally Accepted Principles and Practices for Securing Information Technology Systems
3	SP 800-12  An Introduction to Computer Security: The NIST Handbook
4,4	FIPS 199 Standards for Security Categorization of Federal Information Systems
4,5	SP 800-60 Guide for Mapping Types of Information and Information Systems to Security Categories
6	SP 800-36 Guide to Selecting Information Technology Security Products
6	SP 800-23 Guidelines to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products
7	SP 800-30 Guide for Conducting Risk Assessments

Phase 2

SDLC P2 Task	Reference Document
1	SP 800-30 Risk Management Guide for Information Technology Systems
2	SP 800-53 Security Controls for Federal Information Systems
3	SP 800-53 Security Controls for Federal Information Systems
4	SP 800-36 Guide to Selecting Information Technology Security Products
4	SP 800-23 Guideline to Federal Organizations on Security Assurance and Acquisition / Use of Tested / Evaluated Products
5	SP 800-64 Security Considerations in the Information System Development Life Cycle
5	SP 800-36 Guide to Selecting Information Technology Security Products
6	SP 800-55 Security Metrics Guide for Information Technology Systems
7	Common Criteria; FIPS 140-2 Security Requirements for Cryptographic Modules

Phase 3

SDLC P3 Task	Reference Document
1	SP 800-64 Security Considerations in the Information System Development Life Cycle
1	SP 800-51 Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme
2	SP 800-64 Security Considerations in the Information System Development Life Cycle
3	SP 800-61 Computer Security Incident Handling Guide
3	SP 800-36 Guide to Selecting Information Technology Security Products
3	SP 800-35 Guide to Information Technology Security Services
3	SP 800-56 Recommendation Key Establishment Schemes
3	SP 800-57 Recommendation on Key Management
4	SP 800-55 Security Metrics Guide for Information Technology Systems
5	SP 800-37 Guide for the Security Certification and Accreditation of Federal Information Systems
5	SP 800-53A Guide for Assessing the Security Controls in Federal Information Systems
6	SP 800-37 Guide for the Security Certification and Accreditation of Federal Information Systems
7	SP 800-37 Guide for the Security Certification and Accreditation of Federal Information Systems

Phase 4

SDLC P4 Task	Reference Document
1	Handbook 150:2001, NVLAP Procedures and General Requirements
2	SP 800-26 Security Self-Assessment Guide for Information Technology Systems
3	SP 800-37 Guide for the Security Certification and Accreditation of Federal Information Systems
3	SP 800-53A Guide for Assessing the Security Controls in Federal Information Systems
4	SP 800-37 Guide for the Security Certification and Accreditation of Federal Information Systems
5	SP 800-61 Computer Security Incident Handling Guide
6	Handbook 150:2001, NVLAP Procedures and General Requirements
6	SP 800-55 Security Metrics Guide for Information Technology Systems
7	SP 800-61 Computer Security Incident Handling Guide
7	SP 800-31 Intrusion Detection Systems (IDS)
8	SP 800-34 Contingency Planning Guide for Information Technology Systems

Phase 5

SDLC P5 Task	Reference Document
1	SP 800-64 Security Considerations in the Information System Development Life Cycle
1	SP 800-35 Guide to Information Technology Security Services
3	SP 800-36 Guide to Selecting Information Technology Security Products
4	SP 800-14 Generally Accepted Principles and Practices for Securing Information Technology Systems
4	SP 800-12 An Introduction to Computer Security: the NIST Handbook

3.4. Developing a Training Program

3.4.1. Current TMC Training Practices

Many TMC training programs involve a classroom type setting. The training session is usually led by the system trainer and is accompanied by a PowerPoint presentation, specific manuals, and hands-on exercises.

Training sessions may take anywhere between 2 and 4 hours and have 8-10 personnel in attendance. Usually training may be separated into different sessions: one for operators and one for system administrators. System administrators participate in the operators' training as well as receiving more detailed system training.

3.4.2. How to Provide Training for Virtual TMCs

For Virtual TMCs, this training model needs to have some specific modifications. As described above, training sessions are tailored to the specific users (operators, maintenance, administrators). There are no clearly defined "roles and responsibilities" for a Virtual TMC operator. The TMC operator needs to be able to be an operator, an administrator, and a maintenance user. The training model for a Virtual TMC must be able to satisfy the flexible roles and responsibilities.

A training modification is for blurred roles and responsibilities. Many TMCs have multiple operators who have specific regions or responsibilities; i.e., contact maintenance, coordinate with roadway work crews, etc. With a Virtual TMC, these responsibilities reside within a single operator. This operator needs to be able to handle any of the various operations. Therefore the training session has to detail all the responsibilities, no matter the designation (operator or administrator).

Another distinctive modification is the classroom setting. In a physical TMC, there are multiple, dedicated workstations, as well as a training room. This may not be the situation for the Virtual TMC. Classroom training must now be performed as a one-to-one training or as part of a teleconference with multiple users. One-to-one training may not be cost or time effective, as the trainer must now perform the same training numerous times rather than in a single classroom session. A teleconference may be a more effective training tool for the Virtual TMC operators.

An effective training tool is the use of scenarios. Real-life examples allow the trainees, whether they are operators or administrators, to perform all actions needed for a real-life scenario. Scenarios should include unplanned events with minor lane blockage; unplanned events with major lane blockage, injuries, and fatalities; and responses to planned closures. Other scenarios should also include the more day-to-day activities, such as daily reports for events. Scenarios should also include the not-so-normal activities; e.g., the workstation has crashed or the internet connection has been lost. Training must include the actions that an operator needs to take to remain an active participant in the TMC operations.

Since an operator may be responsible for contacting other agencies as well as making decisions regarding notifying media personnel; training sessions and manuals must include the appropriate associated personnel from the media and other agencies. Again as part of the training sessions, information must be made available to allow the Virtual TMC operators to contact the necessary personnel. This list of personnel could be other agency contacts, maintenance contacts, and even IT personnel.