Freeway Management and Operations Handbook

Chapter 14 – Transportation Management Centers
Page 3 of 5

14.3 Implementation & Operational Considerations

Before the first brick can be laid for a TMC facility or any system hardware or software can be procured, there are a number of issues to be examined and understood. For example – What is the mission of the TMC? How will it operate? What systems will be included in it? Who will operate the systems included? How will the system be managed and maintained over time?

It is generally accepted that the best way to answer these and similar questions – for TMCs, for ITS-based systems, or for any large and complex systems (usually incorporating computers and software) – is to utilize the "systems engineering" process as introduced in Chapter 3 and discussed in greater detail below. At the same time, it must be emphasized that, as noted in the conclusions in the NCHRP synthesis on TMC functions (Reference 5), "some of the most critical issues affecting TMC design and deployment are policy issues, including jurisdictional, modal, institutional, and administrative concerns".

14.3.1 Systems Engineering

The literature contains many definitions for "systems engineering". The FHWA Technical Report "Building Quality Intelligent Transportation Systems Through Systems Engineering" (Reference 9) contains the following definition:

"Systems engineering is the process by which we build quality into complex systems. It uses a set of management and technical tools to analyze problems and provide structure to projects involving system development. It focuses on ensuring that requirements are adequately defined early in the process and that the system built satisfies all defined requirements. It ensures that systems are robust yet sufficiently flexible to meet a reasonable set of changing needs during the system's life. It helps manage projects to their cost and schedule constraints and keeps realism in project cost and schedule estimates."

Another way of describing system engineering is that it is a "requirements driven development process." That is, user requirements are the overriding determinant of system design, component selection and implementation. There should be no "gold plating" and you only pay for what you really need. The Systems Engineering process is more than just steps in system design and implementation; is a life cycle process. It recognizes that most systems are built incrementally and/or expand over time. The basic steps in the process do not change, but are spread out over time. There is an even stronger need to provide feedback and assessment with each incremental deployment phase so that future phases build on and expand the system, rather than simply replace elements of the earlier phases.

Systems engineering helps accomplish four key activities that impact a project's (and TMC's) success. These are (9):

• Identify and evaluate alternatives – The feasibility of each alternative must be measured from three different points of view: technical feasibility, cost feasibility, and schedule feasibility. Technical feasibility addresses whether we can build, maintain, and operate a system alternative, given the technology and people available to us. Cost feasibility looks at whether we can build, maintain, and operate a system alternative with the funds available for it. Schedule feasibility considers whether we can build a system alternative within the time frame allotted for its development. Usually we have to make trade-offs, deciding which alternative offers the better value.
• Manage uncertainty and risk – If we could accurately predict the future, it would be easy to avoid mistakes and problems. However, in real life, we need to deal with uncertainty and risk. Systems engineering focuses on three aspects of risk management: identification, analysis, and mitigation.
• Design quality into our systems – This is accomplished by addressing those factors that can negatively affect quality. Paraphrasing the International Organization for Standardization (ISO), we can define quality as "the totality of features of a system that bear on its ability to satisfy stated or implied needs." Among the factors that can negatively affect the quality of a system are its complexity, its inflexibility, its lack of standardized components, and its reliability and availability.
• Handle program management issues that arise – this requires a good project plan, one that is complete, comprehensive, and communicated. It should including all tasks that must be performed, accurately estimate the resources required to accomplish each task, assign the appropriate resources to each task, define all dependencies among tasks, identify all products or other criteria whose completion signifies that a task is done, and determine how to measure progress against plan when managing the project.

Another management consideration is that the process is most effective when the managers and engineers have domain knowledge about the system being built (including TMCs). Domain knowledge is a fundamental understanding of the technology and functions involved in the system being built. In an ITS system, for example, domain knowledge includes transportation engineering or transit system management. Without domain knowledge, a manager and systems engineer are not as effective.

ITS project development – including TMC hardware and software – has increasingly used the structured systems engineering approach as a means to improve the chance for success. FHWA sponsors a 2-day course entitled "An Overview of Systems Engineering" (10) and has produced several technical documents on the subject (9, 11), with the stated goal "to introduce systems engineering to managers and staff working on Intelligent Transportation Systems (ITS) projects, if they aren't already familiar with its practice". Another course on applying systems engineering to ITS projects – "Applied Systems Engineering for Advanced Transportation" – is offered over the Internet (for a fee) by the Consortium for ITS Training and Education (CITE) (Reference 12). The Federal Highway Administrations Final Rule 940 (13) on ITS Architecture and Standards requires that "all ITS projects be developed using a systems engineering analysis commensurate with the project scope".

References 9 and 10 utilize the "V" (or "VEE") model as a way of showing the systems engineering process and relating the different stages in the system life cycle to one another. The "V" model, illustrated in Figure 14-10 shows the early stages in building a system / TMC as steps along the left leg of the "V," the decomposition leg of the process. The steps on this decomposition leg break the system down into its pieces, proceeding from development of a Concept of Operations for the system / TMC, through the definition and refinement of the system's requirements (going from high-level to detailed requirements), to the system / TMC design stage, which also goes from high-level to detailed design. At the bottom of the "V" is the Implementation stage, which represents the transition from decomposition (the conceptual level) to re-composition (the physical level). During this stage, the system's / TMC's design is transformed into actual products. On the right-hand leg of the "V" are the re-composition steps, where all the parts of the system / TMC are tested and put together. As one proceeds up the right-hand leg, the system's building blocks are combined into larger and larger pieces, resulting in a finally assembled and installed (i.e., complete) system / TMC.

The "V" model helps to emphasize the importance of evaluation in all stages of a system / TMC project. In the early stages of the system life cycle (the left leg of the "V" model), one is using mostly inspection and analysis as evaluation tools. In the later stages of the system life cycle (the right leg of the "V" model), the primary evaluation tool is testing. Regardless of which leg of the "V" model one is on, evaluation efforts are combined with system development activities.

Each of the "steps" / activities shown in the "V" model are summarized below in general terms, followed by a brief TMC-focused discussion. It is emphasized that while the systems engineering process is oriented towards ITS, TMCs, and individual projects, the various steps identified in the V-diagram nonetheless closely parallel the "steps" identified in Chapter 3 (i.e., the "funnel diagram" in Figure 3-1) for establishing a freeway management and operations program.

Figure 14-10: "V" Diagram D

14.3.1.1 Needs Analysis

The needs analysis determines problems that need to be solved. In conducting a needs analysis, there may be some preliminary steps that you have to take to put your effort into the proper context (11). They are:

• Understand the local institutional environment – There are a number of local factors that could affect the requirements on ITS / TMC projects. These include the political situation (e.g., what can realistically be done, in light of who wields political power and what power they have); receptivity to innovation and new ways of doing business (e.g., will local operators and citizens fight some or all proposed changes to the transportation system); willingness to invest in ITS solutions; and local laws and regulations.
• Determine Stakeholders – A stakeholder is anyone who has an interest in the success of the ITS project (a "stake" as it were). Stakeholders include users, politicians, and the public. Each stakeholder has some idea of what he or she wants the system / TMC to do, and their particular needs ultimately determine which ITS components are implemented, and how available funds get apportioned to improve local transportation and satisfy the local constituency. It is therefore important to determine the potential users of all ITS services under consideration (including the TMC) and their primary concerns; others who may be affected directly or indirectly by ITS services and the TMC, but who will not be users; and persons or organizations with a strong material interest in success or failure of ITS solutions. The stakeholders are sources of requirements and they are also ones who validate or verify the requirements. In particular, the principal stakeholders – the ones for whom this system is key to doing their job, including those agencies that will ultimately be housed within the TMC – must be identified. A list of potential stakeholders for a freeway management system and TMC is provided in Table 3-1 (in Chapter 3).

As part of the needs analysis, it also important to recognize and understand the broader vision, goals, and objectives that have been established for the surface transportation network and the freeway management program. The functions that are ultimately allocated to the center should support these goals and objectives – that is, the TMC (and any ITS-based system) should be viewed as a tool for accomplishing the goals and objectives of the agencies involved.

14.3.1.2 Concept of Operations

The concept of operations is a formal document that provides a user-oriented view or "vision" of the system / TMC. It is developed to help communicate this vision to the other stakeholders and to solicit their feedback. To develop a concept of operations, several basic questions must be asked, among which are: do we know who all the users will be; do we know how the users will interact with the proposed system; is how we plan to operate the system consistent with all systems with which it must interact; and have we coordinated with all other agencies affected by this system (11).

The content of a Concept of Operations document is spelled out in a standard (Note: IEEE Std 1362-1998, IEEE Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document) from the Institute of Electronic and Electrical Engineers (IEEE), one the major U.S. standards bodies. Table 14-5 illustrates the outline of a Concept of Operations document, as specified in that standard (9).

A few key points are provided in Reference 9 regarding this outline.

• The last subsection in the Justification section documents assumptions and constraints. Putting assumptions and constraints in writing makes it easier to communicate them to all interested parties. And, if any assumptions or constraints change during the project, one can go back and see what effect they had and what impact a changed assumption or constraint would have on how the system evolves.
• The fifth Concept of Operations section, Concepts for the proposed system, gives one the opportunity to lay out the system and explain how he/she thinks it will work, once it's in operation. This is a key section, because it shows the intended users of the system how the new system will affect them. It's a good tool for setting or managing user expectation for the new system.
• The sixth Concept of Operations section, Operational scenarios, allows one to describe specific cases of system use. Some like to use flow diagrams to illustrate operational scenarios; others like to use a narrative approach, sort of a "Day in the Life of ..." approach.

TMC Concept of Operations

The importance of early planning cannot be overstated. The "1-10-100 rule" states that for every dollar spent rectifying an error or problem in the planning stage would cost $10 to rectify in design and $100 in implementation or operation stages. The agency desiring to implement a TMC faces a significant challenge in defining to its system designer exactly what the agency wants designed, what functions and features are to be included, and how the agency wants it designed. Without this guidance, the designer may either make a "best guess" at the agency's needs and desires, or may come forward with a solution which was developed to meet the needs of another (possibly quite dissimilar) agency and transportation situation. There are many systems in the world today that were built flawlessly, and operate exactly as they were designed. Unfortunately, they weren't designed with operational specifics and don't do what the agencies need them to do.

As noted in the "Transportation Management Center Concepts of Operation Implementation Guide" (Reference 14) (Note: Available from the TMC PFS web site):

"An agency implementing a TMC should plan the TMC as carefully as it would plan any high-cost, high-visibility investment. An important tool in such planning is a 'concept of operations.' It develops answers to the questions 'What do we want to do?' and 'How do we do it?' for the TMC. It also guides many areas of preparation for the facility. It looks closely at the functions which the TMC must perform and the broader functions whose performance the TMC supports. The concept of operations is often the first detailed examination of the idea for implementing a TMC. It will provide guidance and direction to help ensure that the subsequent procurements result in the type of facility and systems that best serve the agency's needs, and which represent an effective utilization of limited budgetary funds. It will also assure that the operational needs of the TMC are consistent with the resources and policies of the responsible agencies. Thus, a path can be laid for successful operations and maintenance, realizing the maximum possible benefit from the investment."

Reference 14 identifies the following examples where the TMC Concept of Operations can serve an important purpose:

The Concept of Operations for the TMC should also identify its purpose or role in the overall freeway management program. The functions of a TMC can vary from location to location, depending upon the local operating goals and visions / philosophies for the freeway management program. The development and design of the TMC needs to support the desired operating philosophy. For example, an agency whose primary goal is information dissemination may want to design a TMC that allows easy access to the information in the system by outside users; while an agency that wants close interaction with other operating agencies (fire, police, emergency services, etc.) may want to provide a physical location in the TMC for those agencies to have staff (e.g., dispatch their emergency response personnel and resources). Common roles/functions of a TMC in freeway management systems include the following:

• A location for coordinating and implementing freeway management strategies and controls.
• A dispatching center for incident management and maintenance forces.
• A location for doing maintenance and repairs of malfunctioning or damaged field equipment.
• A central location for distributing freeway traffic and travel information to travelers, elected officials, and the media.
• A command post for coordinating the response to major emergencies or weather events.

TMC Joint Operations

A major question that must be addressed during the initial planning stages and the Concept of Operations is what agencies need to be in the TMC, the responsibilities of their respective staffs within the TMC, and how they will interact. Depending upon local needs and operating philosophy, operating personnel can come from a variety of agencies and entities, including state transportation agencies, regional and local transportation agencies, police and emergency service providers, local transit authorities, and private media and traffic reporting services.

The resulting joint operations can be structured administratively to occur in different ways, such that varying levels of functional and management control are centralized or individual control is maintained. Joint operation can be structured through the following:

• Sharing physical resources that are common to each agency's operation, but operating each system or agency component individually. This could occur through use of a common communications system.
• Operating individual or multiple systems under one designated management structure where operational control is centralized. This could occur by time of day where peak periods are under central control and off-peak is under local jurisdictional or functional agency control. Typically, the participating parties establish operating guidelines that are carried out by an individual agency or group, with the goal being to establish coordinated ongoing operations.
• Delegating day-to-day operations to another agency or group (including a private entity). This type of operation could entail turning the operations and maintenance of individual devices over to another agency under a defined set of conditions (e.g., Transcom operation of certain CMSs and HARs in the region surrounding New York City).

The ability to engage in joint operations is not an easy accomplishment and usually occurs because of ongoing relationship building. A variety of strategies can be undertaken to foster cooperative joint operations. No one individual technique or action is appropriate for all areas; instead, each community must assess its own unique situation. Strategies that can be employed to foster cooperative and joint operations in a TMC include the following:

• Ensure that each agency is represented in defining goals and objectives and in the initial stages of planning and developing the traffic management program. An invitation to be involved in the planning and design of the TMC should also be extended.
• Emphasize how the program can include projects that address the needs and problems of each agency. Look for ways to widen the focus of the initial goals of the system to help other agencies improve their operations.
• Approach joint operations with an open attitude about how overall results can be enhanced by sharing resources.
• To facilitate sharing and build trust among agencies, start joint operations with a relatively small and noncritical task. Building confidence and trust around these smaller elements will facilitate the accomplishment of larger tasks in the future.
• Develop an open-ended and flexible system architecture such that new systems and changes in hardware and operating procedures can be accommodated easily.
• Add functions and responsibilities under joint operations at a manageable rate.
• Develop standard operating procedures for how the devices in the system can be used by each agency in the control room. These operating procedures should be scenario-based and describe the roles and responsibilities of each agency in the scenario.
• Cross-train the staff from each agency so that they can do the jobs of the other agencies' staffs, and so that each operator has an understanding of the roles, responsibilities and limitations of each agency in the TMC and can serve as a backup or substitute in crises.
• Provide a mechanism for positively, reviewing and debriefing each other's operations with the idea of improving the overall operations and capabilities of the system.

14.3.1.3 Requirements

In this stage, a determination is made – in a more detailed manner than in the concept of operations, what the system / TMC should do. This stage can run through several iterative cycles of defining, reviewing, and refining the requirements. A key point related to this phase is that the end product must be a set of requirements on whose meaning everyone agrees.

Requirements are statements of the capabilities that a system / TMC must have (i.e., "functions"), geared to addressing the mission-oriented objectives of the organization for which the system is built. For requirements to be most useful, they should be statements of what is desired, not descriptions of how the need should be satisfied – that is, good functional requirements are written without specifying implementation details.

Functional requirements are based on facts, not "wish lists" or misperceptions about what's needed to do a job. Questions should always be asked such as: "What's the reason for this requirement?" "What critical purpose does it meet?" "What happens if we don't provide this capability?" In particular, measures should be established that permit the quantification of requirements. It's better to have a requirement that states the need to support "10,000 devices" than one that says you have to be "able to expand the system to accommodate future growth." The first requirement can be verified; the second is not verifiable. (11).

Written requirements are important. A written requirements document captures what you're trying to achieve with this system in a tangible form, one that others can read and review and interpret. Attributes of good functional requirements include (11):

• Necessary. Something that must be included or an important element of the system is missing and other system components can't compensate for its absence.
• Concise (minimal, understandable). Stated in language that is easy to read, yet conveys the essence of what is needed.
• Attainable (achievable or feasible). A realistic capability that can be implemented for the available money, with the available resources, in the available time.
• Complete (standalone). Described in a manner that does not force the reader to look at additional text to know what the requirement means.
• Consistent. Does not contradict other stated requirements nor is it contradicted by other requirements. In addition, uses terms and language that means the same from one requirements statement to the next.
• Unambiguous. Open to only one interpretation.
• Verifiable. Must be able to determine that the requirement has been met through one of four possible methods: inspection, analysis, demonstration, or test.

One way to eliminate ambiguity is to conduct a System Requirements Review or "walkthrough". A System Requirements Review brings in representatives from each stakeholder and walks them through each requirement one-by-one. This is a critical step in the process of getting requirements done properly. It's important to make sure that all the stakeholders interpret all requirements the same way. This is a critical step in the overall process – if everyone doesn't have the same interpretation, some will have expectations that won't be met, and the wrong capabilities may end up being implemented.

TMC Requirements

A Mission Analysis is an exercise that may be useful to agencies in identifying the functions and operational requirements of a TMC. Traditionally, two methods are used to conduct a mission analysis: a mission profile and scenario development.

• A mission profile is a detailed description of normal system operations that occur during a given system activity or over a given interval of time. It consists of listing all the activities to be done by various elements in the total system – operators, supervisors, automated subsystems, sensors, etc. The list also includes any activities done simultaneously (e.g., automated tasks done by system hardware, operator assessments, operator decisions). Activities are described at a high level and no attempt is made to define the roles of the operators or automated system in doing them. This technique provides an organized, high-level framework of system requirements that will support subsequent, detailed design analysis.
• With the scenario development technique, descriptions of specific scenarios – non-routine but typical situations that would burden (challenge) the capabilities of the TMC – are sometimes useful in providing an understanding of the TMC's functions and operational concepts. The scenarios should describe what actions and information are needed to manage traffic during different operating situations such as freeway incidents, major traffic stressors (e.g., large athletic events, inclement weather), or strategic planning episodes.

Table 14-6 lists some possible generic functions of freeway management TMCs. Note that these functions describe what it is the system does; it does not define whether activities are done by humans, by automated equipment, or by a human using a computer.

14.3.1.4 Design

This stage involves deciding "how" each requirement in the system is satisfied. The FHWA course on Systems Engineering (10) defines system design as the "appropriate selection of system components and their interconnection so as to meet the system requirements, and the preparation of specifications that describe the design." The design stage consists of several activities, including generating alternatives, assessing the alternatives (e.g., technical and operational feasibility, institutional compatibility, life-cycle costs, constraints), considering the conditions that impact operations and maintenance (e.g., staff capabilities and availability, environment, available facilities, training and documentation needs) and standards. The "ilities" – reliability, maintainability, availability, and affordability – must also be considered.

It is important to ensure, as the design evolves and becomes more detailed, that the design retains its internal consistency. If groups working independently on parts of the system design fail to communicate effectively, it may be difficult to make the system's pieces mesh during implementation. This can be accomplished via design reviews. Design reviews generally fall into two major categories: Preliminary Design Reviews and Critical Design Reviews. A Preliminary Design Review (PDR) is conducted on each component of the system. The PDR assesses the progress, technical adequacy, and risk mitigation involved in the selected design approach; determines whether the item being reviewed is compatible with defined performance requirements; estimates the degree of technical risk remaining; and verifies the existence and compatibility of all interfaces involved. The Critical Design Review (CDR) is conducted when the design for each component is complete. The CDR ensures that the item under review satisfies all requirements allocated to it; ensures that the item is compatible with all other items in the system; and assesses whether there is any remaining risk associated with the item (9).

TMC Design

To ensure proper design, it is important to begin with a user-centered approach to developing a TMC. A user-centered approach applies system engineering and human factors principles to developing a system design that focuses on what the system is supposed to accomplish rather than on technology, with the selection and acquisition of system components based on the validated functional requirements. The distinguishing features of a user-centered development philosophy as compared with other approaches include the following:

• The focus is on the operator, not the designer. In the user-centered development, the user (i.e., the operator) is viewed as a critical system component. The characteristics, capabilities, and limitations of the user need to be defined and considered during the requirements analysis and design of the system. Ideally, the user should be involved in the planning and design processes at their earliest stages and this involvement should continue throughout the design and testing phases.
• The process is iterative. Systems are best developed through an iterative process, in which a design is tested and validated in a series of stages. This is particularly important in TMC development, where the multiple iterations can uncover problems – and opportunities – that are not apparent until they are viewed in the total system.
• The process extends throughout the life cycle of the TMC. The fact that a new TMC has been built and put into operation does not suggest that it is "complete." As the managers and operators of the TMC become familiar with the system, they will make recommendations for adding many excellent features and procedural changes to improve their abilities to control traffic on the freeway.

The design process for a TMC includes defining the functional relationships, data requirements, and information flows. This involves the following activities:

• Allocating TMC functions to operators, computer/machine components in the system, or a combination of both.
• Analyzing the tasks required to complete each function.
• Establishing how data flow from one function to the next.

Each of these tasks is discussed below.

Function Allocation – In the design of the TMC, function allocation involves assigning system functions to machine components, human operators, or a combination of human and machine components. Using criteria similar to those shown in Table 14-7, each function (or process) is assigned to a human or machine component. Properly allocating functions is critical to ensuring that operators in the TMC perform tasks that are within their capabilities and do not become overloaded. The Human Factors Handbook for Advanced Traffic Management Center Design (6) presents techniques for allocating functions to human operators and machine components.

The allocation of functions in the TMC is usually the first point in the design process at which critical decisions must be made about the role of the operator. It is also a point at which mistakes, if not identified and corrected in design iterations, can cause serious design deficiency. One common misconception that occurs in allocating functions is the presumption that a single set of functions should be handled solely by an operator, and another set should be handled solely by machines. In fact, many critical functions in the TMC can best be handled by the integrated efforts of humans and machines. Identifying these partly automated tasks requires detailed study and analysis. Failing to identify them properly and assign proper interface strategies causes serious operational problems. General guidelines and design considerations for allocating functions in a TMC include the following:

• If environmental constraints limit human performance, the function should be allocated to a machine.
• Events that cannot easily be perceived by humans (such as changing levels of traffic moving past a point on a freeway) should be allocated to machines.
• When a function requires a response that is beyond the speed or accuracy of human capabilities, it should be allocated to a machine.
• If the speed and volume of information derived or needed by a function is beyond the capabilities of a human, it should be allocated to a machine.
• If the information produced by a function is beyond the memory capabilities of a human, it should be allocated to a machine.
• If a function is to be performed continuously, it should be allocated to a machine.
• If the interruption of, and response to, unusual or unexpected events are required, the function should be allocated to a human
• Allocate functions so that they make the best use of human abilities.
• Avoid decisions based solely on the ease or difficulty of automation; consider how allocating different functions between humans and machines affects total system performance.
• Avoid allocating functions in such a way that both humans and machines are forced to work at their peak limits all or most of the time.
• Allocate functions to humans so that they can recognize or feel that they are making an important and meaningful contribution to the performance of the system.
• Allocate functions between humans and machines so that a natural flow and processing of information can occur.
• Assign tasks that require extremely precise manipulations, continuous and repetitive tasks, or lengthy and laborious calculations to a machine.
• Design human/system interfaces on the presumption that the human might at some point have to take control of the system.
• Use hardware and software to aid the operator; do not use the operator to complement a predetermined hardware/software design.

Task Analysis – After functions have been allocated to human operators and system components, the next step in designing a TMC is to identify the tasks that make up system functions. Each function includes one or more tasks. A task is an independent action, carried out either by an operator or by a machine that results in an identifiable outcome. Tasks can frequently be decomposed into discrete subtasks that represent activities that are distinct enough to be analyzed separately, but are clearly contributing to the identified task.

Once the tasks have been identified, they can be grouped to form operational flow or process diagrams. The operational flow diagrams allow designers to identify the actions, information requirements, processes, and decisions that need to be made to accomplish a function. Operational flow diagrams are useful tools in the design process, because they allow designers to readily identify the following elements:

• The types of data required in the TMC.
• The decision-support aids needed to complete operational tasks.
• The data-storage requirements of various processes and tasks in the TMC.
• The types of outputs and decisions produced by each task.

Data Flows – Establishing data flows is a critical step in designing a TMC. Data flows describe the type and frequency of data needed to execute each function of the TMC. This step in the design process is important because it allows system designers to assess the communications requirements of each component in the TMC. Establishing the data flows also helps to identify the structure of the data streams needed to operate each function of the system.

One way to depict data flow is through data flow diagrams. With data flow diagrams, large circles are used to represent sources and destinations of data. The sources/ destinations can be either subsystems or functions within subsystems. Lines connecting data sources and destinations are used to represent the type of data that flows between two elements of the system. Each data type is labeled so that designers know what information is flowing between components. An example of a typical data flow is provided in Figure 14-11. Data flow diagrams need to be prepared for each level of design detail and for each subsystem within the TMC.

Figure 14-11: Typical Data Flow Diagram D

Select System Technologies / TMC Layout – Only after the functions of the TMC have been identified and the data flow requirements assessed should designers begin designing the physical layout and the support elements and related technologies of the TMC. In planning the TMC, system designers need to be concerned with the following elements:

• The physical environment in which the operators and equipment will function.
• The design and operations of the operators' workstations.
• The design of the controls and displays that the operators will use to operate the system.
• The design of the interfaces through which the operators will be presented with information and initiate control decisions.

These technologies and TMC elements are discussed in previous section 14.2.

Another important design issue is system expansion. Freeway Management Systems (FMS) can expand operations in many ways, including an increase the number of freeways and/or roadway facilities covered; adding new freeway management functions; accommodating joint or cooperative operations of several agencies from one location; and serving as a command post for major emergencies. With these potential expansion scenarios in mind, it is critical that agencies plan and design for future expansion in the TMC by providing the following:

• Adequate space in the operations room to install additional operator consoles/ workstations.
• Sufficient space and capacity to install additional computers and peripherals.
• Spare or expandable communications capabilities.
• Additional office space for personnel from different operating agencies.