1 Executive Overview

In the late 1980’s, the transportation community envisioned Intelligent Transportation Systems [ITS] as a tool for transportation practitioners to make transportation facilities more efficient and to encourage a more regional view of transportation. What was not well understood at the time, was the extent of new skills, capabilities, and interagency cooperation the transportation agencies would need to meet those goals. There was no recognition of the importance of addressing life cycle operations & maintenance. Now, there is an awareness of these key ITS challenges. To address them, systems engineering was introduced to the ITS community. It resonated with a number of ITS practitioners. As a result, the FHWA issued 23 CFR 940 and the FTA issued a policy that requires all ITS projects funded with highway trust funds be based on systems engineering analysis.

The goal of this Guidebook is to help agencies use common, consistent, and well-established systems engineering tools and processes to:

Improve the quality of Intelligent Transportation Systems

Systems engineering thinking promotes increased up-front planning and system definition prior to technology identification and implementation. Documenting stakeholder needs, expectations, the way the system is to operate [Concept of Operations], and the system requirements [WHAT the system is to do] prior to implementation leads to improved system quality.

Reduce the risk of cost and schedule overruns

Systems engineering promotes stakeholder involvement throughout project development and improves project control with clearly defined decision points [Control Gates]. With the up-front planning described above, the risk of costly rework and schedule slips during later stages of implementation are greatly reduced.

Gain wide stakeholder participation

Participation of stakeholders is essential for successful system developments. Using a common and standard development process enables stakeholders to understand and actively participate in the development. Plus, it reduces the learning curve when new stakeholders get involved in a project. A common process ensures a wider set of resources [staff, expertise] that agencies can draw upon within the project life cycle.

Maintain, operate, and evolve the Intelligent Transportation System

Project developments that use a systems engineering approach will improve the documentation of the system [requirements, design, verification, development, and support documentation]. Having such documentation will improve the long-term operations & maintenance, of the system. Good documentation will make it easier to upgrade and expand the system.

Maintain consistency with the regional and state ITS architectures

Once a regional ITS architecture is developed and projects are defined, a common and clear roadmap for ITS project development is laid out. A systems engineering approach enables consistency with the regional ITS architecture to be verified and maintained.

Provide flexibility in procurement options for the agencies

Intelligent Transportation Systems that are well documented have greater flexibility for procurement options. Proprietary developments are minimized, proprietary sub-systems are identified, and the use of industry standard interfaces are promoted. This enables alternate system integrators and consultants to support the agencies in upgrades and system expansion. In other words, it minimizes the agencies' need to be "locked into" a specific vendor or system integrator.

Keep current with the rapid evolution of technology

One of the challenges for agencies is staying current with the rapid changes in technology. Intelligent Transportation Systems are long term investments for agencies. So it is important to avoid technology obsolescence. In other words, when field devices fail, the agency should be able to replace them without a major development effort and without maintaining large inventories of obsolete technology. Systems engineering promotes system modularity and the use of standard interfaces where possible. When a technology changes or is unavailable, the functionality can be replaced with minimal impact to other parts of the system [goal of plug and play].

For whom was this Guidebook designed?

This following are this Guidebook's primary audience:

• Agencies that plan, implement, manage, and operate Intelligent Transportation Systems
• Management that champions ITS projects
• ITS practitioners

Secondarily, this Guidebook will help consultants and system integrators [who would be potential contractors for the agencies] gain an understanding of the required systems engineering processes. This Guidebook identifies roles and responsibilities for project development and provides a common process and language so that agencies, system integrators, and consultants can have the same understanding as to what is to be expected when developing ITS projects.

How should this Guidebook be used and what is in it?

This Guidebook is a reference to help practitioners as follows:

• Develop Requests for Proposals
• Assess capabilities of potential Systems Managers [Systems Engineering Technical Assistance, and Independent Verification & Validation consultants]
• Support development teams [System Integrators] in the implementation of ITS projects.

It is also meant as a help guide for the ITS practitioner throughout the development of ITS projects.

The Guidebook provides guidance for the following: [this list is not all inclusive]

• Life cycle phases for Intelligent Transportation Systems
• Activities needed to carry out each development task [based on industry best practices]
• Tailoring development activities to fit large and small projects [tailoring up and tailoring down, respectively]
• Roles and responsibilities in project development
• Important activities that the system’s owner needs to be involved with
• Activities to ensure that all the bases are covered for each activity
• Tips, cautions, and other essential information needed for a task
• Applicable industry standards
• Templates for the development of key project documents
• Example case studies to assist the practitioner in tailoring the processes for their project

What does the Guidebook NOT cover?

This Guidebook was not intended to be an in-depth textbook on systems engineering. Chapter 8 has reference material that will direct the reader to a number of books, papers, and standards on the market that provide excellent material to augment this Guidebook. This Guidebook does not provide guidance for the development of regional architectures. That is covered in "Regional ITS Architecture Guidance: Developing, Using & Maintaining an ITS Architecture for Your Regions" prepared by the National Architecture development team.

How is this Guidebook organized?

Figure 1‑1 illustrates the organization of the Guidebook. The outer layer, the Executive Summary, provides an overview of the Guidebook. The next layer is a closer look at the systems engineering environment. Then, the steps of processes and cross-cutting activities are described. This is followed by the foundation of roles, responsibilities, and capabilities needed. All are accompanied with example references and supporting materials.

Figure1‑1 Organization of the SE Guidebook

Understand the Guidebook and the systems engineering process [Ch 2]. The first step is to understand the organization of the Guidebook and the necessary steps of the systems engineering process. These chapters will point the reader to the relevant overview chapters. Chapter 1, Executive Summary, gives a short overview of the entire Guidebook. This is intended for managers or others who wish a quick view of the processes and key concepts presented here. Chapter 2 places the Guidebook into context in terms of purpose and scope.

Follow the systems engineering process [Ch 3.1 – 3.8]. This is the heart of the Guidebook. The process follows the six phases shown in the center of the diagram. Chapter 3.1 provides an overview, diagrammatic roadmap, and links to the key discussions in Chapter 3. The other chapters correspond to the major phases of project development: needs assessment & Concept Exploration, project planning & concept of operations, system definition, system development & implementation, operations & maintenance, and retirement/replacement. A control gate, that must be passed in order to proceed, follows each phase.

Initiate cross-cutting activities [Ch 3.9]. There are several important activities that are ongoing [continually or repeatedly] throughout the systems engineering process. These include elicitation, project management, acquisition planning, generation of deliverables & documentation, process improvement, configuration management, interface management, risk management, program metrics, control gates, trade studies, technical reviews, and stakeholder involvement. These activities support the tasks carried out during the six phases.

Analyze and prepare the systems engineering environment [Ch 4 ]. There are many factors that both support and constrain the systems engineering process for ITS. The Guidebook user needs to be familiar with these factors before starting work. Examples are: the National ITS Architecture, FHWA Final Rule, ITS standards, and agency roles & responsibilities. This chapter also provides a guide to tailoring the systems engineering process to fit the particular project. Example projects are described so the ITS practitioners will have guidance on tailoring the systems engineering process for their project size and complexity

Case Studies [Ch 5] provides a summary of real world case studies for New York Transit Agency, Baltimore ATMS project, and the Maryland Chart program. Ch 8.5 provides the complete case study description for each of the projects.

Form the project team [Ch 6 and 7. These chapters discuss the typical roles, responsibilities, and capabilities of:

• Agencies
• Consultants
• Developers

While such roles vary greatly from agency to agency, this Guidebook will provide guidance in putting together a project team.

Appendices [Ch 1] contain the following information:

• Acronyms and glossary terms
• Reference materials for more in-depth reading [books, websites, and standards]
• Templates & guidance for contract and systems engineering documents
• Complete Case Studies.