**Regional ITS Architecture Maintenance**

![](media/image1.jpeg){width="5.988888888888889in"
height="4.444444444444445in"}**White Paper**

**January 31, 2004**

TECHNICAL REPORT DOCUMENTATION PAGE

+----------------------+-------+---+----------+----------+-----------+
| 1\. Report No.       | 2\.   |   |          | 3\.      |           |
|                      | Gover |   |          | Reci     |           |
| FHWA-HOP-04-004      | nment |   |          | pient\'s |           |
|                      | Acce  |   |          | Catalog  |           |
|                      | ssion |   |          | No.      |           |
|                      | No.   |   |          |          |           |
+----------------------+-------+---+----------+----------+-----------+
| 4\. Title and        |       |   |          | 5\.      |           |
| Subtitle             |       |   |          | Report   |           |
|                      |       |   |          | Date     |           |
| Regional ITS         |       |   |          |          |           |
| Architecture         |       |   |          | January  |           |
| Maintenance White    |       |   |          | 31, 2004 |           |
| Paper                |       |   |          |          |           |
+----------------------+-------+---+----------+----------+-----------+
|                      |       |   |          | 6\.      |           |
|                      |       |   |          | Pe       |           |
|                      |       |   |          | rforming |           |
|                      |       |   |          | Orga     |           |
|                      |       |   |          | nization |           |
|                      |       |   |          | Code     |           |
+----------------------+-------+---+----------+----------+-----------+
| 7\. Author(s)        |       |   |          | 8\.      |           |
|                      |       |   |          | Pe       |           |
| National ITS         |       |   |          | rforming |           |
| Architecture Team    |       |   |          | Orga     |           |
|                      |       |   |          | nization |           |
|                      |       |   |          | Report   |           |
|                      |       |   |          | No.      |           |
+----------------------+-------+---+----------+----------+-----------+
| 9\. Performing       |       |   |          | 10\.     |           |
| Organization Name    |       |   |          | Work     |           |
| and Address          |       |   |          | Unit No. |           |
|                      |       |   |          |          |           |
| Iteris-1515 S.       |       |   |          |          |           |
| Manchester           |       |   |          |          |           |
| Ave/Anaheim, CA      |       |   |          |          |           |
| 92802                |       |   |          |          |           |
|                      |       |   |          |          |           |
| Lockheed Martin-     |       |   |          |          |           |
| 9500 Godwin          |       |   |          |          |           |
| Dr./Manassas, Va     |       |   |          |          |           |
| 20110                |       |   |          |          |           |
|                      |       |   |          |          |           |
| Consensus Sys.       |       |   |          |          |           |
| Technologies -POB    |       |   |          |          |           |
| 501,17 Miller        |       |   |          |          |           |
| Ave/Shenorock, NY    |       |   |          |          |           |
| 10587                |       |   |          |          |           |
|                      |       |   |          |          |           |
| R.C. Ice and         |       |   |          |          |           |
| Associates-27155 Big |       |   |          |          |           |
| Horn Mountain        |       |   |          |          |           |
| Way/Yorba Linda, CA  |       |   |          |          |           |
| 92887                |       |   |          |          |           |
+----------------------+-------+---+----------+----------+-----------+
|                      |       |   |          | 11\.     |           |
|                      |       |   |          | Contract |           |
|                      |       |   |          | or Grant |           |
|                      |       |   |          | No.      |           |
|                      |       |   |          |          |           |
|                      |       |   |          | D        |           |
|                      |       |   |          | TFH61-01 |           |
|                      |       |   |          | -C-00023 |           |
+----------------------+-------+---+----------+----------+-----------+
| 12\. Sponsoring      |       |   |          | 13\.     |           |
| Agency Name and      |       |   |          | Type of  |           |
| Address              |       |   |          | Report   |           |
|                      |       |   |          | and      |           |
|                      |       |   |          | Period   |           |
|                      |       |   |          | Covered  |           |
|                      |       |   |          |          |           |
|                      |       |   |          | White    |           |
|                      |       |   |          | paper    |           |
+----------------------+-------+---+----------+----------+-----------+
| Department of        |       |   |          | 14\.     |           |
| Transportation       |       |   |          | Sp       |           |
|                      |       |   |          | onsoring |           |
| Intelligent          |       |   |          | Agency   |           |
| Transportation       |       |   |          | Code     |           |
| Systems Joint        |       |   |          |          |           |
| Program Office       |       |   |          |          |           |
|                      |       |   |          |          |           |
| 400 7th Street,      |       |   |          |          |           |
| S.W., Room 3416      |       |   |          |          |           |
|                      |       |   |          |          |           |
| Washington, Dc 20590 |       |   |          |          |           |
+----------------------+-------+---+----------+----------+-----------+
| 15\. Supplementary   |       |   |          |          |           |
| Notes                |       |   |          |          |           |
+----------------------+-------+---+----------+----------+-----------+
| 16\. Abstract        |       |   |          |          |           |
|                      |       |   |          |          |           |
| This white paper is  |       |   |          |          |           |
| a guide for          |       |   |          |          |           |
| transportation       |       |   |          |          |           |
| professionals who    |       |   |          |          |           |
| are involved in the  |       |   |          |          |           |
| development, use and |       |   |          |          |           |
| maintenance of       |       |   |          |          |           |
| regional ITS         |       |   |          |          |           |
| architectures. It    |       |   |          |          |           |
| provides guidance on |       |   |          |          |           |
| what should be       |       |   |          |          |           |
| contained in an      |       |   |          |          |           |
| architecture         |       |   |          |          |           |
| maintenance plan and |       |   |          |          |           |
| on the process of    |       |   |          |          |           |
| maintaining the      |       |   |          |          |           |
| architecture.        |       |   |          |          |           |
+----------------------+-------+---+----------+----------+-----------+
| 17\. Keywords        |       |   | 18\.     |          |           |
|                      |       |   | Dist     |          |           |
| ITS, Architecture,   |       |   | ribution |          |           |
| Maintenance,         |       |   | S        |          |           |
| Configuration        |       |   | tatement |          |           |
| Management.          |       |   |          |          |           |
|                      |       |   | No       |          |           |
|                      |       |   | restr    |          |           |
|                      |       |   | ictions. |          |           |
|                      |       |   | This     |          |           |
|                      |       |   | document |          |           |
|                      |       |   | is       |          |           |
|                      |       |   | a        |          |           |
|                      |       |   | vailable |          |           |
|                      |       |   | to the   |          |           |
|                      |       |   | public   |          |           |
|                      |       |   | from the |          |           |
|                      |       |   | sp       |          |           |
|                      |       |   | onsoring |          |           |
|                      |       |   | agency.  |          |           |
+----------------------+-------+---+----------+----------+-----------+
| 19\. Security        | 20\.  |   |          | 21\. No. | 22\.      |
| Classification (of   | Sec   |   |          | of Pages | Price     |
| this report)         | urity |   |          |          |           |
|                      | Clas  |   |          | 42       |           |
| Unclassified         | sific |   |          |          |           |
|                      | ation |   |          |          |           |
|                      | (of   |   |          |          |           |
|                      | this  |   |          |          |           |
|                      | page) |   |          |          |           |
|                      |       |   |          |          |           |
|                      | Un    |   |          |          |           |
|                      | class |   |          |          |           |
|                      | ified |   |          |          |           |
+----------------------+-------+---+----------+----------+-----------+

Table of Contents

[1 Introduction 1](#introduction)

[2 Why does a regional ITS architecture need to be maintained?
2](#why-does-a-regional-its-architecture-need-to-be-maintained)

[3 Maintenance decisions 3](#maintenance-decisions)

[3.1 Who will maintain the Regional ITS Architecture?
4](#who-will-maintain-the-regional-its-architecture)

[3.2 When will the architecture be updated?
6](#when-will-the-architecture-be-updated)

[3.3 What will be maintained? 7](#what-will-be-maintained)

[4 Maintenance Process 9](#maintenance-process)

[4.1 Configuration Management Overview
9](#configuration-management-overview)

[4.2 Architecture Maintenance Process
10](#architecture-maintenance-process)

[4.2.1 Configuration Management Planning
10](#configuration-management-planning)

[4.2.2 Configuration Identification 16](#configuration-identification)

[4.2.3 Configuration Control 16](#configuration-control)

[4.2.4 Configuration Status Accounting
17](#configuration-status-accounting)

[4.2.5 Configuration Audits 18](#configuration-audits)

[4.3 Effort required for maintenance
18](#effort-required-for-maintenance)

[5 Conclusions 19](#conclusions)

**REGIONAL ITS ARCHITECTURE MAINTENANCE WHITE PAPER**

# Introduction

This white paper is a guide for transportation professionals who are
involved in the development, use and maintenance of regional ITS
architectures. It supplements the Regional ITS Architecture Guidance
Document dated October 2001 by providing a more detailed guide for the
development of a regional ITS architecture maintenance plan and the
activities involved in maintaining a regional ITS architecture.

A **Regional ITS Architecture** is: "A regional framework for ensuring
institutional agreement and technical integration for the implementation
of ITS projects or groups of projects."[^1] In January 2001, FHWA
published a Final Rule (ITS Architecture and Standards) and FTA
published a companion Final Policy that requires each region with ITS
projects using funds from the Highway Trust Fund to create a regional
ITS architecture adopted by its stakeholders by April 8, 2005, or within
four years of the date that its first ITS project advances to final
design. The Final Rule/ Final Policy requires that, at a minimum, a
regional ITS architecture shall include:

> •  Description of the region;
>
> •  Identification of the participating agencies and stakeholders;
>
> •  An operational concept that identifies roles and responsibilities
> of stakeholders;
>
> •  Any agreements required for operations;
>
> •  System functional requirements (high level);
>
> •  Interface requirements and information exchanges with planned and
> existing systems and subsystems;
>
> •  Identification of ITS standards supporting regional and national
> interoperability; and
>
> •  Sequence of projects required for implementation

The development of an architecture maintenance plan and the
implementation of a program to maintain the architecture is also a
requirement of the ITS Architecture and Standards Final Rule/ Final
Policy, which says: "*The agencies and other stakeholders participating
in the development of the regional ITS architecture shall develop and
implement procedures and responsibilities for maintaining it, as needs
evolve within the region."*

The development and use of a regional ITS architecture are fully
described in the Regional ITS Architecture Guidance Document dated
October 2001 and will not be further discussed in this white paper. The
guidance document can be obtained on CD from FHWA division
representatives or downloaded from the FHWA's ITS Electronic Document
Library at
<http://www.itsdocs.fhwa.dot.gov//JPODOCS/REPTS_TE//13598.pdf>. The
guidance document discusses maintenance of the regional ITS
architecture, and white paper builds upon that discussion, providing a
maintenance process and laying out the activities needed to effectively
maintain a regional ITS architecture.

**Regional ITS Architecture Maintenance**

As ITS projects are implemented, the regional ITS architecture will need
to be updated to reflect new ITS priorities and strategies that emerge
through the transportation planning process, to account for expansion in
ITS scope, and to allow for the evolution and incorporation of new
ideas. A maintenance process should be detailed for the region, and used
to update the regional ITS architecture. This maintenance process should
be documented as part of the initial development of the regional ITS
architecture in a regional ITS architecture maintenance plan. The goal
of the maintenance plan is to guide controlled updates to the regional
ITS architecture baseline so that it continues to accurately reflect the
region's existing ITS capabilities and future plans.

**What's covered in this white paper?**

Section 2 of the white paper discusses why maintenance of a regional ITS
architecture is needed. Section 3 begins the discussion of the
maintenance process by addressing decisions that must be made regarding
who is responsible for maintenance, what is maintained, and the timing
of maintenance actions. Section 4 presents the maintenance process and
section 5 presents conclusions. Appendix A contains examples of change
requests, change database logs and topics for the architecture
maintenance plan. Finally, Appendix B contains several actual
maintenance plans. References from these example maintenance plans serve
as examples throughout the paper. Note that the process of architecture
maintenance covered in this white paper is meant to apply to a wide
range of regional and statewide ITS architecture developments. Each
architecture development effort will need to tailor the process to meet
the needs and resources of their particular region.

# Why does a regional ITS architecture need to be maintained?

The regional ITS architecture is not static. It must change as plans
change, ITS projects are implemented, and the ITS needs and services
evolve in the region. The regional ITS architecture must be maintained
so that it continues to reflect the current and planned ITS systems,
interconnections, and other aspects of architecture. The following list
includes many of the events that may cause change to a regional ITS
architecture:

-   **Changes in Regional Needs.** Regional ITS architectures are
    created to support transportation planning in addressing regional
    needs. Over time these needs can change and the corresponding
    aspects of the regional ITS architecture that address these needs
    may need to be updated. These changes in needs should be expressed
    in updates to planning documents such as the Regional Transportation
    Plan.

-   **New stakeholders.** New stakeholders become active in ITS and the
    regional ITS architecture should be updated to reflect their place
    in the regional view of ITS elements, interfaces, and information
    flows. Why might new stakeholders emerge? The stakeholders might
    represent new organizations that were not in place during the
    original development of the regional ITS architecture. Or maybe the
    geographic scope of the architecture is being expanded, bringing in
    new stakeholders. Or maybe additional transportation modes or
    transportation services are being considered that touch the systems
    of additional stakeholders.

-   **Changes in scope of services considered.** The range of services
    considered by the regional ITS architecture expands. This might
    happen because the National ITS Architecture has been expanded and
    updated to include new user services or to better define how
    existing elements satisfy the user services. A regional ITS
    architecture based on an earlier version of the National ITS
    Architecture should take into consideration these changes as the
    regional ITS architecture is updated. The National ITS Architecture
    may have expanded to include a user service that has been discussed
    in a region, but not included in the regional ITS architecture, or
    was included in only a very cursory manner. Changes in the National
    ITS Architecture are not of themselves a reason to update a regional
    ITS architecture, but a region may want to consider any new services
    in the context of their regional needs.

-   **Changes in stakeholder or element names.** An agency's name or the
    name used to describe their element(s) undergoes change.
    Transportation agencies occasionally merge, split, or just rename
    themselves. In addition element names may evolve as projects are
    defined. The regional ITS architecture should be updated to use the
    currently correct names for both stakeholders and elements.

-   **Changes in other architectures**. A regional ITS architecture
    covers not only elements and interfaces within a region, but also
    interfaces to elements in adjoining regions. Changes in the regional
    ITS architecture in one region may necessitate changes in the
    architecture in an adjoining region to maintain consistency between
    the two. Architectures may also overlap (e.g. a statewide ITS
    architecture and a regional ITS architecture for a region within the
    state) and a change in one might necessitate a change in the other.

There are several changes relating to project definition that will cause
the need for updates to the regional ITS architecture.

-   **Changes due to Project Definition or Implementation**. When
    actually defined or implemented, a project may add, subtract or
    modify elements, interfaces, or information flows from the regional
    ITS architecture. Because the regional ITS architecture is meant to
    describe the current (as well as future) regional implementation of
    ITS, it must be updated to correctly reflect how the developed
    projects integrate into the region.

-   **Changes due to Project Addition/Deletion**. Occasionally a project
    will be added or deleted through the planning process or through
    project delivery and some aspects of the regional ITS architecture
    that are associated with the project may be expanded, changed or
    removed.

-   **Changes in Project Priority**. Due to funding constraints, or
    other considerations, the planned project sequencing may change.
    Delaying a project may have a ripple effect on other projects that
    depend on it. Raising the priority for a project's implementation
    may impact other projects that are related to it.

The above reasons for possible changes in the regional ITS architecture
baseline may happen frequently or infrequently, depending upon the
region and the specifics of the original regional ITS architecture
development effort. This should be taken into account as one set of
factors in determining how often to update the regional ITS
architecture.

# Maintenance decisions

The purpose of maintaining a regional ITS architecture is to keep it
current and relevant, so that stakeholders will use it as a technical
and institutional reference when developing specific ITS project plans.
A key characteristic of a successful regional ITS architecture is
*consensus*; that is, the notion that each stakeholder has and continues
to buy-in to the architecture as the model for how ITS elements have
been deployed in a region, and more importantly how future ITS elements
should be deployed in the region.

Each of the maintenance decisions discussed in this section are
primarily in support of keeping the regional ITS architecture relevant
to the ITS planning and deployment of ITS projects as resources become
available. As conditions in a region naturally evolve, an effective
regional ITS architecture maintenance process will also evolve the
regional ITS architecture so that it "keeps up" with the evolving
conditions, and maintains the characteristic consensus that ensures
stakeholders will find it relevant and a benefit to use.

The decisions that will be discussed are:

-   **Who**: Who will lead and implement the maintenance effort?

-   **When:** On what schedule will the regional ITS architecture
    change?

-   **What:** What parts of the regional ITS architecture will be
    maintained?

## Who will maintain the Regional ITS Architecture?

Who will maintain the Regional ITS Architecture? This is perhaps one of
the most crucial maintenance decisions for a regional ITS architecture.
To maintain a consensus regional ITS architecture, to some extent *all*
stakeholders will need to participate, but typically one or two agencies
will take the lead responsibility to maintain the regional ITS
architecture.

An important concept is that the responsibility for architecture
maintenance should not be delegated to an individual person, but should
instead be assigned to an agency or institutional group in the region.

Often an individual may be, or may have been, a champion in the
development of a regional ITS architecture, and that's fine. But
maintenance is recurring, and necessarily is a long-term effort. The
responsibility may be delegated to an individual at any given time, but
the overall responsibility should be a stated role of an institution or
agency in the region. In this way the responsibility transcends the
variabilities that can impact an individual person's activities and
career. Sometimes this responsibility will be shared by agencies. This
is the case with the Inland Empire maintenance plan (see appendix B)
that provides for the maintenance responsibility to be assumed jointly
by four key agencies in the region.

**Issues in determining maintainer**

Two key considerations in selecting a maintainer are described below.

1.  Does the maintainer have the necessary skills/resources to maintain
    the regional ITS architecture?

> Maintaining a regional ITS architecture utilizes a range of skills. In
> order to properly evaluate changes to the architecture the maintainer
> must have staff that is knowledgeable of the existing regional ITS
> architecture. This implies a detailed technical understanding of the
> various parts of the architecture and how changes would affect each
> part. Also required is an understanding of transportation systems in
> the region (although this understanding can reside jointly in the
> group of agencies/ stakeholders who participate in the maintenance
> process). Finally, the maintainer agency needs to have staff with an
> understanding of the tools used to create (and to update) the
> architecture. This might include for example, knowledge of the Turbo
> Architecture tool, if that is used to hold some of the architecture
> information. The agency responsible for maintaining the architecture
> needs to have the skills within its own organization or consider
> acquiring the skills. In either case, the agency needs the necessary
> funding to support the maintenance effort.
>
> Having the resources to maintain a regional ITS architecture may mean
> that the stakeholders using the regional ITS architecture have to
> share in the costs to acquire these resources, even though one
> specific agency may commit to maintain staff or contract the skill set
> necessary.

2.  Does the maintainer have the mission and authority to maintain the
    full stakeholder and functional scope of the regional ITS
    architecture?

The agency that maintains a regional ITS architecture ideally is one
that has broad functional responsibilities across the full scope of the
regional ITS architecture. In this case, "scope" represents the
geographic area of the region, the transportation functions in the
region, and the timeframe for deployment of new ITS elements and
interfaces in the region.

A natural maintainer for many regions is the Metropolitan Planning
Organization (MPO). Very often the scope of the MPO will match (or
nearly match) the scope of the regional ITS architecture. This is the
case in the Northeastern Illinois maintenance plan\-- the responsible
agency for maintenance is the MPO in the region (CATS). This is also
true for the Oahu Regional ITS Architecture, where Oahu Metropolitan
Planning Organization will assume the maintenance responsibility. Both
of these plans can be found in Appendix B. In cases where the MPO does
not possess the resources to manage the effort, or in cases where there
is no MPO (e.g. if the region is rural in nature) alternate maintainers
might be identified. Some other possibilities for maintainer
organizations are:

-   State Department of Transportation (DOT). A State DOT might take
    responsibility for maintaining the regional ITS architecture. This
    particular approach may make the most sense in rural regions where
    the ITS functions are largely the responsibility of the state DOT.
    But it could also apply to regions that have limited resources
    available in the MPO or other local planning organization or where
    the "region" is an entire state.

-   Transportation Authorities. These entities manage transportation
    infrastructure using a business model that may be relatively
    independent of those agencies more aligned with the MPO business
    model. If a Transportation Authority is a stakeholder in a regional
    ITS architecture, then an agreement between the Authority and the
    MPO may be necessary to carry on the appropriate maintenance of
    their common regional ITS architecture.

-   Regional ITS Committees: Regions often have some institutional
    framework that make decisions about integration, ITS issues,
    operations, or procurement. Many areas in the United States address
    this issue by creating an ITS Committee, Working Group, ITS Program
    Committee, or Operations Task Force. This institutional group could
    be responsible for the architecture maintenance.

When one agency or institution takes responsibility for architecture
maintenance, they may use agreements to create a management/oversight
function (e.g. a "regional ITS architecture maintenance committee" or
"regional ITS architecture maintenance board") to oversee regional ITS
architecture maintenance work, which would have representation from the
key stakeholders to the agreement. This management/oversight function
might be given management authority over the maintenance process. In
this way, the stakeholders are investing in and controlling their own
regional ITS architecture, and they will have direct responsibility for
the quality of the product.

**What group will assist the maintainer in evaluating and approving
changes?**

Another decision that must be made is who will support the maintainer in
evaluating and approving changes to the architecture. This should be a
group of representatives of key stakeholders, ideally members from the
areas of traffic, transit, public safety, and maintenance. This group
might be a carryover from a committee or body that consisted of key
stakeholders in the development of the architecture, or it could be a
newly constituted group, or it might be a form of the Regional ITS
Committee described above. These groups have many names, but one common
trait \-- they often include both technical and managerial
representatives of the key transportation agencies in the region. As an
example, the Inland Empire maintenance plan (in Appendix B) calls out
the creation of a new group\-- the Architecture Maintenance Team\-- with
representation from key stakeholders. The Oahu Regional ITS Architecture
Report calls out an existing group--- the ad hoc ITS Technical Task
Force---to support the maintenance activity. See Appendix B for both of
these examples.

The group responsible for evaluating and approving changes to the
architecture may be a group that has some coordinating authority for
integration of systems in the region. However there is no need for the
group to have legal or contracting authority. They will be serving as a
vehicle for consensus.

## When will the architecture be updated? 

When will the architecture be updated? Another way to describe this is
what "timetable" will be used for making updates or changes to the
architecture. There is no set timetable that will apply to every region.
The timetable chosen will depend on several factors including how the
regional ITS architecture is used and the funding/ staffing available
for the task.

How often will the regional ITS architecture be modified or updated?
There are two basic approaches to update interval: periodic maintenance
and exception maintenance. Each has their advantages and disadvantages.
They are not mutually exclusive, and an approach could be developed that
is a combination of the two basic models.

-   Periodic Maintenance. This approach ties the maintenance of the
    regional ITS architecture to one of the recurring activities of the
    transportation planning process. For example, if an MPO is the lead
    maintenance agency for a region, it's natural that the regional ITS
    architecture would be updated at the same frequency as the regional
    transportation plan is updated (every three to five years) or the
    Transportation Improvement Program is updated (at least every two
    years). The update of the architecture should occur several months
    prior to the transportation planning document update, so that the
    revised architecture could serve as an input to the planning update.
    While this is convenient for the MPO, it may be a problem for the
    ITS component of federally funded transportation projects where a
    change to the regional ITS architecture is required for Final Rule
    940 project/architecture consistency. Publication and versioning
    costs are minimized for the periodic maintenance approach since
    there is a new version only once in the maintenance cycle.

-   Exception Maintenance. This approach considers and makes changes to
    the regional ITS architecture in a process that is initiated as
    needed. This is very convenient for Rule 940 consistency issues, but
    may be more costly than a periodic process (where requests for
    changes are queued until they are all addressed at once).
    Publication and versioning costs are dependent on the frequency of
    changes made to the regional ITS architecture.

-   Combined Periodic and Exception Maintenance. This approach is the
    most responsive to stakeholder needs, and perhaps the most likely to
    succeed with regard to usage of the regional ITS architecture,
    however, it implies the greatest cost. Specific stakeholder requests
    are dispatched immediately, and a more thorough process of analysis
    is periodically applied to discover and incorporate new ITS
    requirements.

Note, the above discussion relates to 'how often' the architecture is
updated. A complementary discussion regarding whether the update
involves incremental changes or is an update of the full baseline will
be provided in section 4.2.

## What will be maintained?

What aspects of the regional ITS architecture will be maintained? Those
constituent parts of a regional ITS architecture that will be maintained
are referred to as the "baseline". This section will consider the
different "parts" of the regional ITS architecture and whether they
should be a part of the baseline.

One of the benefits of a regional ITS architecture is to enable the
efficient exchange of information between ITS elements in a region and
with elements outside the region. Efficiency refers to the economical
deployment of ITS elements and their interfaces. The result of these ITS
deployments should be contributions to the safe and efficient operation
of the surface transportation network. Each of the components in the
regional ITS architecture below have a role in this economy, and
appropriate effort should be levied to maintain them.

> *Description of Region*

This description includes the geographic scope, functional scope and
architecture timeframe, and helps frame each of the following parts of a
regional ITS architecture. Geographic scope defines the ITS elements
that are "in" the region, although additional ITS elements outside the
region may be necessary to describe if they communicate ITS information
to elements inside the region. Functional scope defines which services
are included in a regional ITS architecture. Architecture timeframe is
the distance (in years) into the future that the regional ITS
architecture will consider. The description of the region is usually
contained in an architecture document, but may reside in a database
containing aspects of the regional ITS architecture, and should
certainly be a part of the baseline.

> *List of Stakeholders*

Stakeholders are key to the definition of the architecture. Within a
region they may consolidate or separate, and such changes should be
reflected in the architecture. Furthermore, stakeholders that have not
been engaged in the past might be approached through outreach to be sure
that the regional ITS architecture represents their ITS requirements as
well. The stakeholders should be described in architecture documentation
(and may also reside in a database representing aspects of the regional
ITS architecture). Their listing and description should be part of the
baseline.

> *Operational Concept*
>
> It is crucial that the operational concepts (which might be
> represented as roles and responsibilities or as customized market
> packages) in a regional ITS architecture accurately represent the
> consensus vision of how the stakeholders want their ITS to operate for
> the benefit of surface transportation users. These should be reviewed,
> and if necessary, changed to represent both what has been deployed
> (which may have been shown as "planned" in the earlier version of the
> regional ITS architecture) and so that they represent the current
> consensus view of the stakeholders. Many of the remaining maintenance
> efforts will depend on the outcome of the changes made here. The
> operational concept will reside in the architecture documentation (and
> possibly in a diagramming tool if a customized market package approach
> is used) and should be part of the baseline.
>
> *List of ITS Elements*

The inventory of ITS elements is a key aspect of the regional ITS
architecture. Changes in stakeholders as well as operational concepts
may impact the inventory of ITS elements. Furthermore, recent
implementation of ITS elements may change their individual status (e.g.
from planned to existing). The list of elements is often contained in
architecture documentation, and is key information in any architecture
database. It is a key aspect of the baseline.

> *List of Agreements*

One of the greatest values of a regional ITS architecture is to identify
where information will cross an agency boundary, which may indicate a
need for an agency agreement. An update to the list of agreements can
follow the update to the Operational Concept and/or interfaces between
elements. The list of agreements will usually be found in the
architecture documentation. This listing should be a part of the
baseline.

> *Interfaces between Elements (interconnects and information flows)*

Interfaces between elements define the "details" of the architecture.
They are the detailed description of how the various ITS systems are or
will be integrated throughout the timeframe of the architecture. These
details are usually held in an architecture database. They are a key
aspect of the architecture baseline, and one that will likely see the
greatest amount of change during the maintenance process.

> *System Functional Requirements*

High-level functions are allocated to ITS elements as part of the
regional ITS architecture. These can serve as a starting point for the
functional definition of projects that map to portions of the regional
ITS architecture. Because of the level of detail, these are usually held
in spreadsheets or databases, but may be included in the architecture
document. They are a part of the baseline.

> *Applicable ITS Standards*
>
> The selection of standards depends on the information exchange
> requirements. But in addition, the maintenance process should consider
> how ITS standards may have evolved and matured since the last update,
> and consider how any change in the "standards environment" may impact
> previous regional standards choices (especially where competing
> standards exist). For example, if XML based Center-To-Center standards
> reach a high level of maturity, reliability and cost-effectiveness,
> then a regional standards technology decision may be made to
> transition from investments in other standards technologies (e.g.
> CORBA to XML). The description of the standards environment for the
> region, as well as the details of which standards apply to the
> architecture should be part of the baseline.
>
> *Project Sequencing*
>
> While project sequencing is partly determined by functional
> dependencies (e.g. "surveillance" must be a precursor to "traffic
> management"), the reality is that for the most part project sequences
> are local policy decisions. Project sequences should be reviewed to
> make sure that they are in line with current policy decisions.
> Furthermore, policy makers should be informed of the sequences, and
> their input should be sought to make the project sequences in line
> with their expectations. This is crucial to avoiding the regional ITS
> architecture becoming irrelevant. The project sequencing should be
> included in the architecture documentation and may also be held in a
> spreadsheet or database. These should be part of the architecture
> baseline.

# Maintenance Process

This section describes the regional ITS architecture maintenance
process. The process described below is based upon the more general
discipline of Configuration Management. This section will first present
a short summary of configuration management, and then describe the
process of maintaining a regional ITS architecture, drawing connections
between the general discipline and the specific application of it for
maintaining a regional ITS architecture. The maintenance process
described in this section is a suggested or example process for the
maintenance of regional ITS architecture. The process presented can be
applied to the maintenance of any regional ITS architecture, but should
be tailored to fit the size and scope of the particular architecture.
The process should also be tailored so that it fits within the region's
transportation planning processes (e.g., the Regional Transportation
Plan update process).

## Configuration Management Overview

Configuration management is defined as: "A management process for
establishing and maintaining consistency of a product's performance,
functional, and physical attributes with its requirements, design and
operational information throughout its life"[^2] and can be applied to
the development of any system. In the context of regional ITS
architecture it is a process for establishing and maintaining
consistency of the architecture's information content throughout its
life. In general, the configuration management process consists of five
major activities:

 

-   **Configuration management planning** -- making decisions about what
    needs to be controlled within a product configuration, when you
    establish a controlled configuration, how you change a controlled
    configuration, and what amount of effort you're going to expend in
    managing configurations, with the decisions formalized in a
    *configuration management plan*. In the context of maintaining a
    regional ITS architecture this corresponds to the architecture
    maintenance plan.

-   **Configuration identification** -- identifying the *configuration
    items* and the unique identifiers that you use to keep track of all
    items that need to be independently identified, stored, tested,
    reviewed, used, changed, delivered and/or maintained. Identifying
    the configuration items and what identifiers will be used is part of
    the architecture maintenance plan.

-   **Configuration control** -- the control of which changes are made
    to the configuration baseline and when and how they are made.

-   **Configuration status accounting** -- keeping track of the state of
    all configuration items, all pending proposed changes, and all
    approved changes to configuration items

-   **Configuration audits** --verifying consistency of configuration
    documentation against the product. In the context of a regional ITS
    architecture this includes verifying that different representations
    of the architecture (e.g. document and database) match.

These activities are performed throughout the life of the development
and operation of systems. Figure 1 summarizes these process steps. There
are some additional resources that provide deeper discussion, broader
application of these principles and some specific tools and techniques
for implementation of configuration management. These may provide
additional information in adapting the information in the white paper to
specific regional needs.

-   TMC Pooled-Fund Study [Configuration Management for Transportation
    Management
    Systems](http://tmcpfs.ops.fhwa.dot.gov/cfprojects/new_detail.cfm?id=24&new=2)
    -- Final Report September 2003.

-   [A Guide to Configuration Management for Intelligent Transportation
    Systems](http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/13622.html) -
    April 2002.

Figure 1. Configuration Management Process

## Architecture Maintenance Process

The process of maintaining a regional ITS architecture involves managing
change, and can be described using the activities summarized in the
previous discussion of configuration management.

### Configuration Management Planning

Before the maintenance activity begins the parameters of the activity
must be identified and the details of the process must be determined.
These parameters, defining who will maintain the architecture, when the
architecture will be updated, and what will be the baseline maintained
have been described in Section 3. Both these decisions and the
maintenance process itself should be defined in an architecture
maintenance plan, which is the primary output of the configuration
management planning activity. The maintenance plan may be a separate
document or part of the larger regional ITS architecture document.
Appendix A provides a sample set of topics for such an architecture
maintenance plan. The plan should be created during the initial
development of the regional ITS architecture, but if it was not (as has
been the case in many architectures developed prior to the release of
the Final Rule/ Final Policy) then the process should be defined and
documented as soon as possible. The maintenance plan should be a part of
the architecture baseline described below.

**Who**

The maintenance plan should identify who will be responsible for the
maintenance effort and what group of stakeholders will review and
approve changes to the architecture baseline. In the discipline of
configuration management this group of stakeholders is termed the
configuration control board (CCB). In addition to defining who will be
involved in maintenance a description of each agencies roles and
responsibilities may be included. The Oahu Regional ITS Architecture
Report in Appendix B provides just such details on roles and
responsibilities.

**When**

The maintenance plan should also identify the timetable for regional ITS
architecture updates. As discussed in section 3.2, there are several
options for this timeline. The other timing decision that should be
identified in the maintenance plan is when to set the baseline and begin
the maintenance process. In the case of regional ITS architectures, the
first release of the architecture after its initial development would
normally constitute the initial baseline. This is the point at which the
architecture is ready for distribution and use, and the point at which
potential changes to the architecture may begin to develop.

**What**

The maintenance plan should clearly identify what will be maintained-
i.e. the architecture baseline. Section 3.3 discussed the parts of the
regional ITS architecture that should be maintained. In fact, these
parts are contained in databases (e.g. a Turbo Architecture database),
spreadsheets, drawing files (e.g. PowerPoint or Visio) and documents.
Defining the architecture baseline is defining exactly what documents,
databases, etc. will be maintained.

In addition to these architecture outputs, source documents that were
used to produce the regional ITS architecture outputs may also be
important to identify. Some of these documents will be the subject of
later revision and maintaining a consistency between the architecture
and the other efforts is important. For example, if the regional ITS
architecture inventory was derived from a number of individual
stakeholder inventory documents, then the date and version numbers of
those source documents should be considered for inclusion in your list
of controlled items. Other examples of these source documents might
include early deployment study reports, strategic deployment plans, and
inventory tracking reports. It is important that the dates of reports
and any version numbers associated with the reports are recorded as part
of the configuration that is controlled. This way, subsequent releases
of these documents would trigger an analysis to determine how the
changes are best propagated through the rest of the controlled items in
order to maintain a consistent configuration. It's also necessary to
record where these are stored -- at which agency, on which data server,
web site or other storage location.

The versions of software tools that were used to produce the
architecture might also be included in the set of configuration items.
These might include the Turbo Architecture software and the version of
the National ITS Architecture used. For these tools, the important thing
to record as part of the configuration is the version number and date of
release. Subsequent updates to the tools and databases would trigger a
change analysis.

A final consideration that goes into the definition of the architecture
baseline is how you plan to use the architecture. Will market package
diagrams be an important source of interfaces for project definition? Or
will interconnect diagrams be used? Or will project developers go
directly to the database representation for their detailed definition?
Considering some of these alternatives will help you decide which
representations of the architecture are most important to your region.

Figure 2 shows some examples of the items that might be selected for the
architecture baseline.

![](media/image2.wmf){width="6.0in" height="2.061111111111111in"}

Figure 2: Examples of Configuration Items to Consider.

The definition of baseline will depend greatly on the scope and
complexity of the regional ITS architecture effort. For small efforts
the baseline might consist of only a database, an architecture summary
document (which would include the maintenance plan) and the version of
National ITS Architecture (and possibly Turbo Architecture) used for the
development.

**Deciding How to Change the Baseline**

Change is inevitable. The goal of configuration management is not to
keep changes from occurring, but to permit changes in a controlled
fashion, ensuring that all configuration items are consistent with their
descriptions at all times. Due to the nature of a regional ITS
architecture (i.e. a set of documentation and databases rather than an
actual system of software and hardware), there are two basic approaches
that could be taken to updating the baseline. The first is *incremental
change* based upon individual change requests. The second is a *full
baseline update* based upon a periodic revisiting of the entire
architecture. In the latter case all the architecture outputs are
revisited and modified based upon stakeholder inputs, using much the
same process as was used in the original development of the
architecture.

The process of changing the baseline can be broken into the steps shown
in Figure 3. The following sections will consider each process step as
it might be applied to both approaches to architecture maintenance. The
formality or amount of effort that goes into these process steps will
depend upon the scope and complexity of the regional ITS architecture.

Figure 3: Process for Changing the Baseline

*Identify Change*

The primary aspects of change identification are:

-   Who can suggest a change?

-   How is the change request documented?

Each architecture effort will need to make a decision about who can
initiate a change request. In some areas the selected answer will be
"anyone". This approach is called out in the Inland Empire maintenance
plan in the appendix. Allowing anyone to initiate a change is conducive
to the development of a "consensus" architecture because it empowers all
stakeholders to provide inputs. However the approach does have a
drawback \-- if literally anyone can input requests the region runs the
risk of being overrun by requests that will tax scarce resources to
review and decide upon proposed changes. An alternative approach that
may be attractive to some larger regions is to limit who can make change
requests to members of the CCB or members of other key ITS committees.
This effectively means that any change suggested has the approval of a
key stakeholder. This approach is planned in the Northeastern Illinois
maintenance plan given in Appendix B. This has the added benefit of
spreading the resources needed to generate or evaluate changes among the
group.

The plan might also address when a change request should be made. For
example, the Oahu maintenance plan in Appendix B lays out detailed
directions for inclusion of ITS projects in the TIP, identifying when
changes to the regional ITS architecture need to be made in order for a
project to be funded through the TIP. Also the plan might identify the
types of changes that will be made to the architecture. The Oahu plan
identifies administrative amendments that do not require Policy
Committee approval and non-administrative amendments that do require
Policy Committee approval.

It is recommended that a simple change request form be created that
contains at least the following information:

-   Name of change

-   Description of change

-   Rationale for change

-   Originator name or agency

-   Originator contact information

-   Date of origination

A sample change request form, as well as an example of a change is
provided in Appendix A.

As part of the configuration management process this information should
be maintained in a change log (or change database) that would add the
following additional fields of information

-   Change number (some unique identifier)

-   Change disposition (accepted, rejected, deferred)

-   Change type (minor or significant)

```{=html}
<!-- -->
```
-   Part of baseline affected (could be check boxes for document,
    database, web site, and not known)

```{=html}
<!-- -->
```
-   Disposition comment

-   Disposition date

A sample change log entry is shown in Appendix A.

There are many ways the above change forms can be implemented. The form
could be on a regional architecture website for download by anyone
submitting a change. A less formal alternative would be for a change
request to be submitted as an email containing the key information
above. The formality in the process creates an audit trail of all
changes considered as well as a record of those approved, those
rejected, and those deferred. This audit trail can come in handy in
future assessments of proposed enhancements or changes to the systems.

The above description of initiating changes applies to individual change
suggestions that might arise from review of the architecture by a
stakeholder or from the impact of individual projects. In the case of a
full baseline update of the regional ITS architecture, this could be
handled by a summary change request indicating the nature of the update
and referencing the stakeholder interactions that will generate a set of
changes.

*Evaluate Change*

When using the incremental change approach to maintenance, each change
request needs to be evaluated to determine what impact it has upon the
architecture baseline. This evaluation could be required of the person
proposing the change, or it could be performed by someone else (possibly
the person, or group of people responsible for maintaining the
architecture). Since a proper evaluation of a change requires detailed
knowledge of the aspects of the regional ITS architecture baseline that
are affected: it is usually a better idea to have someone on the CCB (or
their staff) do the evaluation. If the proposal for architecture
modification has an impact on other stakeholders, someone from the CCB
should contact the stakeholders to confirm their agreement with the
modification. If the issue warrants it, a stakeholders meeting or
teleconference to discuss the modification may be held. In the case of a
full baseline update, the change evaluation happens through stakeholder
consensus as part of the overall update.

*Approve Change*

When using the incremental change approach, the changes should be
presented to the CCB along with recommendations to approve, defer, or
reject them. This could be handled informally through email, or through
periodic face-to-face meetings. The maintenance plan should identify how
change approval will occur and any procedures that will be used to make
the decisions. Should approval require unanimous consensus of all
members of the change review board? Approval of all stakeholders
affected by the change? Or just a majority of the CCB members? Which
procedure is used depends greatly on the nature of consensus building in
the region. Approval of affected stakeholders is a good approach and one
that may fit a wide range of conditions. For example, if a change to an
interconnection between the traffic management center and the transit
center is suggested, then approval by the appropriate traffic and
transit agency represents consensus on the change and should be all that
is needed for approval. Unanimous consent is not recommended as it is
the hardest to maintain (and may slow down the process considerably due
to trying to get all parties to respond, or come to meetings). In the
case of full baseline update, the approval comes from the stakeholder
inputs obtained when each architecture input is revised.

*Update Baseline*

This activity involves putting the changes into the architecture
baseline documents and databases. This requires much the same skills and
techniques used in creating the initial baseline. When using the
incremental change approach, all the changes would be entered by one or
more assigned personnel, and then checked per the process described in
the maintenance plan. When using the full baseline update, new versions
of documents and databases would be circulated to stakeholders for a
wider review. In addition, the change log would be updated to describe
the actual change made and the version identification of all
architecture baseline material would be updated as described in the
maintenance plan.

*Notify Stakeholders*

The final part of the maintenance process is to notify stakeholder of
the changes or updates to the architecture. This applies equally to
incremental change and full baseline update approaches. In order to
perform this notification, the maintaining organization should create
and keep up to date a contact list for all stakeholders represented in
the architecture. As part of the maintenance process, this contact list
should be reviewed and updated periodically to identify changes in
personnel or changes in contact information (e.g. phone numbers or email
addresses). The task of actually notifying the stakeholders of changes
may be handled in a variety of ways ranging from hard copy to e-mail to
websites. Each approach has its strengths and weaknesses, and what is
best for the region will be based on the current methods of
communicating. A suggested approach that may meet a wide range of needs
is to identify a website where information about the architecture is
available and have a place on that website to provide notification of
changes. This could be coupled with email notification to the
stakeholder list that a change has occurred and to access the
information on the website. As part of the note (as well as on the
website) it would be good to provide the new version and date of
baseline items, as well as a short summary of the changes.

**Configuration Management Resources**

What resources are needed to perform configuration management? In the
context of maintenance of a regional ITS architecture, the same
personnel skills that are used to work with the National ITS
Architecture and possibly the Turbo architecture tool will be used in
managing the configuration items that are included in the configuration
management plan. In addition to human resources, there will be the need
to have file servers, web sites, or other central locations to store
electronic copies of configuration items. These must be "read-only" and
protected so that changes are not made to released versions of the
databases and documents. Any required changes require a new version
number/date and hence a new copy of the configuration item separate from
the previous version.

### Configuration Identification

Each configuration item must have a unique identifier associated with
it. The identifier for the item should be marked on it in some fashion,
so that the item can be identified without error and tracked. In the
context of regional ITS architecture maintenance, this can be
accomplished by suffixing a version number and date in the file name for
a database file or electronic document, or it can be physically marked
on a printed document. The identifier can also be included in a header
or footer for documents and diagrams. In this way, everyone who reads
the materials or looks at the database (using Turbo Architecture, for
example) will know which version they are reviewing.

It also makes sense to have a controlled document that lists all of the
configuration items and the versions that constitute that baseline in
time. Maintenance history can also be included. Any interdependencies
between the items are worth recording. There are several reasons for
this. First, you want to be able to know what items you have under
configuration control and be able to locate them. Marking them with a
unique identifier makes it possible to do that. Second, you want to be
able to track the status of each item as it changes. Third, if a change
is made to one of your configuration items, you want to be able to
determine the impact of that change on the other items.

### Configuration Control

Configuration control refers to the process of identifying, evaluating
and approving changes (as laid out in the architecture maintenance plan)
and then updating the baseline and all associated documentation. Any
additions after the initial release/baseline will be noted with a
changed version number and date to the relevant identifiers. This must
also include an update and new version of the overall configuration item
list that documents the current versions of all configuration items.

In the case of a regional ITS architecture the baseline consists of
databases, documents, and possibly other supporting outputs such as
spreadsheets or drawing files. The process of configuration control and
of updating these can become challenging since there is likely to be
more than a single representation of the same information. For example,
if a database contains the architecture inventory and an architecture
document contains a table that lists this inventory- these two
representations of the same information need to be kept in sync.
Eliminating this kind of duplication is not really an option because a
database representation of the architecture is needed to manage to large
number of elements and connections, but some form of documentation is
also required to make the information more understandable and usable for
the stakeholders. The solution is to be aware of the duplication and to
put in place a plan to manage it. Because of the potential for changes
affecting multiple parts of the baseline, the changes in each part of
the baseline should be coordinated with updates in other parts of the
baseline. This is particularly true when using the incremental change
approach to architecture maintenance.

In the incremental change approach, it is also possible to allow the
database version of the information to change more frequently than the
documentation. This might be appropriate if the form of the information
used most often by stakeholders is the database (e.g. in the mapping of
regional ITS architecture to projects). This could be handled by notes
in the configuration item list.

### Configuration Status Accounting

Configuration status accounting is the process of ensuring that all of
the relevant information about an item -- documentation and change
history -- is up to date and as detailed as necessary. This includes the
status of all pending changes. A primary goal of configuration status
accounting is to disseminate configuration item information necessary to
support existing and future change control efforts. A typical
configuration status accounting system involves establishing and
maintaining documentation for the entire life cycle of an item. Status
accounting is ideally carried out in conjunction with change control.

The primary benefit of configuration status accounting is that it
provides a methodology for updating all relevant documentation to ensure
that the most current configuration is reflected in the configuration
identification database. It accounts for the current status of all
proposed and approved changes. The goal of configuration status
accounting is to provide decision makers with the most up-to-date
information possible. Having the most recent information about a change
item or including how the changes were implemented helps to reduce
research efforts in future change control activities whether
implementing a new change or rolling back a change that had a negative
or ![](media/image3.wmf){width="4.4in" height="3.25in"}unexpected
impact. To report status, a format similar to that shown in Figure 4
might be used

Figure 4. Sample Configuration Identification Document.

#### 

For a small regional ITS architecture, the only configuration items
might be a document and a Turbo database. This would mean that
configuration status accounting amounts to reporting on the version of
the two configuration items (e.g. ruralRegArchV1-6-3-03.tbo and
ruralRegionarchV1-7-3-03.doc are the latest versions of the "rural
region ITS architecture"). Reporting this status could be done by phone
call, letter, email or fax to interested stakeholders just to let them
know that these files are still the latest. When using the incremental
change approach, the other thing typically reported during status
accounting would be the list of pending changes to the regional ITS
architecture, and for a small region there may not be very many changes
typically encountered and these may be very infrequent. So, in addition
to identifying the latest version of the architecture, the region might
report that there have been 2 changes received from stakeholder A and B
that these haven't been implemented yet but are expected to be worked on
in the next 6 months. When using a full baseline update approach pending
changes are collected but probably not reported until summarized in the
change log that occurs when the full baseline is updated.

### Configuration Audits

In the general discipline of configuration management, configuration
verification and audit is the process of analyzing configuration items
and their respective documentation to ensure that the documentation
reflects the current situation. In the case of a regional ITS
architecture the configuration items *are* the documentation. Hence this
step in the process becomes a rather simple one that can look at two
aspects of the architecture:

-   Verifying the correctness of the configuration status accounting
    report.

-   Verifying that different representations of the architecture
    information (e.g. the database and document) are in sync.

This type of audit is most applicable when using the incremental change
approach (which may result in many small updates to configuration items,
but is also a good idea to perform at the end of the effort in the full
baseline update.

## Effort required for maintenance

How much effort must be expended to maintain a regional ITS
architecture? That is dependent on several factors:

-   How much is the architecture being used? The more it is used to
    support planning and project development activities, the greater the
    level of changes it will probably see.

-   What is the approach being used for architecture maintenance? Is it
    incremental changes or full baseline update?

-   What is the maintenance update cycle? Are changes being incorporated
    on a regular basis or is revision of the architecture happening once
    every planning cycle?

-   What is the size and complexity of the architecture? The larger the
    architecture the greater the effort in maintaining it.

To identify the effort required consider several maintenance scenarios:

1.  The maintaining organization collects change requests and reviews
    them with the CCB on a periodic (e.g. quarterly) basis.

How many changes are collected in each period is very dependent on use
of the architecture (how much is it being looked at while stakeholders
are using it) as well as the complexity of the architecture (how many
elements or connections could be changed). Creating a change request
should be a small time investment for any submitter (e.g. under an hour
of time). There is a small time investment of the maintaining
organization to log the changes. Periodically, changes would be
evaluated and presented to the CCB. Evaluating each change will take
only a small time investment (e.g. under an hour). The CCB meeting of a
couple hours will dispose of the changes. The amount of effort required
to update the baseline will be a function of the scope of the change
(e.g. adding a new stakeholder, inventory items and connections will
take longer than changing the status of a few information flows). Again,
the amount of effort for the activities described above is dependent on
the number of changes being considered.

2.  The maintaining organization collects change requests and holds them
    until an update occurs X years after the initial architecture is
    completed.

> This scenario is very similar to the previous one (in terms of time
> required for each change). The primary difference would be the number
> of changes to be incorporated. Again the amount of effort will be
> highly dependent on such things as the level of ITS investment in the
> region. One way to limit the amount of effort required in the
> evaluation and approval part of the process is to have maintainer
> staff produce a summary of changes and recommended outcomes (approve,
> defer, or reject). This will allow the CCB to focus on only those
> changes requiring significant stakeholder consensus when it meets.

3.  At the update cycle stakeholders are brought back together for one
    or more workshops to review and update the architecture.

This is the full baseline update approach. In this approach to
maintenance, additional time will be spent getting some subset of the
stakeholders together in one or more workshops to review the
architecture. A series of changes will naturally flow from these
meetings that can be incorporated en masse into the architecture. The
level of effort required for these meetings will be dependent on how
many meetings are planned and how much effort will be required to
present the architecture to the stakeholders.

So how much will it cost? We all have to answer to the realities of
budgeting and planning which forces us all to the bottom line. The cost
of maintaining a regional ITS architecture depends on how you are going
to use it. As you can see from the discussion above the cost of paying
someone to update the database and documents may be trivial compared to
the cost of all of the stakeholders time reviewing and approving
changes. Think about the scenarios above and decide what maintenance
approach your region will likely follow. Based on that decision you can
then decide whether to allocate some financial resources to your future
budgets to cover the cost of maintenance - personnel, equipment,
contractors, etc.

### 

# Conclusions

This white paper, written as a guide for transportation professionals
who are involved in the development, use and maintenance of regional ITS
architectures, has drawn the following conclusions about maintenance of
regional ITS architectures:

-   Change to a regional ITS architecture is inevitable. The many
    reasons for this were elaborated in section 2.

-   In recognition of the need to update the architecture, the
    Architecture and Standards Final Rule/ Final Policy has, as one of
    its requirements, that all regions developing a regional ITS
    architecture "shall develop and implement procedures and
    responsibilities for maintaining it".

-   An architecture maintenance plan should be developed that lays out
    these responsibilities and procedures, which will be tailored to
    each region's special needs.

-   The discipline of configuration management as discussed in this
    paper provides a foundation for the maintenance process.

Appendix A: Sample Change Management Forms and Maintenance Plan Outline

The following are examples of change request form and change log entries
indicating the type of information one might expect to find in these
forms

![This figure presents a sample change request form (filled out with a
request). There are two parts to the form. The top part is filled out by
the change originator. The bottom part is filled out by the maintaining
organization.](media/image4.wmf){width="6.305511811023622in"
height="5.490944881889764in"}**Sample Change Request Form**

**Sample Change Log Entry**

  ---------------------------------------------------------------------------------------------------------------------
  **Change     **Change        **Change       **Change        **Disposition   **Baseline   **Change     **Disposition
  \#**         Description**   Originator**   Disposition**   Date**          Affected**   Type**       Comment**
  ------------ --------------- -------------- --------------- --------------- ------------ ------------ ---------------
  Some unique  This could be a  Copy of name  Field with set   Date of         List of     Categorize    A field for
  identifier   copy of the     from above     of choices such Disposition     baseline     change-      comments
  such as      suggested                      as Accept,                      documents/   might use    regarding the
  2004.01 to   change above,                  Reject, Defer.                  outputs that minor/       change or its
  indicate the or might be an                 Filled in once                  will be      major, or    disposition.
  first change expanded                       the CCB has                     affected by  something    
  cataloged in description.                   decided on the                  change. This similar.     
  2004)        This field                     change                          could be a                
               might also                                                     set of                    
               point to a                                                     columns- one              
               white paper                                                    for each                  
               that details                                                   part of                   
               the change.                                                    baseline                  
                                                                              with check                
                                                                              boxes.                    

  ---------------------------------------------------------------------------------------------------------------------

**Architecture Maintenance Plan Outline**

The following provides an example outline for an architecture
maintenance plan that follows the guidance given in this white paper.
The exact form and content of each region's plan should be tailored to
meet the needs and resources of the region.

1.  Introduction

2.  Roles and Responsibilities (for maintaining the architecture)

3.  Timetable

4.  Architecture Baseline

5.  Change management process

    -   Identifying changes

    -   Evaluating changes

    -   Approving changes

    -   Updating baseline

    -   Notifying stakeholders

**Appendix B: Real-World Examples**

The following provides several real world examples of architecture
maintenance plans- the first is for Inland Empire California, the second
for Northeastern Illinois, and the third is for Oahu, Hawaii. They are
all fairly recent, so no actual change activity has been performed, but
each group of stakeholders has indicated their intent to use the
maintenance plans for updates to their respective regional ITS
architectures. In the case of Northeastern Illinois, the maintenance
plan has been formally approved by the MPO's Policy Committee.

**Inland Empire, California**

The following is the maintenance plan developed as part of the Inland
Empire ITS Architecture in June 2003.

**8.2 Architecture Maintenance**

The Inland Empire Area regional ITS architecture should be modified as
plans and priorities change, ITS projects are implemented, and the ITS
needs and services evolve in the region. The Inland Empire Area ITS
Architecture was developed with a ten-year time horizon. As the
architecture is updated, it will be extended further into the future.
The goal of maintaining the architecture is to keep an up-to-date
regional ITS architecture that is accessible and easily used for
deploying ITS in the Inland Empire area.

The key aspects of the maintenance process, which are defined in this
section are:

> • Who is responsible for architecture maintenance?
>
> • What has to be maintained?
>
> • When will the architecture be updated (how often)?
>
> • What is the process by which architecture will be modified/changed?

*8.2.1 Who is responsible for Architecture Maintenance?*

Just as a group of Stakeholders were key to the development of the
Inland Empire Area Architecture, it is imperative that Stakeholders stay
involved in the on-going maintenance. Once regional architecture has
been completed and approved by all participating agencies, an Inland
Empire Architecture Maintenance Team should be developed that has at
least one representative from SANBAG, RCTC, SCAG, Caltrans Traffic
Operations and Caltrans Transportation Planning, as appropriate (a mix
of planning and operations personnel could serve on this Team). This
Maintenance Team should make modification decisions together with each
of the four agencies (SANBAG, RCTC, SCAG and Caltrans) having one vote
in regional decisions for modifying the architecture. In order to ensure
that the architecture stays up-to-date, the first action of this Team
should be to determine which agency (SANBAG, RCTC, SCAG, or Caltrans)
will take formal responsibility for making physical changes toward
maintaining the architecture. This leadership role could also rotate on
an annual basis for an equal share of responsibility and accountability
or, if agreed upon, one agency can take responsibility for the formal
database maintenance.

*8.2.2 What has to be maintained?*

There are several different parts and reports that make up the Inland
Empire Regional Architecture. Some require more frequent updates than
others, but the entire document will need a periodic review for
consistency with regional vision and goals. The current version of
Regional ITS Architecture will be established as the baseline
Architecture and maintenance time frames identified in this Chapter will
begin upon completion.

The Inland Empire Area regional ITS architecture is stored in Microsoft
Access databases and is represented through a set of outputs including
reports and diagrams. The most significant portions of the architecture
will be maintained through updates in the electronic database using
TurboArchitecture™. Additionally, the Inland Empire area regional ITS
architecture contains several other documents that should be updated at
regular intervals:

> • Project Sequencing Report as needed
>
> • Operational Concept as needed
>
> • Functional Requirements as needed
>
> • List of Agency Agreements as needed

To aid the Inland Empire in architecture version document control, the
filename of the database should contain the date on which the
architecture was updated. This will allow the current version to be
easily identified.

The following information should be maintained in the TurboArchitecture™
databases:

> • Description of the Region
>
> • List of Stakeholders, including key contact information
>
> • Inventory of existing and planned ITS systems in the region
>
> • Documented regional needs and ITS services associated with
> supporting systems in the region (Market Packages)
>
> • Existing and planned interconnects and information flows for the
> region.

Outputs such as interconnect and architecture flow diagrams, inventory
lists, Stakeholders lists and other diagrams and reports can be produced
by a member of the Maintenance Team from TurboArchitecture™ outputs, so
they are by-products of the architecture database. These outputs can be
updated as necessary for meetings or outreach activities.

*8.2.3 When will the Architecture be updated (how often)?*

Depending upon the outcome of the SCAG Regional Architecture efforts,
the Turbo Architecture™ databases from each of the subregions could
become an appendix to the RTP and, as the RTP undergoes a formal update
once every three years, the architecture could undergo any major
modifications at that time. This will be a natural result of the
architecture being stream lined into the regional planning process to
ensure that the Architecture continues to accurately represent the
region. The operational concept, system functional requirements, project
sequencing list, and the list of agency agreements represent high-level
views of the Inland Empire Area architecture and do not necessarily need
to be modified each time a revision is made to the architecture.
However, these documents will be modified as the architecture is
broadened to address new needs and services or on an *as needed* basis.

*8.2.4 What is the process by which the Architecture will be
modified/changed?*

Because changes can arise from many sources, and very likely will arise
from some sources outside the technical expertise of a single agency, it
is a good idea for a group of people from different Stakeholder areas to
be involved in maintenance of the architecture. Representatives from
traffic, transit, emergency management, and other key Stakeholders from
the team that developed the architecture should provide input to the
Maintenance Team for review. Each county has a Technical Advisory
Committee (TAC), comprised of the City and County staff, as well as
other ITS Stakeholders. These monthly meetings are an ideal place to
remind agencies of the architecture, and for the TACs to be a point of
contact to discuss ITS architecture updates and processes. Getting input
from the Stakeholders guarantees that the architecture continues to
reflect the desires of the Stakeholders in the region.

To allow Stakeholders to use the architecture for their planning and
deployment activities, the current architecture database should be
available from the Inland Empire Maintenance Team. For easy access,
other regional Stakeholders should be notified by e-mail when the
architecture database and all other current documentation has an exact
location or website from which to be accessed.

In addition to maintaining the architecture, this maintenance plan
should be reviewed periodically for required changes. This maintenance
plan was developed during the initial development of the Inland Empire
Area Regional ITS Architecture. Use of the architecture and
modifications to it may differ from what was anticipated. Revising the
plan will ensure that the goal of architecture maintenance is realized.

**8.3 The Change Management Process**

The change management process is the procedure for modifying the
Architecture. It specifies how changes are identified, how often they
will be made, and how the changes will be defined, reviewed, implemented
and released.

8*.3.1 How Changes Are Identified*

The Inland Empire Area regional ITS architecture was created as a
consensus view of what ITS systems the Stakeholders in the region have
currently implemented and what systems they plan to implement in the
future. The architecture will need to be updated to reflect changes
resulting from project implementation or resulting from the planning
process itself. There are many actions that may cause a need to update
the architecture.

• Changes for Project Definition. When actually defined, a project may
add, subtract or modify elements, interfaces, or information flows of
the regional ITS architecture. Because the architecture is meant to
describe not only ITS planned for the region, but also the current ITS
implementations, it should be updated to correctly reflect the deployed
projects.

• Multiple Agency Stakeholders. There are several generic Stakeholders
in the Inland Empire

Area architecture. These generic Stakeholders group multiple
Stakeholders from the region.

For example, small municipal transit agencies are all identified under
one regional ITS element identified as \"Small Municipal Transit
Agencies\". As Stakeholders can be better identified that are covered by
these generic Stakeholders terms, the descriptions of these Stakeholders
will be added to the Architecture. As their respective elements plan and
deploy ITS systems, they should be added as separate elements and
Stakeholders in the architecture.

• Changes for Project Addition/Deletion. Occasionally a project will be
added, deleted or modified during the planning process. When this
occurs, the aspects of the regional ITS architecture associated with the
project have to be added, deleted or modified.

• Changes in Project Status. As projects are deployed, the status of the
architecture elements, services and flows that are part of the project
will have to be changed from planned to existing. Elements, services and
flows will be considered to exist when they are substantially complete
in that they have been turned on, tested and are currently being used.

• Changes in Project Priority. Due to funding constraints, technological
changes or other considerations, a project planned of the region may be
delayed or accelerated. Such changes will need to be reflected in the
Inland Empire Area ITS Architecture.

• Changes in Regional Needs. Over time the needs in a region can change
and the corresponding aspects of the regional ITS architecture will have
to be updated. While the

Inland Empire Area ITS Architecture was developed with input from
several Stakeholders in the region, not all Stakeholders could or wanted
to participate. As ITS deployment increases and benefits of integration
are realized, additional Stakeholders will become interested in

ITS, the architecture should be updated to reflect their place in the
regional view of ITS. The systems they operate and their interfaces will
have to be added or revised.

Additionally, the National ITS Architecture itself is a living resource
of information and in order to keep a life of at least 20 years into the
future, it is expanded and updated from time to time to include new user
services or refine existing services. In recent years the National ITS
Architecture users asked that maintenance and construction activities be
included in the architecture and with national security issues that have
arisen since September 11, 2001, in order to address homeland security
in transportation systems new security and emergency management entities
are being added. How these changes in the national \"template\" effect
the Inland Empire Area regional ITS architecture should be considered as
the Regional Architecture is updated. The National ITS Architecture may
have expanded to include a user service that has been discussed in a
region, but not been included in the regional ITS architecture, or been
included in only a limited manner.

*8.3.2 How Often Changes Are Made?*

A comprehensive architecture update will be completed every three years,
concurrent with the update of the RTP. The comprehensive update would
include involving new Stakeholders, reviewing services planned for the
area, and other items, as appropriate.

Minor revisions, such as changes in the status of an information
(architecture) flow between Stakeholders, can be made as the information
is known or even on an annual basis. Minor changes can be made by
members of the Maintenance Team with consensus among themselves.

In future updates of the Regional Architecture for the Inland Empire
Regional ITS Architecture it is recommended that the Architecture
Maintenance Team consider documenting traceability between needs to
market packages, operational concepts, functional requirements and
projects.

8.3.3 Change Definition, Review, Implementation, and Release

Any Stakeholders in the Inland Empire region can propose a change to the
regional architecture. Stakeholders should inform the Inland Empire
Maintenance Team of the status of any projects with ITS aspects. To
properly maintain the architecture, Inland Empire Maintenance Team
should be informed not only of when projects are planned; but also when
projects are completed or when changes made during design or
construction impact the regional architecture.

Stakeholders should propose changes in writing to the Inland Empire
Maintenance Team. Proposals should clearly define the architecture
aspects to be added, deleted or revised. The reasons for proposed
modifications should be given. Each proposal should include contact
information for the person proposing the change so he or she can be
contacted if questions arise.

Each proposed modification will be reviewed and considered by the Inland
Empire Maintenance Team who at the same time, will consider timing
issues as they relate to the RTP and RTIP approval update process. If
the proposal for architecture modification has an impact on other
Stakeholders, someone from the Team will contact the Stakeholders to
confirm their agreement with the modification. If the issue warrants it,
a Stakeholders meeting to discuss the modification may be held. If
consensus in favor of the modification is reached, the Maintenance Team
member who is identified as the \"keeper of the databases\" should make
the revision in the architecture database.

Once the regional architecture has been modified, the Stakeholders in
the region should be notified. The Inland Empire Maintenance Team should
maintain a list of Stakeholders and their contact information. The
Stakeholders should be notified of architecture updates and informed on
how to obtain the latest version of the architecture.

**Northeastern Illinois**

The following maintenance plan was approved by the CATS Policy Committee
in June 2003 and incorporates part of the documentation of the
Northeastern Illinois Regional ITS Architecture from December 2002.

Northeastern Illinois Regional ITS Architecture Maintenance Plan

The Need for a Maintenance Plan

The Northeastern Illinois Regional ITS Architecture is not a static set
of outputs. It must change as plans change, as ITS projects are
implemented, and as the ITS needs and services evolve in the region.

This architecture maintenance plan for northeastern Illinois supplements
the Regional ITS Architecture. The maintenance plan defines:

-   Who will maintain the architecture

-   What will be maintained (specific documents and databases)

-   How it will be maintained (i.e. what configuration control process
    will be used)

The regional ITS architecture is created as a consensus view of what ITS
systems the region\'s stakeholders have implemented and what systems
they plan to implement in the future. The regional architecture will
need to be updated to reflect various changes:

-   [Changes in Project Definition]{.underline} - When actually defined,
    a project may add, subtract or modify elements, interfaces, or
    information flows from the regional ITS architecture. Because the
    regional ITS architecture is meant to describe the current (as well
    as future) regional implementation of ITS, it must be updated to
    correctly reflect how the developed projects integrate into the
    region.

-   [Changes for Project Addition/Deletion]{.underline} - Occasionally a
    project will be added or deleted through the planning process and
    some aspects of the regional ITS architecture that are associated
    with the project may be expanded, changed or removed.

-   [Changes in Project Priority]{.underline} - Due to funding
    constraints, or other considerations, the planned project sequencing
    may change. Delaying a project may have a ripple effect on other
    projects that depend on it. Raising the priority for a project's
    implementation may impact the priority of other projects that are
    dependent upon it.

-   [Changes in Regional Needs]{.underline} - Transportation planning is
    done to address regional needs. Over time these needs can change and
    the corresponding aspects of the regional ITS architecture that
    addresses these needs may need to be updated.

-   [Changes due to New Stakeholders]{.underline} - New stakeholders may
    come to the table and the regional ITS architecture should be
    updated to reflect their place in the regional view of ITS elements,
    interfaces, and information flows.

-   [Changes to reflect National ITS Architecture
    Revisions]{.underline} - The National ITS Architecture may be
    expanded and updated from time to time to include new user services
    or better define how existing elements satisfy the user services.
    These changes should also be considered as the regional ITS
    architecture is updated. For instance, the National ITS Architecture
    may have expanded to include a user service that has been discussed
    in a region, but not been included in the regional ITS architecture,
    or been included in only a cursory manner.

**The Maintenance Plan Process**

***Who will be responsible for updating the regional architecture?***

Responsibility for maintenance of the Northeastern Illinois Regional ITS
Architecture will lie with the Chicago Area Transportation Study (CATS).
As the Metropolitan Planning Organization, the CATS Policy Committee
provides a forum for regional stakeholders to develop and maintain the
regional architecture. In addition, CATS has organized committees and
task forces to address components of the regional transportation system.
The Advanced Technology Task Force (ATTF) is charged with such an
oversight role with respect to ITS.

####### How will potential changes to the architecture be identified?

Implementers will self-certify that their projects are consistent with
the regional architecture or will request changes in the architecture to
maintain consistency. Any ITS project or project with ITS components
must be submitted to CATS. Only member organizations of the CATS Policy
Committee will be allowed to recommend potential changes to the regional
architecture. A simple change request form will be used to document the
request and it will be added to a change database maintained by CATS
staff.

***Who decides if a change to the regional architecture is necessary?***

CATS staff, in coordination with the agency proposing the change, will
assess what impact the proposed change has upon the current regional
architecture. This assessment will then be passed on to the ATTF, which
will serve as a Change Control Group responsible for reviewing and
approving changes to the current architecture. A subgroup of the ATTF
may be selected to perform technical reviews for the Change Control
Group.

***How are the changes formally approved?***

The list of recommended changes developed by the ATTF will be submitted
first to the CATS Work Program Committee and then to the CATS Policy
Committee for approval. Only after acceptance by the Policy Committee
are the recommended changes formally approved.

***Who will implement the changes to the regional architecture?***

CATS staff will update the regional ITS architecture using the list of
changes approved by the Policy Committee.

####### When will the regional architecture be updated?

Updates of the regional architecture will be coordinated with updates of
the Regional Transportation Plan on a three-year cycle.

***Maintenance Process Summary***

Details of the architecture maintenance process, including the
configuration control documentation, are under Section 12 of the
[Northeastern Illinois Regional ITS Architecture
Documentation]{.underline}. The maintenance plan for the regional
architecture can be summarized using the following steps:

1.  Requests for changes to the regional ITS architecture are received.

2.  Change requests are reviewed by the ATTF and a list of recommended
    changes is developed.

3.  The list of recommended changes must be formally approved by the
    CATS Work Program Committee and then by the Policy Committee.

4.  CATS staff will update the regional ITS architecture using the
    approved list of changes.

*Excerpt from Section 12 of the Northeastern Illinois Regional ITS
Architecture Documentation that describes the baseline and the
configuration control process.*

***12.2 Architecture Baseline***

Establishing an architecture baseline requires clear identification of
the architecture products that will be maintained, including specific
format and version information. For the Northeastern Illinois Regional
ITS Architecture the following outputs are recommended as the
architecture baseline:

-   Architecture Document (this document)

-   Turbo Architecture Database

-   Regional ITS Architecture Web pages

Regarding the Architecture document, it is recommended that the source
document, in Microsoft Word format, be held by CATS, while a PDF version
of the document be created for general distribution. Also that a version
number and date be included inside the cover page.

Regarding the Turbo Architecture Database, it is recommended that CATS
maintain a zipped version of the final delivered Northeastern Illinois
Regional ITS Architecture database. The name, date, and size of the
database file inside the zipped file should be entered into an
architecture log as version 1.0 of the architecture.

Regarding the web site, a CD-ROM version of the final web site should be
maintained by CATS. It is further recommended that the version number of
the architecture be entered somewhere on the home page of the web site
so that the version being viewed is immediately identifiable.

***12.3 Configuration Control***

Once the baseline is defined, the process for making changes to this
baseline must be established. The change management process specifies
how changes are identified, how often they will be made, and how the
changes will be reviewed, implemented, and released.

####### How Changes are Identified

This involves two issues-

-   who can identify a change to the architecture and

-   how will the change request be documented.

For a region as large as Northeastern Illinois, the question of who can
make change requests is an important one. If literally anyone can input
requests the region runs the risk of being overrun by requests that will
tax scarce resources to review and decide upon. On the other end of the
spectrum, if too much formality or paperwork are added to the process
then many valid or needed changes may go unexpressed. The recommendation
is that only members of the ATTF be allowed to identify potential
changes. This effectively means that any change suggested has the
approval of a member of the task force. This has the added benefit of
spreading the resources needed to generate or evaluate changes among the
group.

As to how the change request should be documented---it is recommended
that a simple change request form be created that contains at least the
following information

-   Name of change

-   Description of change

-   Part of baseline affected (could be check boxes for document,
    database, web site, and not known)

-   Rationale for change

-   Originator name or agency

-   Date of origination

This information will ultimately be added to a change database
(recommended to be maintained by CATS personnel) that will add the
following additional fields of information

-   Change number (some unique identifier)

-   Change disposition (accepted, rejected, deferred)

-   Change type (minor or significant)

-   Disposition comment

-   Disposition date

####### How often Changes are Made

It is recommended that the first update to the architecture baseline be
made approximately a year after completion of the initial version.
Depending upon the amount of change requests submitted, this could be
anything from a minor update to correct errors found to a more
significant update to include changes in stakeholders, elements, and
connections. Also some changes could be deferred until the next major
update of the architecture. It is recommended that a major review and
update of the architecture (including possibly additional stakeholder
meetings) be performed in the 6 months prior to the update of the
Regional Transportation Plan. This will allow an updated version of the
architecture to be used as the basis for the RTP update. Additional
minor revisions of the baseline could be considered on a yearly basis.

####### Change Review, Implementation, and Release. 

The general steps in the change review process are:

1.  Define changes per the recommendations given above.

2.  Assess the impact of the change. Someone needs to evaluate the
    change and determine what impact it has upon the architecture
    baseline. There are three options for who performs this evaluation

    a.  the person proposing the change (i.e. the member of the ATTF
        that brings it forward)

    b.  a staff member of CATS (the agency responsible for architecture
        maintenance) or

    c.  a contractor through some architecture support contract.

> Each of these options has positive and negative implications. The
> first option will work well for minor changes (e.g. changes in status,
> connections, or descriptions). However, it does require each
> submitting person to have sufficient knowledge of the architecture to
> suggest appropriate solutions. The second option requires the
> architecture knowledge to be available through CATS personnel. Their
> long-term availability to perform the work is a possible risk. The
> third implies contracting for the necessary expertise, so has the
> negative of additional cost associated with it.

3.  Provide a recommendation to the Change Control Group. For proper
    change control some group should be assigned responsibility for
    reviewing and approving changes to the baseline. The recommendation
    is that a subgroup of the ATTF be appointed for this purpose. This
    Change Control Group (sometimes referred to as a Configuration
    Control Board) should be lead by the individual responsible for
    maintaining the architecture (or by one of the individuals if it is
    a group activity). The job of the Group is to decide what changes go
    into the architecture baseline. This could be done through periodic
    meetings (say quarterly), through electronic correspondence, or a
    combination of both. A recommendation is that minor changes be
    handled through monthly email distribution and approval, while major
    changes or areas of disagreement be handled at the periodic face to
    face meetings. It is important to maintain the consensus nature of
    the architecture by having a group of core stakeholders agree on
    changes.

4.  The Change Control Group makes a decision. Either it accepts the
    change, rejects it, or asks for additional evaluation.

5.  The decision is implemented. If the decision is to accept the
    change, then the appropriate portions of the architecture baseline
    are updated (per the schedule discussed above) and an updated
    architecture baseline is defined.

The time required to perform this configuration control process will be
a direct function of the number of changes suggested to the
architecture, which will be driven by how much the architecture is being
used. It is suggested that the process be reviewed within the first year
and fine-tuned to most appropriately address the level of change that
has occurred.

Oahu Regional ITS Architecture

The following are excerpts from the Oahu Regional ITS Architecture
Procedures and Responsibilities Report, dated October 2003. Chapters 2,
3, 4, and parts of 6 are included below.

2 Policy on ITS Architecture Maintenance

Part (f) of 23 CFR 940.9 states that "the agencies and other
stakeholders participating in the development of the regional ITS
architecture shall develop and implement procedures and responsibilities
for maintaining it, as needs evolve within the region." In conjunction
with this, the *Oahu Regional ITS Architecture* includes a policy
statement as part of its Integration Strategy to meet this regulation.
Policy A.5 states, "The region will establish a method for maintaining
the ITS Architecture to ensure that eligibility for Federal
transportation funding is maintained."

This policy does not dictate the ITS architecture maintenance procedure,
but supports the region in the development of a maintenance approach.
Maintenance of the architecture includes:

-   Assessing proposed ITS projects against the ITS architecture to
    determine if they are consistent and to determine if changes should
    be made to the architectures to reflect architecture flows proposed
    in the projects.

-   Periodically updating the regional ITS architecture to ensure that
    the *Oahu Regional ITS Architecture* does not become obsolete. The
    number of years between updates depends on several factors-
    including the rate at which ITS is deployed, the number and types of
    changes made to the National ITS Architecture and standards, changed
    circumstances that result in new needs that may be met using ITS,
    and the rate of change of ITS technologies and systems available in
    the marketplace.

Most regions identify a group that would convene, when required, to
perform/ oversee the two activities noted above. Fortunately, the OMPO
Policy Committee has already established an *Organizational Structure
for Addressing ITS Policy Issues* (see Appendix A) in which it
identifies an ad hoc ITS Task Force to deal with technical ITS issues.
(The role of this task force is described in Section 4 of this
document).

Key activities, as described in the Integration Strategy, that are
suggested in this policy include:

1.  All partner agencies need to identify candidates for the ad hoc ITS
    Task Force that will focus on Architecture Maintenance. The Task
    Force will need to determine which agency will be the leader of the
    group, or if leadership will rotate among key partner agencies. The
    leader will be responsible for convening the larger group when
    necessary.

2.  Partner agencies need to identify funding sources that can be used
    to fund regional ITS architecture maintenance activities, if funding
    is required.

3\. OMPO ITS Organizational Structure

The maintenance of the ORITSA architecture utilizes the existing
structure as established and as stated in the *Organizational Structure
for Addressing ITS Policy Issues*. (See Appendix A for a complete copy
of the document.) Each of the functions for the respective committees
listed is described along with their areas of responsibility.

1.  Policy Committee

Function: To serve as ITS policy decision-maker

Areas of Responsibility:

a.  Prioritize Oahu's ITS projects under the 3-C planning process,
    regardless of funding source

b.  Endorse the federal funding of Oahu's ITS projects

c.  Endorse general city-state coordination, agreements, or other
    interests

d.  Promote legislation to assist in the development and implementation
    of a fully integrated and coordinated ITS system.

    1.  Technical Advisory Committee

> Function: To serve as a technical resource to the Policy Committee
>
> Areas of Responsibility:

a.  Identify potential policy issues to Policy Committee

b.  Make recommendations to Policy Committee on ITS policy issues

c.  Make technical (non-policy) ITS decision in areas impacting city and
    state jurisdictions

d.  Document ITS planning activities in the Overall Work Program (OWP)

e.  Provide resources to inform Citizen Advisory Committee (CAC) of
    policy issues when public input is needed

    1.  ITS Technical Task Force

> Composition:

a.  Technical Advisory Committee (TAC) agency representatives

b.  Ad hoc members as required by the agenda

c.  FHWA representative

> Function: To serve as the ITS technical expert arm of the TAC
>
> Areas of Responsibility:

a.  Be a forum for agencies to discuss and report progress on ITS
    activities

b.  Identify potential policy issues to TAC for Policy Committee action

c.  Resolve technical issues regarding implementation

d.  Identify technical issues not resolved by the ITS Technical Task
    Force which must be forwarded up to TAC for TAC action

e.  Develop pros, cons, and recommendations for TAC

    1.  Citizen Advisory Committee

> Function: to provide public input to the Policy Committee
>
> Areas of Responsibility:
>
> a\. Chair to determine whether public input, through the CAC, will be
> sought
>
> b\. Make recommendations to Policy Committee when public input is
> sought

2.  OMPO Staff

> Functions: To coordinate and promote discussions on potential policy
> issues within the OMPO process; and to advise the Policy Committee
>
> Areas of Responsibility

a.  Participate in the ITS Technical Task Force, TAC, and CAC

b.  Identify potential policy issues

4 ad hoc ITS Task Force

4.1 Membership

Because the ITS Technical Task Force allows for ad hoc members, this
will be the venue utilized for the maintenance of the Oahu Regional ITS
Architecture. The standing task force members will be from the following
OMPO participating agencies.

-   Department of Transportation Services (DTS)

-   Department of Transportation (DOT)

-   Department of Planning and Permitting (DPP)

-   Department of Business, Economic Development and Tourism (DBEDT)

-   FHWA

As needed, members from the following agencies will be invited to
participate on the Task Force:

-   Department of Design and Construction (DCC)

-   Department of Information Technology (DIT)

-   Federal Motor Carrier Safety Administration (FMCSA)

-   FTA

-   Honolulu Emergency Services Department (HESD)

-   Honolulu Fire Department (HFD)

-   Honolulu Police Department (HPD)

-   Oahu Civil Defense Agency (OCDA)

-   Etc.

See Appendix C of this document for contact information

2.  Role of the ad hoc ITS Technical Task Force

With respect to maintaining the *Oahu Regional ITS Architecture*, the
role of the ad hoc ITS Technical Task Force will be to:

-   Assess proposed ITS projects against the ITS architecture to
    determine if they are consistent, and to determine if changes should
    be made to the architecture to reflect architecture flows proposed
    in the projects.

-   Assess the regional ITS architecture to ensure that the *Oahu
    Regional ITS Architecture* does not become obsolete and to recommend
    changes to update the *Oahu Regional ITS Architecture*.

Meetings of the ad hoc ITS Technical Task Force will be convened, at a
minimum, annually, and with the development of each Transportation
Improvement Program (TIP). In addition, if ITS projects are added
through amendments to the TIP, each non-administrative amendment of the
TIP will also trigger a meeting of the ad hoc ITS Technical Task Force.

2.  Role of OMPO Staff

OMPO shall initially assume chairmanship of the ad hoc ITS Technical
Task Force. Under its chairmanship, OMPO shall be responsible for
convening meetings as needed. OMPO shall maintain the *Oahu Regional ITS
Architecture* and will be responsible for the maintenance of the master
copy of the Turbo Architecture. (Refer to Appendix D for a description
of Turbo Architecture) Updates of any changes to the *Oahu Regional ITS
Architecture* will be provided to the ad hoc ITS Technical Task Force.

3.  Role of Agencies

Agencies that are making modifications to the *Oahu Regional ITS
Architecture* will be responsible for coordinating with OMPO to convene
meetings of the ad hoc ITS Technical Task Force and providing the group
with appropriate information of the proposed changes. They will also be
responsible for determining the agencies that will be participating on
the ad hoc ITS Technical Task Force. Changes that are agreed to by the
ad hoc ITS Technical Task Force shall be documented by the proposing
agency through a technical memorandum and in Turbo Architecture. City
and State agencies are the only entities that can make a change to the
*Oahu Regional ITS Architecture;* private organizations will need to
work with a sponsoring agency in an effort to make a change to the *Oahu
Regional ITS Architecture.*

4.  Turbo Architecture

Agencies that require Turbo Architecture can obtain a copy of the
software through OMPO. OMPO will program the request as part of its OWP.
See Appendix D for a description of Turbo Architecture, as obtained from
the National ITS Architecture website.

6 Modifying the Architecture

This section describes detailed procedures for ITS projects that are
found in the TIP and TIP amendments. Administrative and
non-administrative amendments to the *Oahu Regional ITS Architecture*
are described.

1.  ITS Projects Proposed for Programming in the TIP

At the time when projects are being considered for inclusion in the TIP,
the ad hoc ITS Technical Task Force shall meet to determine which
projects can be considered TIS projects. Of those projects, the ad hoc
ITS Task Force shall then determine, by the approach outlined in Figure
1, whether they are consistent with the *Oahu Regional ITS
Architecture.*

1.  Is the project included in or consistent with the Oahu Regional ITS
    Architecture?

If the project is determined by the ad hoc ITS Technical Task Force to
already be included in or consistent with the *Oahu Regional ITS
Architecture,* then the project will be considered for inclusion into
the TIP. If the project is found to be inconsistent with the *Oahu
Regional ITS Architecture,* then the next question will be answered.

2.  Does the project require communications links or data sharing
    between two or more agencies?

If the projects is an ITS project and communication links or data
sharing occurs within the proposing agency only (not between two or more
agencies), then the project will be considered for inclusion into the
TIP. However, if the projects requires communication links or data
sharing between two or more agencies, then the project is defined, by
default, as a regional project and will need to go through the process
to determine whether the projects should be included in the *Oahu
Regional ITS Architecture.*

3.  Will the *Oahu Regional ITS* Architecture be amended prior to its
    start or as part of the project scope of work?

If, as part of the projects scope of work, the *Oahu Regional ITS
Architecture* will be amended, then the project will be considered for
inclusion into the TIP. If there are no plans to amend the *Oahu
Regional ITS Architecture* as part of the project scope of work or as
part of the project, then the project is not eligible for inclusion in
the TIP.

As part of the project scope of work, the following procedures are to be
followed:

1.  The proposing agency will work with the ad hoc ITS Technical Task
    Force to determine how the *Oahu Regional ITS Architecture* should
    be amended.

2.  The proposing agency will make a presentation to the TAC, and then
    to the Policy Committee, that details the amendment, including the
    following information:

-   Market package(s) to be added to the *Oahu Regional ITS
    Architecture;*

-   Agencies that will be part of the market package; and

-   List of anticipated communication and data exchanges that will
    transpire between agencies.

Figure 1: ITS Projects and the draft TIP --

Determining Consistency with the Oahu Regional ITS Architecture

![This figure presents a flow chart used to determine consistency with
the Oahu Regional ITS Architecture. The logic presented in the figure is
described in sections 6.1.1 through 6.1.3.
](media/image5.wmf){width="6.511023622047244in"
height="7.248425196850394in"}

1.  Documentation

The agency proposing change will prepare a short report on behalf of the
ad hoc ITS Technical Task Force, that lists the ITS projects that are
eligible for inclusion in the TIP. This report will be submitted to the
OMPO staff member responsible for the TIP. An example of this report can
be found in Appendix B.

6.2 Amending the Oahu Regional ITS Architecture

There are two types of amendments that can be made to the *Oahu Regional
ITS Architecture:* administrative and non-administrative.

1.  Administrative Amendments

Administrative amendments do not require Policy Committee action and can
be done by agency staff and the ad hoc ITS Technical Task Force. These
amendments will amend the communication and data exchanges in the market
packages of the *Oahu Regional ITS Architecture.* As of April 2003,
there were six market packages in the *Oahu Regional ITS Architecture.*
These are:

-   ITS Virtual Data Warehouse (AD3) [^3]

-   Broadcast Traveler Information (ATIS1)

-   Regional Traffic Control (ATMS07)

-   Incident Management (ATMS08)

-   Emergency Response (EM1)

-   Emergency Routing (EM2)

    1.  Role of Agency and Task Force

Agency staff, as appropriate, will evaluate each proposed ITS projects
to determine if the projects is consistent with the *Oahu Regional ITS
Architecture.* For example, if DTS is proposing an ITS project, then DTS
will be responsible for determining if the project is consistent with
the *Oahu Regional ITS Architecture.*

The project will be considered consistent with the *Oahu Regional ITS
Architecture* if it is part of one of the six market packages listed in
Section 6.2.1. The proposing agency will work with the ad hoc ITS
Technical Task Force to document the communications and data exchanges
between agencies.

If the agency finds the project to be consistent, and the communications
flows are documented as "existing", then no action by the agency staff
is required.

If the project is consistent, and the communication flows are documented
as "planned", then agency staff shall prepare a technical memorandum to
inform OMPO that the *Oahu Regional ITS Architecture* needs to be
updated. Documentation of these exchanges will be provided by the
proposing agency in two forms:

1.  Technical memorandum that details each of the added or changed
    communication and data exchanges; and

2.  Updated Turbo Architecture file.

    1.  Role of OMPO Staff

OMPO staff shall notify its participating agencies and appropriate ad
hoc ITS Technical Task Force agency representatives, and incorporate
agency changes to the *Oahu Regional ITS Architecture* and in the Turbo
Architecture master file.

If a consultant is being retained to assist the agency in the
development of the project, this shall be included as one of the talks
and deliverables as specified in the contract.

1.  Non-Administrative Amendments

Non-administrative amendments require Policy Committee action. If the
project is not part of one of the six market packages previously listed,
an amendment to the *Oahu Regional ITS Architecture* will be required.

1.  Role of Agency and Task Force

If the ITS project is inconsistent with the *Oahu Regional ITS
Architecture,* the proposing agency will coordinate with the chair of
the ad hoc ITS Technical Task Force to convene a meeting of the ad hoc
ITS Technical Task Force to propose an amendment to the *Oahu Regional
ITS Architecture.* The agency that is proposing the amendment will
identify, in writing, the other City and State agencies that should be
invited to participate in the ad hoc ITS Technical Task Force meeting.
Note that the agencies involved will be dependent on the type of project
that is being proposed.

The proposing agency will work with the ad hoc ITS Technical Task Force
to determine how the *Oahu Regional ITS Architecture* should be amended.
When the decision has been made, the proposing agency will make a
presentation to the Technical Advisory Committee that details the
amendment, including the following information:

-   Market package(s) to be added to the *Oahu Regional ITS
    Architecture;*

```{=html}
<!-- -->
```
-   Agencies that will be part of the market package; and

-   List of anticipated communication and data exchanges that will
    transpire between agencies.

    1.  Role of the TAC

The TAC will be asked to recommend that the Policy Committee endorse the
proposed amendment to the *Oahu Regional ITS Architecture*. If the TAC
does not make such a recommendation, the project will be forwarded to
the Policy Committee with the TAC's reasons fro not recommending the
Policy Committee endorse the proposed amendment noted. The proposing
agency, at that time, can decide how it would like to proceed (e.g.,
leave proposal as is; amend proposal; fund project with local money;
etc.)

If the TAC does recommend that the Policy Committee endorse the
amendment, it may make suggestions for the agency to modify the
proposal. The proposing agency will work with the ad hoc ITS Technical
Task Force to incorporate these modifications before making a
presentation to the Policy Committee.

2.  Role of the Policy Committee

The Policy Committee will be asked to endorse the proposed amendment. If
it does not endorse the amendment, the project is not eligible for
federal funds through the TIP process. If the Policy Committee does
endorse the amendment, the project can be considered for inclusion in
the TIP.

3.  Role of Proposing Agency

The proposing agency will work with the ad hoc ITS Technical Task Force
to document the communication and data exchanges between agencies.
Documentation of these exchanges will be provided by the proposing
agency in two forms:

1.  Technical memorandum that details each of the added or changed
    communication and data exchanges; and

2.  Updated Turbo Architecture file.

    1.  Role of OMPO Staff

Upon receipt of the documentation of changes and the updated Turbo
Architecture file, OMPO staff will incorporate them into the *Oahu
Regional ITS Architecture* and maintain the master files.

Figure 2 outlines the process for amending the *Oahu Regional ITS
Architecture.*

> ![This figure presents a flow chart of actions to be taken in amending
> the Oahu Regional ITS Architecture. The text of section 6.2 provides a
> description of the steps shown in the
> figure.](media/image6.wmf){width="6.5in"
> height="7.822047244094488in"}Figure 2: Amending the Oahu Regional ITS
> Architecture

[^1]: FHWA Final Rule on Intelligent Transportation System Architecture
    and Standards; January 29, 2001.

[^2]: ANSI/EIA 649-1998, *National Consensus Standard for Configuration
    Management*

[^3]: ^1^ The letters/number designation refer to the designation the
    market package has in the National Architecture