Search Operations:

Regional ITS Architecture Maintenance White Paper

January 31, 2004
Technical Report Documentation Page Information

1. Report No.:
FHWA-HOP-04-004

2. Government Accession No.:

3. Recipient's Catalog No.:

4. Title and Subtitle:
Regional ITS Architecture Maintenance White Paper

5. Report Date:
January 31, 2004

6. Performing Organization Code:

7. Author(s):
National ITS Architecture Team

8. Performing Organization Report No.:

9. Performing Organization Name and Address:
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

10. Work Unit No.:

11. Contract or Grant No.:
DTFH61-01-C-00023

12. Sponsoring Agency Name and Address:

13. Type of Report and Period Covered:
White paper

14. Sponsoring Agency Code:

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:
ITS, Architecture, Maintenance, Configuration Management.

18. Distribution Statement:
No restrictions. This document is available to the public from the sponsoring agency.

19. Security Classification (of this report):
Unclassified

20. Security Classification (of this page):
Unclassified

21. No. of Pages:
42

22. Price:

Table of Contents

1 Introduction

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

3 Maintenance decisions

3.1 Who will maintain the Regional ITS Architecture?

3.2 When will the architecture be updated?

3.3 What will be maintained?

4 Maintenance Process

4.1 Configuration Management Overview

4.2 Architecture Maintenance Process

4.2.1 Configuration Management Planning

4.2.2 Configuration Identification

4.2.3 Configuration Control

4.2.4 Configuration Status Accounting

4.2.5 Configuration Audits

4.3 Effort required for maintenance

5 Conclusions

Regional ITS Architecture Maintenance White Paper

1 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 (PDF, 5.4MB). 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.

2 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.

3 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?

3.1 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.

3.2 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.

3.3 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.

4 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).

4.1 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 - Final Report September 2003.
• A Guide to Configuration Management for Intelligent Transportation Systems - April 2002.

Figure 1. Configuration Management Process

4.2 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.

4.2.1 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.

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)
• Part of baseline affected (could be check boxes for document, database, web site, and not known)
• 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.

4.2.2 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.

4.2.3 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.

4.2.4 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 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.

4.2.5 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.

4.3 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.

5 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

Sample Change Request Form

Sample Change Log Entry

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

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 TurboArchitectureT. 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 TurboArchitectureT 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 TurboArchitectureT 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 ArchitectureT 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 - 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 - 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 - 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 - 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 - 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 - 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. 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
   1. the person proposing the change (i.e. the member of the ATTF that brings it forward)
   2. a staff member of CATS (the agency responsible for architecture maintenance) or
   3. 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.

3.1 Policy Committee

Function: To serve as ITS policy decision-maker

Areas of Responsibility:

1. Prioritize Oahu's ITS projects under the 3-C planning process, regardless of funding source
2. Endorse the federal funding of Oahu's ITS projects
3. Endorse general city-state coordination, agreements, or other interests
4. Promote legislation to assist in the development and implementation of a fully integrated and coordinated ITS system.

3.2 Technical Advisory Committee

Function: To serve as a technical resource to the Policy Committee

Areas of Responsibility:

1. Identify potential policy issues to Policy Committee
2. Make recommendations to Policy Committee on ITS policy issues
3. Make technical (non-policy) ITS decision in areas impacting city and state jurisdictions
4. Document ITS planning activities in the Overall Work Program (OWP)
5. Provide resources to inform Citizen Advisory Committee (CAC) of policy issues when public input is needed

3.3 ITS Technical Task Force

Composition:

1. Technical Advisory Committee (TAC) agency representatives
2. Ad hoc members as required by the agenda
3. FHWA representative

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

Areas of Responsibility:

1. Be a forum for agencies to discuss and report progress on ITS activities
2. Identify potential policy issues to TAC for Policy Committee action
3. Resolve technical issues regarding implementation
4. Identify technical issues not resolved by the ITS Technical Task Force which must be forwarded up to TAC for TAC action
5. Develop pros, cons, and recommendations for TAC

3.4 Citizen Advisory Committee

Function: to provide public input to the Policy Committee

Areas of Responsibility:

1. Chair to determine whether public input, through the CAC, will be sought
2. Make recommendations to Policy Committee when public input is sought

3.5 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

1. a. Participate in the ITS Technical Task Force, TAC, and CAC
2. 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

4.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.

4.3 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.

4.4 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.5 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.

6.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.

6.1.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.

6.1.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.

6.1.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

6.1.4 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.

6.2.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)

6.2.1.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.

6.2.1.2 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.

6.2.2 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.

6.2.2.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;
• Agencies that will be part of the market package; and
• List of anticipated communication and data exchanges that will transpire between agencies.

6.2.2.2 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.

6.2.2.3  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.

6.2.2.4  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.

6.2.2.5 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.

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] The letters/number designation refer to the designation the market package has in the National Architecture

You will need the Adobe Acrobat Reader to view the PDFs on this page.