Chapter 14 – Transportation
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
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
- 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
22.214.171.124 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).
- 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.
126.96.36.199 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).
Table 14-5: Outline – Concept of Operations (Source: Reference
Table of Contents
List of figures
List of tables
- Referenced documents
- Current system or situation
- Justification for and nature of changes
- Concepts for the proposed system
- Operational scenarios
- Summary of impacts
- Analysis of proposed system
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
||The concept of operations may be the first definitive expression
of how the TMCs functions will be performed. Thus, it can support
resource planning for the physical space requirements, hardware and
software specifications, the staffing, and some allocation of responsibilities
between the implementing parties.
||The concept of operations can serve, at successive levels of detail,
as a component of consensus building by the partners performing those
functions, who have already begun to define the requirements, as well
as the mission/vision/goals/objectives of the TMC.
|Training & Documentation
||The concept of operations also addresses the training program required
for the staff and the documentation that they will require in performance
of their duties.
||The concept of operations should also identify the interactions
between organizations involved in performing the TMC's functions.
Thus, it will identify the points at which agencies or functions within
an agency interact, and how that interaction may take place:
- Who initiates
- What information is provided
- What response is needed
- What communications means are applied
- How the response is confirmed
- What form the feedback loop takes to assess effectiveness, modify
the response if needed, and terminate it when appropriate.
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
- A location for coordinating and implementing freeway management strategies
- 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
- 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
- Add functions and responsibilities under joint operations at a manageable
- 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.
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
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
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
- 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
- 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.
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
- 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
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.
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).
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
- 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
- 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
Table 14-7: Criteria for Assigning Functions to Humans and Machines
|Humans Excel in ...
||Machines Excel in ...
|Detection of certain forms of very low energy levels
||Monitoring (both men and machines)
|Sensitivity to an extremely wide variety of stimuli
||Performing routine, repetitive, or very precise operations
|Perceiving patterns and making generalizations about them
||Responding very quickly to control signals
|Ability to store large amounts of information for long periods – and recalling relevant facts at appropriate moments
||Storing and recalling large amounts of information in short time
|Ability to exercise judgment where events cannot be completely defined
||Performing complex and rapid computation with high accuracy
|Improving and adopting flexible procedures
||Sensitivity to stimuli beyond the range of human sensitivity (infrared,
radio waves, etc.)
|Ability to react to unexpected low-probability events
||Doing many different things at one time
|Applying originality in closing problems (i.e., alternative solutions)
||Exerting large amounts of force smoothly and precisely
|Ability to profit from experience and alter course of action
||Insensitivity to extraneous factors
|Ability to perform fine manipulation, especially where misalignment
||Ability to repeat operations very rapidly, continuously, and precisely
the same way over a long period
|Ability to continue to perform when overloaded
||Operating in environments that are hostile to man or beyond human
|Ability to reason inductively
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
- 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
- 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
- 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
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
- Sufficient space and capacity to install additional computers and
- Spare or expandable communications capabilities.
- Additional office space for personnel from different operating agencies.