Freeway Management and Operations Handbook

Chapter 3 – Freeway Management Programs
Page 2 of 2

3.3 Projects

"Projects" are well-defined, individual actions and activities that make up a substantial portion of a program (along with policies, procedures, and other actions). The development and implementation of projects is a how an on-going program is realized, and subsequently updated to reflect changes in the operating environment. Most, if not all, freeway management and operations programs incorporate some of the technologies and strategies associated with Intelligent Transportation System (although it is important to always remember that freeway management and operations is not limited to just ITS). As such, many freeway management programs will include projects to develop, design, implement, and expand freeway management systems that incorporate advanced technologies and complex software. This section summarizes a number of published processes that are geared towards ITS deployment – specifically, systems engineering, configuration management, and regional ITS architectures. While these processes are oriented towards ITS and individual projects, they nonetheless closely parallel the various "steps" identified in the previous section for establishing a freeway management and operations program.

3.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 2) 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 success. These are (2):

• 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 in our systems – 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.

References 2 and 6 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 3-2 shows the early stages in building a system 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, through the definition and refinement of the system's requirements (going from high-level to detailed requirements), to the system 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 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 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.

Figure 3-2: V-Diagram (Reference 2) D

The "V" model helps to emphasize the importance of evaluation in all stages of a system 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. Additional information regarding the individual steps that comprise the "V" systems engineering model is provided in Chapter 14.

As previously noted, one of the key activities of the systems engineering process is to manage risk. This means ferreting out the issues and potential problems that can affect the end-project. Table 3-2 contains a set of questions – listed by each step shown in the "V" diagram – that can be asked to help identify issues and potential problems. The questions are at a high level. As you answer them, other, more detailed questions will arise.

3.3.2 Configuration Management

Freeway management programs (and their associated freeway management systems) are ongoing endeavors. More often than not, the program and systems are implemented in small increments, with functions and areas of coverage being added over time. The institutional landscape – which influences policy and funding decisions – is also subject to change during the life-cycle. Changes in program and system requirements are therefore inevitable. A goal of a freeway management practitioner should not be to avoid making changes, but to keep the requirements change process under control through a process known as "Configuration Management." Configuration Management includes procedures and techniques that allow the practitioner to consider and evaluate the impacts of proposed changes, and then to track and document those changes that are made.

Configuration management is a part of the systems engineering process and a critical element in the life of any system. It is particularly important in those systems that are software intensive. But configuration management principles and procedures are also applicable in the broader context of a freeway management program. The concept can and should be expanded to include operations and management strategies – not just technical systems. In other words, the term "configuration" in configuration management can refer to the entire set of items that make up a freeway management program, including policies, system hardware and software, documentation, operational procedures, freeway geometrics and associated infrastructure (e.g., signing and lighting), incident management strategies, work zone procedures, and anything else that makes up the description and embodiment of a the program.

The process is described in more detail in the document "Configuration Management (CM) for Transportation Management Systems" (Reference 10), the contents of which are summarized below and in Chapter 14. It is noted that the processes and procedures of CM have been developing in the information technology community for many years. Accordingly, Reference 10 makes use of a standard developed and refined in the IT industry – the Electronic Industries Alliance (EIA) Standard 649 National Consensus Standard for Configuration Management (ANSI/EIA-649/-1998), referred to EIA 649. Reference 10 is oriented towards ITS-based transportation management systems. But as is the case with other "systems" processes described herein, by changing a few key terms (e.g., "system" into "program", "TMS" into "freeway operations") and expanding the context, the CM process can be "converted" and used for the overall freeway management and operations program.

There are two fundamental purposes of Configuration Management (CM) – to establish system integrity, and to maintain system integrity. A system with integrity is one in which:

• All components are well defined and documented
• A working baseline is always available to implement and provide transportation management services
• Integration with other regional systems can readily be accomplished
• A high degree of traceability exists, allowing one to easily identify how system functions are provided.

In other words, a system with integrity is one that is available and functional.

CM provides a holistic approach for effectively controlling system change. It helps to verify that changes to subsystems are considered in terms of the entire system, minimizing adverse effects. Changes to the system are proposed, evaluated and implemented using a standardized, systematic approach that ensures consistency. All proposed changes are evaluated in terms of their anticipated impact on the entire system. CM also verifies that changes are carried out as prescribed and that documentation of items and systems reflects their true configuration. A complete CM Program includes provisions for the storing, tracking and updating of all system information on a component, subsystem and system basis. This provides TMS managers with an up-to-date baseline of their system.

The CM process may be (and ideally should be) applied throughout the system life cycle. This allows TMS management to track requirements throughout the life cycle through acceptance and operations and maintenance. As changes are inevitably made to the requirements and design, they must be approved and documented, creating an accurate record of the status of the system. The general CM process is described graphically in Figure 3-3. Additional information regarding these CM activities is provided in Chapter 14.

Figure 3-3: Configuration Management Process (Reference 10) D

3.3.3 FHWA Rule on Regional ITS Architectures

FHWA Rule 940 (4), which became effective in 2001, implements section 5206(e) of the Transportation Equity Act for the 21st Century (TEA-21), and requires ITS projects to conform to the National ITS Architecture and standards. The rule states that "conformance with the National ITS Architecture is interpreted to mean the use of the National ITS Architecture to develop a regional ITS architecture, and the subsequent adherence of all ITS projects to that regional ITS architecture." Per the rule, "a regional ITS architecture shall be developed to guide the development of ITS projects and programs and be consistent with ITS strategies and projects contained in applicable transportation plans. The National ITS Architecture shall be used as a resource in the development of the regional ITS architecture. The regional ITS architecture shall be on a scale commensurate with the scope of ITS investment in the region. Provision should be made to include participation from the following agencies, as appropriate, in the development of the regional ITS architecture: Highway agencies; public safety agencies (e.g., police, fire, emergency/medical); transit operators; Federal lands agencies; State motor carrier agencies; and other operating agencies necessary to fully address regional ITS integration."

Freeway practitioners interact with many of the agencies noted above. Moreover, given that freeway management systems will often be a major component of a regional ITS architecture (Note: Regional integration is discussed in Chapter 16), and that freeway management system projects funded in whole or in part with the highway trust fund must conform to this rule, it is important that freeway practitioners be cognizant of the rule and be involved in any process for developing a regional ITS architecture.

While not identifying a process, per se, Rule 940 identifies what the regional architecture shall include as a minimum – specifically:

• A description of the region;
• Identification of participating agencies and other stakeholders;
• An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the systems included in the regional ITS architecture;
• Any agreements (existing or new) required for operations, including at a minimum those affecting ITS project interoperability, utilization of ITS related standards, and the operation of the projects identified in the regional ITS architecture;
• System functional requirements;
• Interface requirements and information exchanges with planned and existing systems and subsystems (for example, subsystems and architecture flows as defined in the National ITS Architecture);
• Identification of ITS standards supporting regional and national interoperability; and
• The sequence of projects required for implementation.

Additionally, the rule states that all ITS projects (funded with highway trust funds) shall be based on a "systems engineering analysis", and that this analysis shall include identification of participating agencies, requirements definition, analysis of alternative system configurations and technology options, procurement options, identification of applicable standards and testing procedures, and procedures and resources necessary for operations and management of the system.

The Regional ITS Architecture Guidance Document (5) describes a process for creating a regional ITS architecture with supporting examples of each architecture product. This document is a guide for transportation professionals who are involved in the development, use, or maintenance of regional ITS architectures. The guidance is structured around the following process:

• Step #1: Get Started
  • Identify Need
  • Define Region
  • Identify Stakeholders
  • Identify Champions
• Step #2: Gather Data
  • Inventory Systems
  • Determine Needs and Services
  • Develop Operational Concept
  • Define Functional Requirements
• Step #3: Define Interfaces
  • Identify Interconnects
  • Define Information Flows
• Step #4: Implementation
  • Define Project Sequencing
  • Develop List of Agency Agreements
  • Identify ITS Standards
• Step #5: Use the Architecture
• Step #6: Maintain the Architecture

Each of these steps and associated activities are discussed in Chapter 16 herein (Regional Integration). As is the case with the other system-oriented processes, these steps parallel many of the activities identified in the "funnel" diagram in Figure 3-1.

3.3.4 National ITS Architecture

As previously noted, FHWA Rule 940 (4) requires ITS projects to conform to the National ITS Architecture and standards. The rule states that "conformance with the National ITS Architecture is interpreted to mean the use of the National ITS Architecture to develop a regional ITS architecture, and the subsequent adherence of all ITS projects to that regional ITS architecture." Since most, if not all, freeway management programs incorporate some of the technologies and strategies associated with Intelligent Transportation Systems, a basic knowledge and understanding of the terms and concepts of the National ITS Architecture is important for freeway management practitioners. This section provides an overview of the National ITS Architecture. Additional information on the National ITS Architecture as well as information on available training can be found at the FHWA's ITS Joint Program Office website: www.its.dot.gov and then clicking on "Architecture" at the top of the page. A link to http://www.iteris.com/itsarch/ is provided where the many documents describing the National ITS Architecture (11) may be found.

3.3.4.1 Background

A system architecture is a framework that describes how system components interact and work together to achieve the system's goals. The architecture – or framework – describes the system operation, what each component does and what information is exchanged among the components. While it may be somewhat abstract, the architecture provides the tool for defining interfaces between systems, subsystems, and system components, and identifying the communications necessary to achieve integration of the systems and subsystems.

The National ITS Architecture provides a common structure for the design of intelligent transportation systems. It is not a system design nor is it a design concept. It is the framework around which multiple design approaches can be developed, each one specifically tailored to meet the individual needs of the user, while maintaining the benefits of a common architecture (e.g., compatibility and interoperability between systems, products, and services; without limiting design options). The architecture defines the functions that must be performed to implement a given service, the physical entities or subsystems where these functions reside (e.g., the roadside or the vehicle), the interfaces/information flows between the physical subsystems, and the communication requirements for the information flows (e.g., wireline or wireless). The National ITS Architecture also provides a common vocabulary to facilitate internal and external communications with colleagues and others involved in transportation planning. In addition, it identifies and specifies the requirements for the standards needed to support national and regional interoperability, as well as product standards needed to support economy of scale considerations in deployment.

3.3.4.2 Attributes

The National Architecture utilizes a layered framework consisting of three layers—transportation, communications, and institutional. The transportation and communications layers are "technical" layers in which the actual components reside. The institutional layer is a non-technical layer that establishes the policies, funding incentives, working arrangements, and jurisdictional structures that support the technical layers – in essence, where the aforementioned planning for operations and associated collaborations take place.

Figure 3-4 provides a high-level view of the framework of the physical architecture.

Figure 3-4: High Level Architecture Diagram (Reference 11) D

This "links-and-sausages" diagram includes both the transportation and communication layers of the Architecture. The transportation layer includes 21 interconnected subsystems (depicted as rectangles), distributed among four classes –Traveler, Center, Roadside, and Vehicle – depicted as larger, colored encompassing rectangles.

• Center Subsystems deal with those functions normally assigned to public/private administrative, management, or planning agencies. It is emphasized that the Center Subsystems are functionally, not physically defined. They should not be viewed as "brick and mortar" facilities. Rather, they represent a cohesive set of functional definitions with required interfaces to other Subsystems. The implementation of a physical Transportation Management Center will often collocate the functions and capabilities from several of the Center Subsystems.
• Roadside Subsystems include functions that require convenient access to a roadside location for the deployment of sensors, signals, changeable message signs or other interfaces with travelers and vehicles of all types.
• Vehicle Subsystems are installed in a vehicle. They include such functions as advanced vehicle control and safety systems, and in-vehicle signage and information.
• Traveler Subsystems represent platforms for ITS functions of interest to travelers or commercial vehicle operators in support of multimodal traveling.
• Communication Links support the exchange of information (referred to as either information flows or architecture flows) between the subsystems. The National ITS Architecture has identified four communication media types (shown as ovals) to support the communications requirements between the 21 subsystems – wireline (fixed-to-fixed), wide area wireless (fixed-to-mobile), dedicated short-range communications (fixed-to-mobile), and vehicle-to-vehicle (mobile-to-mobile).

In addition to the physical architecture, the National ITS Architecture includes a Logical Architecture that presents a functional view of the ITS User Services. This perspective is divorced from likely implementations and physical interface requirements. It defines the functions or process specifications that are required to perform ITS user services, and the data flows that need to be exchanged between these functions. The logical architecture groups processes and data flows to form particular transportation management functions (e.g., manage traffic), which are represented graphically by data flow diagrams (DFDs), or bubble charts, which decompose into several levels of detail.

3.3.4.3 User Services

User Services identify what ITS should do from the user's perspective. A broad range of users are considered, including the traveling public as well as many different types of system operators. The concept of user services allows system or project definition to begin by establishing the high level services that will be provided to address identified problems and needs. The user services have been bundled into the following eight categories:

• Travel and Traffic Management
• Public Transportation Management
• Electronic Payment
• Commercial Vehicle Operations
• Emergency Management
• Advanced Vehicle Safety Systems
• Information Management
• Maintenance and Construction Management

New or updated user services have been and will continue to be added over time.

3.3.4.4 Market Packages

Some of the user services are too broad in scope to be convenient in planning actual deployments. Additionally, they often don't translate easily into existing institutional environments and don't distinguish between major levels of functionality. In order to address these concerns (in the context of providing a more meaningful evaluation), a finer grained set of deployment-oriented ITS service building blocks – called Market Packages – were defined from the original user services. Market packages, are tailored to fit – separately or in combination – real world transportation problems and needs. They provide another method for entering into the National ITS Architecture, and can be used as a starting point for defining functional requirements and system specifications. Market 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, market packages may change and new market packages may be defined. Several of the market packages associated with freeway management and operations are identified in subsequent chapters.

3.3.5 Standards

The International Standards Organization (ISO) defines standards as documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose. The National ITS Architecture identifies standard requirements based on the interfaces between subsystems in the physical architecture, the associated information flows and data flows that pass across those interfaces, and some indications of the class of technology suitable for each interface. An actual standard would dictate a specific interface (or interfaces), specific message sets and protocols, and specific technology for implementation.

The USDOT ITS JPO's Standards website (www.standards.its.dot.gov) provides current status on the ITS Standards Program. It also contains resource documents, fact sheets, testing, deployment contacts, training and application area information as well as an interactive ITS Standards Forum. A link is also provided to the ITS Data Registry, a growing repository of elements of the ITS Standards.

3.3.5.1 NTCIP

Of particular interest to the freeway practitioner involved in ITS is the NTCIP (National Transportation Communications for ITS Protocol) suite of standard communications protocols and data definitions that have been designed to accommodate the diverse needs of various subsystems and user services of the National ITS Architecture. NTCIP standards are intended to handle these needs in the following two areas:

• The first type of communications is between a management system or center and multiple control or monitoring devices managed by that system or center, such as a freeway management system communicating with detectors and ramp meters on freeways, and a traffic management system controlling CCTV cameras, dynamic message signs, advisory radio transmitters, environmental sensors and traffic count stations on roadways. Since most applications of this type involve a computer at a management center communicating with various devices at the roadside or on agency vehicles, this type is referred to as center-to-field (C2F) communications.
• The second type of communication involves messages sent between two or more central management systems, such as an emergency management system reporting an incident to a freeway management system and a traveler information system, and a weather monitoring system informing a freeway management system of ice forming on the roadway so that the freeway management system is able to post appropriate warning messages on dynamic message signs. This type of communication is referred to as center-to-center (C2C) communications. Even if two or more of the various center subsystems are located within the same "center" or building, they are still considered logically separate. C2C involves peer-to-peer communications between any number of system computers in a many-to-many network. This type of communication is similar to the Internet, in that any center can request information from, or provide information to, any number of other centers. Additional information regarding C2C standards is provided in Chapter 16.

NTCIP provides the mechanism whereby interchangeability and interoperability amongst the various components of transportation systems can be achieved, where "interchangeability" is defined as the capability to exchange devices of the same type (e.g., a signal controller from different vendors) without changing the software; and "interoperability" is defined as the capability to operate devices from different manufacturers, or different device types on the same communications channel. Specific NTCIP standards are discussed in more detail in subsequent chapters. Additional information regarding NTCIP may be found on the NTCIP website (www.ntcip.org), including the NTCIP Guide (12).

3.4 Maintenance Considerations

The processes and the associated steps summarized above focus on planning, developing, implementing, operating, and managing a transportation management system. This includes freeway management strategies, which are addressed in more detail in subsequent chapters. Another crucial element of a system's life cycle is maintenance. Freeway Management Systems (FMS) are complex, integrated amalgamations of hardware, technologies and processes for data acquisition, command and control, computing and communication. Accordingly, FMS maintenance can be a complex proposition as well, requiring sophisticated approaches and advanced technology. Maintenance of the FMS is a necessity to ensure reliability and proper operation, thereby protecting the investment and enabling the system to respond to changing conditions. Failure to function as intended could negatively impact traffic safety, reduce system capacity, and ultimately lead the traveling public to lose faith in their transportation system. Failure of the system also has the potential to cause measurable economic loss and increase congestion, fuel consumption, pollutants, and traffic accidents. In essence, loss of a device due to a malfunction is an operations issue. Maintenance is part of management and operations.

There are several references that address maintenance of transportation management systems and components, including the ITE publication "Traffic Control System Operations – Installation, Management and Maintenance" (Reference 13) and "Guidelines For Transportation Management Systems Maintenance Concepts and Plans" (Reference 14). Both documents discuss maintenance management (e.g., organizational structure, personnel and staffing), options for performing maintenance (e.g., in-house, contract), and guidelines for performing maintenance on a variety of system components - the former document addressing field devices, computers, and communications; the latter focusing more on Transportation Management Centers.

Maintenance considerations must be an integral part of any process to develop a freeway management program and / or system, and must be part of all the steps and activities in that process – for example, involving maintenance stakeholders, developing a maintenance concept, including maintenance and replacement costs in the life cycle analyses of alternative technologies / components, identifying maintenance functional requirements, including resources to carry out maintenance functions in the resource allocation process, etc. In this manner the freeway management program and any enabling systems will include the necessary resources, environment, and procedures to maintain the infrastructure associated with the program / system; transportation management center and its associated infrastructure.

3.5 References

1. "Regional Transportation Operations Collaboration and Coordination, a Primer for Working Together To Improve Transportation Safety, Reliability, and Security", FHWA, Publication FHWA-OP-03-008, 2002

2. "Building Quality Intelligent Transportation Systems Through Systems Engineering", Mitretek Systems, April 2002

3. "Applied Systems Engineering for Advanced Transportation", CITE (Course Registration is available through the CITE website at www.citeconsortium.org.)

4. FHWA Rule 940, National Register, January 8, 2001

5. Regional ITS Architecture Guidance Document; "Developing, Using, and Maintaining an ITS Architecture for your Region; draft prepared by National ITS Architecture Team; October, 2001

6. "An Overview of Systems Engineering", FHWA 2-day course

7. NCHRP Project 8-35: Incorporating ITS into the Transportation Planning Process, "Integrated Practitioners Planning Guidebook - Draft", July 2000

8. Integrating Intelligent Transportation Systems within the Transportation Planning Process: An Interim Handbook, FHWA, January 1998

9. "Developing Functional Requirements for ITS Projects", Mitretek Systems, April 2002

10. "Configuration Management for Transportation Management Systems", 2003 (Available from the TMC Pooled Fund Study website http://tmcpfs.ops.fhwa.dot.gov)

11. The ITS National Architecture, Documentation – Version 4.0, April 2002

12. "NTCIP Guide – Updated Version 3", AASHTO, ITE, NEMA, October 2002

13. "Guidelines For Transportation Management Systems Maintenance Concepts and Plans", PB Farradyne, July, 2002 (Available from the TMC Pooled Fund Study website http://tmcpfs.ops.fhwa.dot.gov)

14. Kraft, W. and Giblin, J., "Traffic Control Systems Operations - Installation, Management, and Maintenance", ITE, 2000

15. "Incident Management Handbook", November 2000