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:
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:
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.
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.
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.
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.
Virtual TMC stakeholders should agree upon and commit to eliminating any single point of failure in the Virtual TMC model. Typically this includes:
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.
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
Agencies must select one of three recommended paths or guidelines to implement C2F communications in the Virtual TMC Model:
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.
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.
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.
These data hubs should be created taking into account the common C2C standards used in the ITS market today:
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:
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:
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:
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
2. Impact if issue becomes a reality
L = Low Impact
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 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.
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:
3.2. The Planning Process
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:
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:
220.127.116.11. Stakeholder Identification
Stakeholder identification will largely depend on a series of factors unique to the context of the Virtual TMC scope, including:
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:
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:
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:
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.
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.
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:
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:
3.2.3. Organizational Considerations
18.104.22.168. 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 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:
22.214.171.124. 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:
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.
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:
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.
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.
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:
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.
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.
126.96.36.199. 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:
188.8.131.52. 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:
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.
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.
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.
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.
184.108.40.206. 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:
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
220.127.116.11. 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 Handbook27 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:
The typical options for these factors are summarized in Table 16 and are discussed in greater detail in the following sub sections.
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:
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.
Table 17 further expands upon the key components that should be contained in the Virtual TMC Business Plan.
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.
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.
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 http://www.ops.fhwa.dot.gov/publications/tptms/handbook/chapter_3.htm for additional information.)
This legislation imposed the following requirements:
Figure 29 depicts the various systems, sub-systems, and interconnects that comprise the National ITS Architecture.
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:
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.
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:
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:
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.32 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.
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:
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
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.
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:
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.
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.39
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
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.
20 FHWA, Systems Engineering for Intelligent Transportation Systems: An Introduction for Transportation Professionals. "Section 3.3.1 Overview of the "V" Model." [ Return to note 20. ]
21 FHWA, Regional ITS Architecture – Development, A Case Study - Gary-Chicago-Milwaukee ITS Priority Corridor, FHWA-JPO-99-022/FTA-TRI-99-03 (Washington, DC: 1999). [ Return to note 21. ]
22 USDOT, "A National Campaign for Improving Regional Transportation Operations," Presentation given at a special session of the National Association Working Group (NAWG), February 2004. [ Return to note 22. ]
23 Ibid. [ Return to note 23. ]
24 USDOT's 2011 Practitioner's Guide to Regional Concept for Transportation, p. 2. [ Return to note 24. ]
25 Ibid., p. 12 [ Return to note 25. ]
26 Ibid., p. 21. [ Return to note 26. ]
27 FHWA, Transportation Management Center Business Planning and Plans Handbook (Washington, DC: 2005). Available at: http://tmcpfs.ops.fhwa.dot.gov/cfprojects/uploaded_files/TMC_BPG_Final.pdf [ Return to note 27. ]
28 Ibid., "Chapter 1. Introduction and Overview." [ Return to note 28. ]
29 Ibid., "Figure 2-5. Relationship of ITS Planning Processes with the TMC Business Plan," p. 2-15. [ Return to note 29. ]
30 FHWA, Applying a Regional ITS Architecture to Support Planning for Operations: A Primer. http://ops.fhwa.dot.gov/publications/fhwahop12001/index.htm [ Return to note 30. ]
31 FHWA, ITS Architecture Implementation Program, "Figure 23 – National ITS Architecture – Sausage Diagram." http://ops.fhwa.dot.gov/its_arch_imp/its-integration-ohio/section443.htm [ Return to note 31. ]
33 S. Kaufman, "Getting Started with Open Data," Informally published manuscript, Rudin Center for Transportation Policy and Management (New York: New York University, 2012). [ Return to note 33. ]
34 TMC Business Planning and Plans Handbook, "Figure 2-5. Relationship of ITS Planning Processes with the TMC Business Plan", p. 2-15. [ Return to note 34. ]
36 Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology. ITL bulleting the system development life cycle SDLC (NIST ITL SDLC) (n.d.). Retrieved from website: http://csrc.nist.gov/publications/nistbul/april2009_system-development-life-cycle.pdf [ Return to note 36. ]
37 "Information Security System Development Life Cycle." Ready.Gov. N.p., 31 10 2011. Web. Retrieved from http://www.ready.gov/document/information-security-system-development-life-cycle on 10 Apr 2014. [ Return to note 37. ]
38 Ibid. [ Return to note 38. ]
39 Computer Security Division Information Technology Laboratory National Institute of Standards and Technology. (n.d.). Managing Information Security Risk (NIST SP 800-39). Retrieved from website: http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf [ Return to note 39. ]
United States Department of Transportation - Federal Highway Administration