Using Your Regional ITS Architecture Peer Exchange Workshop

Topic

    Executive Summary
1. Background and Introduction
2. Linking the RA and the Transportation Planning Process
3. Using the RA for Project Development
4. RA Maintenance
5. Concluding Remarks

Appendices

A. Peer Exchange Workshop Invitation and Agenda
B. Peer Exchange Workshop Region Descriptions

Executive Summary

This paper presents the findings of the "Using Your Regional ITS Architecture (RA) Peer Exchange Workshop" held in December 2004, Kansas City, MO.

The Federal Highway Administration, 23 CFR Parts 655 and 940 Intelligent Transportation System Architecture and Standards Final Rule, and Federal Transit Administration National ITS Architecture Policy on Transit Projects (Final Rule) states that after April 8, 2005, a Regional ITS Architecture must be in place for regions to use Highway Trust Fund monies, including the Mass Transit Account, for new ITS projects. In addition, ITS projects using Highway Trust Fund monies must be developed following a systems engineering analysis.

There are several good reasons to integrate the adopted RA, and its development and maintenance into the transportation planning process. The RA provides a useful source of information to the planning process through the ITS inventory, stakeholders and planned ITS projects. The RA supports the planning process mainly through increased stakeholder participation in the Long Range Transportation Plan (LRTP) development and through better system and inter-jurisdictional integration.

Adopting the RA will provide the most value for harnessing the relationships developed and information gathered during the RA development process. The RA can be adopted in many ways. The RA can be formally approved or endorsed by the MPO board, by a stakeholder group or informally through good relationships.

The RA development process has helped to get relevant stakeholders from a variety of modes involved in the ITS planning process. This stakeholder involvement is the key to developing regional ITS systems that are integrated and meet the larger transportation goals of the region. The RA provides a structured mechanism for stakeholder involvement. Besides face-to-face forums such as stakeholder meetings, the RA can be posted on the internet for information sharing and for gathering RA update information.

One intent of the Final Rule is to require the use of a systems engineering process when developing ITS projects. The RA saves time and provides value by creating a baseline for ITS projects that use a systems engineering process. Some of the initial work may have already been done in developing the RA. A starting point thus exists for project development.

Stakeholders can take several measures to help make sure that ITS projects are consistent with their RA, and that the RA is useful for project development. These measures include updating State DOT project development manuals to reflect ITS, RA and systems engineering; placing greater emphasis on training for systems engineering and RA use; documenting RA and systems engineering benefits; and dedicating project resources for systems engineering analysis.

The development and implementation of RA maintenance procedures are requirements of the Final Rule. As ITS projects are implemented, the RA will need to be updated to reflect new ITS priorities and reflect strategies that emerge through the transportation planning process. This includes accounting for expansion in ITS scope, and allowing for the evolution and incorporation of new ideas. The region should follow an established maintenance process for updating the RA. Currently, the regions that attended the workshop are maintaining their RA in-house. It is important to have a well defined maintenance plan and a thorough configuration management process to ensure that all aspects of RA maintenance and updates are covered. As RAs mature and maintenance needs increase, consultants may be considered. Regions should plan to dedicate resources for RA maintenance as funding and resources for RA maintenance is expected to be an issue in the future. Keeping the right stakeholders involved in the ongoing maintenance process is very important. The foundational relationships between ITS stakeholders often established during the development of the RA need to be continued in order to keep the RA relevant and useful as an ITS planning and implementation framework.

1. Background and Introduction

The Federal Highway Administration, 23 CFR Parts 655 and 940 Intelligent Transportation System Architecture and Standards Final Rule, and Federal Transit Administration National ITS Architecture Policy on Transit Projects (Final Rule) was adopted in April 2001. This Final Rule states that after April 8, 2005 a Regional ITS Architecture must be in place for regions to use Highway Trust Fund monies, including the Mass Transit Account, for new ITS projects. This Regional ITS Architecture must include:

• Description of the region
• Identification of participating agencies and stakeholders
• An operational concept that identifies roles & responsibilities of stakeholders
• List of agreements required for operations
• System functional requirements (high-level)
• Interface requirements and information exchanges with systems and subsystems
• Identification of ITS standards supporting regional and national interoperability
• Sequence of projects required for implementation
• Maintenance procedures for the Regional ITS Architecture

In addition, the Final Rule states that all ITS projects that use Highway Trust Fund monies shall be developed using a systems engineering analysis. This systems engineering analysis shall include:

• Identification of portions of the Regional ITS Architecture being implemented
• Identification of participating agencies with roles and responsibilities
• Definition of requirements
• Analysis of alternatives
• Identification of procurement options
• Identification of standards and testing procedures
• Identification of resources for operations and maintenance

Pursuant to this Final Rule, many regions have developed a Regional ITS Architecture. These regions have a wealth of knowledge and experience in developing, using and maintaining their RA which is valuable to regions that are not as far along.

This paper documents the results of a workshop whose purpose was to harness the knowledge, experience and lessons learned of selected regions in using their RA in the planning process, integrating the RA with systems engineering for project development, and maintaining their RA. This workshop was conducted on 7-8 December 2004, in Kansas City, MO. The “Using Your Regional ITS Architecture Peer Exchange Workshop” included 24 attendees from 8 regions from across the country. The participant mix from each participating region at the minimum included an RA champion, an MPO representative and a Federal Highway Administration Division Office representative. In addition, FHWA staff from Headquarters and the Resource Center were present to facilitate the workshop. The regions were invited on the basis of: the amount of experience, maturity of the architectures, diversity in type of architecture, and ability to participate. The invitation letter and workshop agenda are provided in Appendix A. Descriptions of the 8 regions and their RAs can be found in Appendix B.

The discussion during the workshop fell under these categories:

1. Linking the RA and the Transportation Planning Process
2. Using the RA for Project Development
3. Maintaining the RA

Each discussion category is presented in a separate section within this document. Each category section includes: an introduction, a summary of major findings; and a discussion overview. The Introduction part of the section for each category lays out the context. This introductory part is gathered from existing documents and some insights from practitioners. It generally describes the issue being discussed and provides some high level advice. The Major Findings follows the introduction and lists the major points that came across at the workshop. These major findings were gathered from the workshop’s interactive discussions. These were then presented to the attendees at the end of the workshop for concurrence. The Discussion Overview part of each section presents the compilation of the main interactive discussion during the workshop. The discussion overview is organized by major topics that were raised during the workshop. It elaborates on the major findings when necessary and also covers other areas of the discussion that are not represented in the major findings. A short section of concluding remarks follows the discussion on Maintaining the RA.

2. Linking the RA and the Transportation Planning Process

2.1 Introduction

This section identifies ways to better link the RA with the transportation planning process and presents some benefits and issues about how the current process is evolving. There are several good reasons to integrate and adopt the RA and its development and ongoing maintenance into the transportation planning process. The RA development uncovers collaboration opportunities, communications issues and institutional issues. RA development has benefits that go forward into adoption and maintenance. The RA provides a useful source of information to the planning process through the ITS inventory, stakeholders and planned ITS projects contained in it. Connecting the RA development and maintenance process to the planning process assists in developing integrated goals and objectives, improves communications between the stakeholders, and helps support and justify ITS projects for Federal funding (inclusion in Unified Work Plan and TIP) and provides a framework for unified decision making.

The RA should relate to other planning documents, particularly the long-range or regional transportation plan. The RA supports the planning process through increased stakeholder participation in the long-range plan development and through better system and inter-jurisdictional integration. The RA can directly support the selection of projects for the TIP. The RA can also serve as the basis for an ITS strategic plan and play a role in the development of corridor plans.

The RA development and maintenance process provides an accessible way for transportation planners to become more familiar with integrated management and operations. The RA serves as a focal point for coordination and collaboration between planning and operations practitioners. It can also help to engage operations managers in regional planning including deciding transportation funding priorities.

The connection between the RA development and maintenance process and the transportation planning process can be initiated by identifying how the RA incorporates regional goals and objectives. Reviewing the goals, objectives, and strategies in transportation plans will reveal the opportunities for coordination with the RA. Creating appropriate mechanisms to better link the RA with planning documents is essential for best utilizing the RA and linking the RA to planning.

Stakeholder adoption of the RA is important. Adopting the RA will provide the most value for harnessing the relationships developed and information gathered during the RA development process. The RA development process can highlight for planners the importance of integrating ITS technology with management and operations considerations into regional plans. The stakeholders can adopt their RA in many ways. The RA can be approved or endorsed by the MPO board, by a stakeholder group or informally through good relationships. As an example, RA documentation exerpts and references may be included in the adopted Long Range Transportation Plan (LRTP). An adopted RA can be used by agencies as a guide for ITS-related decisionmaking. A completed and adopted RA provides the greatest benefit if agencies use it as a framework for decisionmaking and to improve communications.

USDOT has several resources available on linking RA and the transportation planning process (http://www.ops.fhwa.dot.gov/its_arch_imp/guidance.htm)

A section on the relationship between the RA and the transportation planning process can be found on pages 117-125 of the guidance document entitled Developing, Using, and Maintaining an ITS Architecture for Your Region ( http://ntl.bts.gov/lib/jpodocs/repts_te/13598.pdf).

In the FHWA publication Getting More by Working Together: Opportunities for Linking Planning and Operations, the Regional ITS Architecture is identified in as important vehicle for creating better linkages between the transportation planning and operations functions (http://www.ops.fhwa.dot.gov/publications/lpo_ref_guide/index.htm).

The link between transportation planning and the RA occurs mainly through increased stakeholder participation in the Long Range Transportation Plan (LRTP) development and through better system and inter-jurisdictional integration. The RA can be adopted in the LRTP and can be accepted when accepting the LRTP. The adopted RA provides documentation for ITS projects and can directly support the selection of projects for the Transportation Improvement Program (TIP). The RA can also serve as the basis for an ITS Strategic Deployment Plan and play a role in the development of other regional management plans.

2.2 Major Findings

• The RA development process fosters involvement of operators/project developers in the larger transportation planning process.
• The RA process has helped to get relevant stakeholders from a variety of modes involved in the ITS planning process.
• Posting the RA on the Internet is proving to be useful for information sharing, gathering updates, and making changes to both the RA and other transportation plans.
• The RA is useful for transportation planning in that it provides a complete inventory of ITS project elements, a description of how projects are integrated, and stakeholder agreement on project deployment needs.
• Having a LRTP that reflects RA needs promotes a unified regional ITS vision and satisfies both the RA and LRTP Federal requirements.
• Some regions use their ITS Deployment Plan as a vehicle for including RA project needs in the transportation planning process.
• Different regions have their own way of approving their RA and considering it ready for use.
• Integrating the RA project sequencing list with the TIP project list can help reduce redundancy and aid funding decisions. Having a joint TIP and RA projects list helps to make deployment more efficient by eliminating the occurrence of projects that have the same purpose and functionality.
  

2.3 Discussion Overview

Stakeholder Involvement

The RA provides a resource for identifying relevant stakeholders to be included in the transportation planning process and fosters focused communication among stakeholders to bring greater value to the process. The RA helps facilitate the major planning goal of developing a consensus and getting different stakeholders to work cooperatively by providing a common ground. The RA also helps provide tangible support from multimodal and non-traditional groups and sets the stage to get these stakeholders together to discuss common projects. It is increasingly important to involve engineers and operators in the RA and related transportation planning functions since they use the RA to define ITS at the project level.

Based on the workshop findings, there are three levels of regional stakeholder involvement in the RA process: regions that have integrated new stakeholders into standing planning committees, regions that involve relevant stakeholders in ad hoc committees on an as needed basis, and regions that have found it challenging to maintain stakeholder support in the planning process. Some of the reasons for stakeholder involvement or non-involvement were cited as follows:

• Funding Opportunities: Many stakeholders participate in RA activities because that is how they get their funding for projects. In the near term, having projects and associated funding encourages greater involvement.
• Project Need: Participation by some groups (commercial vehicle operators, chamber of commerce, emergency and safety agencies) is not strong because it is not always clear how they will benefit from the involvement. To encourage participation, it is important to explain from their point of view what ITS and RA can do. Speaking their language helps and it is important to be sensitive to how they perceive and understand information. It is important to understand their issues and to take the initiative and go to them rather than have them come to you. One-on-one discussions seem to work well to encourage participation.
• Fostering Involvement: Some public constituents such as environmental groups fear that ITS may encourage people to drive more. One region suggested using transit as an example to explain that ITS has environmental benefits. This region’s environmental group will support ITS as long as they see it as a way to promote transit services.

RA and Transportation Planning Integration

Prior to the RA development requirements, planners and others whose primary role was non-ITS did not have an easy mechanism to be involved in the various aspects of ITS planning and decision making. They were often involved in ITS on an ad-hoc basis, based on varying levels of exposure to ITS decision making, or based on regional relationships. The RA development and maintenance process has provided a mechanism to planners and others to ensure that all different perspectives are covered and issues are not overlooked. As a result of this involvement, planners are developing new ways to integrate ITS projects into the existing transportation planning process and the RA has provided a framework for facilitating this exchange.

The RA provides important background information for overall transportation planning. It provides an ITS project inventory, a high level description of ITS project functionality and shows how the various systems interconnect. The RA additionally provides a framework for identifying which projects to implement and when to implement them. This framework can assist planners to prioritize projects, address transportation system performance, and have better control of the process. The RA is useful for anticipating issues and future developments so that stakeholders can avoid redundancy and implement integrated systems. The RA development and maintenance process helps planners engage the right stakeholders. It is important not to implement stovepiped ITS systems that do not communicate with other systems.

Based on the workshop feedback, some regions use the RA directly in the planning process and others use it to support existing practices. Several regions are using the RA to support development and refinement of their ITS Strategic Deployment Plan, which outlines regional ITS goals. The ITS Strategic Deployment Plan is then used to support the Long Range Transportation Plan (LRTP). Planners use ITS Strategic Deployment Plans to translate the more technical aspects of the RA into a high level format that is better understood by regional decision makers. Planners are finding that it is easier to convey ITS project plans when technical information is reduced to a minimum.

The RA has helped some regions embed ITS into the TIP. When TIP projects come to the MPO board, the RA provides the supporting information to help the MPO board understand the rationale and benefits of the ITS elements. The RA also provides some direction for incorporating projects into the LRTP. One region used the RA directly to communicate ITS project needs to other committees and localities. They found that the connection of the RA to the TIP and LRTP is through direct discussion of ITS projects.

Another region looked at the TIP to see where ITS fits in and how it is funded. They created categories to classify ITS projects and asked the TIP committee if they could include these categories in the TIP list. The TIP committee realized that they could use the RA as a resource to assist in the development of a prioritized project list that is ultimately included in the TIP. This is important because it helped to eliminate funding competition presented by some ITS projects and provided them with one unified list of regional project priorities.

Some regions find that their TIP and ITS Strategic Deployment Plan project list is more useful than the RA project sequencing list. The RA project sequencing list is not as well accepted by their TIP committees as is the TIP and list of ITS Strategic Deployment Plan projects.

Other findings show that some regions are using the RA ITS project inventory to identify opportunities for their congestion mitigation strategy development. Regions are also finding the RA useful to develop their regional communications infrastructure plans and corridor management plans.

One familiar complaint about ITS is that rushing to implement ITS for the sake of having ITS may not allow a region to realize the full potential of the technology. This is especially true if no planning considerations were made. However, to understand the potential of ITS technologies it is important to get planners involved in the ITS project development process. This aids planners in understanding how ITS can help achieve larger regional goals.

Funding Source

Regions often implement ITS projects that are not federally funded. Some regions shared concerns about involving these non-federally funded projects in the RA. If a federally funded project is not consistent with the RA, the RA needs to be updated to include it through the regional maintenance procedures. It was noted that regions should be aware that their FHWA Division Office representatives will be asking them specific questions about project consistency with the RA.

Formal RA Adoption

Different regions have their own way of approving their RA and considering it ready for use. The following methods were identified by workshop participants:

• One region promoted the RA through their State ITS chapter and the MPO general assembly approved it. Their RA has been mainstreamed into the LRTP. They approved it the same as they would approve any major planning document. Approvals were done as part of the LRTP. They now have an updated version in which there are no significant changes. They will seek a new approval in their next update when they expect to have significant changes.
• One smaller region took their RA to their policy committee for approval. They chose a 10 year time horizon because they felt it would better accommodate the evolution of technology.
• One region approved their updated RA version as part of the transportation management plan. They posted it on the Internet so stakeholders would have easy access and accepted comments over a period of one month.
• One region’s RA was endorsed by the transportation policy board. They used focus groups and telephone interviews to get RA feedback. A committee was formed just for the RA development phase. The committee does not meet on an ongoing basis and it was only formed for the RA development phase. They consider it a challenge to track down the original participants in order to update the RA.
• In some regions a less formal approval process is enabled by good communications between the RA maintainer and stakeholders who manage ITS projects.

3. Using the RA for Project Development

3.1 Introduction

This section presents the experience of regions in ITS project development and how the RA can help.

One intent of the Final Rule is to encourage the use of a systems engineering process when developing ITS projects. The RA provides input to the systems engineering process used for project development.

The desired outcome of any ITS project is a successful system at the end of the project, with success measured by how well the system satisfies the requirements of the people who use it. A goal-oriented ITS project manager wants to use any tools or techniques that help achieve success. Systems engineering provides those tools and techniques. Using systems engineering helps:

• Accurately identify and evaluate alternatives
• Manage project uncertainty and risk
• Manage program management issues

One of the objectives of systems engineering is to provide significantly greater value to the project for a smaller value investment. Systems engineering is not intended to add burden to the project or to diminish value through cost increase. Just like in RA development, the systems engineering effort should be commensurate with the scope of the ITS project, i.e. the more complex a project, the more complex the analysis.

The RA saves time and provides value by creating a baseline for ITS projects that use a systems engineering process. Some of the initial project work may already have been done in developing the RA. The RA provides a starting point in the development of the concept of operations, in requirements definition and in the design phase of the systems engineering process. The RA can assist with:

• Confirming needs as identified by the regional stakeholders
• Lending support for justification of funding requests
• Providing a baseline for requirements definition
• Identifying key players for system implementation
• Identifying existing system inventories
• Defining system interfaces and information flows
• Providing information on institutional and technical agreements related to the ITS project
• Identifying potential ITS standards

3.2 Major Findings

• The RA development process allows operators/project developers to understand how a project fits in the deployment vision for a region/state.
• Having an identified RA coordinator in the project review process helps ensure that ITS and/or enabling technologies are considered in capital projects.
• State DOT project development manuals need to be updated to reflect ITS, RA and systems engineering.
• State IT departments can be engaged as partners/stakeholders in project development and deployment as they can be a useful resource.
• State and local ITS champions would welcome FHWA assistance in getting the RA and systems engineering message out to other stakeholders.
• Training is key to widespread acceptance and use of the RA and systems engineering.
• Setting aside project money for training can help minimize project risk.
• RA and systems engineering benefits need to be documented and shared.
• For projects where no federal funds are used, the use of the RA and a systems engineering analysis is not required. Methods need to be found for these projects to encourage RA and systems engineering use such that deployment consistency is achieved.

3.3 Discussion Overview

RA, Systems Engineering and Project Development

Most regions agreed that at the minimum, people have heard of and have some awareness of the RA. The level of understanding of the RA and how it may be used for project development varies. The RA operational concept is a useful starting point to develop the project concept of operations. Some regions try to make sure that they incorporate some of the aspects of the RA like operational concept into project documentation. The ITS inventory gathered in the RA helps to identify issues and spark discussion about where the major links need to be. The ITS inventory in the RA needs to be accurate and thorough. The RA should be accurate and meet the intent of the final rule in order to be useful as a starting point for project development.

One State mentioned that beyond technical understanding, there is a significant business practice issue involved in using the RA for project development. They have hired a systems engineering consultant to look at State DOT-wide business practices. This effort will also include looking at merging the Plans, Specifications, and Estimate (PS&E) and systems engineering processes. It was generally agreed that this approach would be helpful. DOT project development manuals need to include RA and systems engineering to clarify to practitioners how project development, RA and systems engineering relate. Workshop participants asked that FHWA promote the revision of these manuals. One State has state-level procedures in place for incorporating RA with projects. Workshop attendees from this State mentioned that it is yet to be seen how these procedures will be carried out with the local jurisdictions.

All regions agreed that the systems engineering process needs to be better understood. More outreach and training is required for promoting use of the systems engineering process. All regions agreed that it would be very useful to have the benefits of the RA and the systems engineering process available to them. This will help justify the project investment required up front for systems engineering analysis. There is a need to document and compare transportation industry examples of when systems engineering was used versus not used. Benefits information will be useful to explain how the RA and systems engineering add value and to clear the perception that funds are being taken away from construction. One way of explaining the benefits of systems engineering is through the value engineering concept, which basically says that spending now will save much more later. Money spent in making the project follow a systems engineering approach will lead to savings during project implementation, in operations and system maintenance. It would be useful for FHWA to continue devoting resources to capture successes and lessons learned.

It was agreed that it would be useful to have those involved in the RA as well as people with systems engineering expertise attend monthly project design meetings. Time should be dedicated to RA and systems engineering issues at these meetings.

In one region, the MPO acted as a consultant for a transit project and helped develop a project definition based on RA knowledge. It was mentioned that from a transit perspective, FHWA, FTA and APTA should promote a common systems engineering process to ensure interoperable systems.

Some regions mentioned that there is a need to specify ITS projects better to fully utilize the value of systems engineering. There is a need to do a better job at cataloging ITS specifications. Often, the last ITS project that was implemented provides the standards and specifications for the next ITS project. This approach is reactive and not optimal. One approach would be to have baseline specifications for ITS projects and then add functionality as needed. The RA could possibly drive standards development in a region. This standards development can lead to more compatible and interoperable ITS deployments.

One region that had interest from stakeholders in using the RA for project development has posted the RA and Turbo outputs highlighting the systems engineering related portions on the internet with a feedback mechanism.

All regions agreed that the RA generally helps their projects in involving stakeholders, in improving cooperation and coordination, and in providing a starting point for project development.

Promoting Use of RA for Project Development

Workshop participants emphasized that every State is different. In certain States the local stakeholders have taken the initiative in promoting and using the RA. In others the State DOT or the MPO may play that role. Training and awareness are of primary importance. Once it is understood how the RA, systems engineering and project development fit together, then it will be much easier to promote RA use. Most agreed that the current training in promoting RA use is beneficial. Finding training related money and time is an issue. Participants indicated that dedicated earmark or special funding for training would be useful.

One State has achieved success in promoting and using the RA for projects based on a close working relationship between their MPOs and the State DOT. Another State has had success because they had State Planning and Research (SPR) funding for systems engineering and ITS outreach. One region has used the completed and adopted RA to bring in operations personnel involved in the project development process. In another region the MPO is working with implementers in helping them promote RA use.

Turbo Architecture

Most regions represented at the workshop have used Turbo Architecture for RA development but not for project development. Use of Turbo Architecture has many benefits including providing good RA output. Regions are hoping that the latest version of Turbo Architecture, version 3.0 may be useful for projects as it includes help with developing the concept of operations. Turbo Architecture 3.0 is available through McTrans for a nominal fee. Turbo Architecture training is available through NHI. FHWA does not see Turbo Architecture as a complete tool for systems engineering. There are other good industry tools available to support the systems engineering process. Turbo Architecture has helped regions to feel comfortable enough to develop their RA in-house. Some regions felt they needed to use Turbo Architecture regularly to stay proficient in the use of the tool. Some participants thought that it would be useful to make Turbo Architecture more user friendly because RA development work is in most cases only a part of their responsibilities.

All agreed that State and local agencies do not have enough money for Turbo Architecture and systems engineering training. Participants indicated that FHWA funding for Turbo Architecture training would be useful. It is also important to train some of the regional stakeholders in the use of Turbo Architecture. One region participated with their ITS State Chapter to partner in providing Turbo Architecture training.

Consultant Management

The general consensus is that consultants proficient in RA development are a good resource. One indicator of the capabilities of a consultant is their familiarity and understanding of the Final Rule. Some regions decided not to hire a consultant and to develop their RA in-house. They found this to be a good opportunity for growth in their skills and knowledge of RA and systems engineering.

It is important to know what to look for and expect from a consultant. Having knowledgeable internal staff helps. Stakeholders should make sure that they stay engaged with the RA development and maintenance process if a consultant is hired. There needs to be frequent consultant-agency interaction, training and knowledge transfer in the process development. The sponsor should shadow the consultant. They need to ensure that the consultant is providing overview and training of the process to internal staff as the RA is being developed.

Information Technology Department Involvement in Project Development

Some regions think that it is important to make sure that the IT staff is involved in ITS projects. These regions experienced several benefits by doing so. For example, IT staff can assist in improving projects by reviewing networks and traffic operations center (TOC) configurations. Some regions have been able to share costs with IT departments on ITS components like servers.

Conversely, one region said that IT departments that saw the complexity of ITS may be reluctant to own ITS components. Many IT departments primarily perform office automation activities and may not be aware of ITS software and hardware engineering needs. Some cautioned that involvement of IT staff should not lead to IT staff driving the project.

Overall participants agreed that it can be useful for IT staff to be involved in the project development and deployment process. This must be done with caution. Success and best use of IT resources will depend upon relationships and the expertise of IT staff with ITS, which varies by region. Some regions pointed out that though advantageous, involving IT resources may have other ramifications such as the sharing of networks that are designed to be exclusively for transportation data.

4. RA Maintenance

4.1 Introduction

This section presents the experience of regions in maintaining and updating their RA.

The development and implementation of RA maintenance procedures are requirements of the Final Rule. Stakeholders that were engaged to develop the RA need to continue to be engaged for RA maintenance. As ITS projects are implemented, the RA 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 developed for the region and used to update the RA. This maintenance process should be documented as part of the initial development of the RA in a RA maintenance plan. The goal of the maintenance plan is to guide controlled updates to the RA baseline so that it continues to accurately reflect the regions existing ITS capabilities and future plans.

The collaborative nature of the Regional ITS Architecture development requires approval of changes and updates by more than one stakeholder. The configuration management/change process should reflect the cooperative/collaborative nature of Regional ITS Architecture development. Configuration management is accepted as standard practice in many disciplines and applied across many industries. The same practices can be applied to the maintenance of the RA.

The RA is not meant to be static and will continually evolve. It must change as plans change, ITS projects are implemented, and the ITS needs and services evolve in the region. The RA must be maintained so that it continues to reflect the current and planned ITS systems, interconnections, and other aspects. The events that may cause change to a RA include:

• Changes in regional needs
• New stakeholders
• Changes in scope of services considered
• Changes in stakeholder or element names
• Changes in other related architectures
• Changes in project definition and priority
• Changes due to addition of projects

While many regions have only recently completed or are in the process of completing their RA, there are some regions that have had experience with maintaining their RA. Of the regions with experience in RA maintenance, most have opted to do maintenance in-house, but will consider hiring contractors as needed.

4.2 Major Findings

• In-house RA development may provide some maintenance benefits, although staff turnover could be an issue. Consultants can be considered.
• Changes in the National ITS Architecture and Turbo Architecture are not a reason to change the RA unless the changes affect the components in the RA.
• RA maintenance needs to be carried out through a well defined configuration management process.
• There will be multiple sources for changes and all should be considered.
• It can be challenging to track changes on a project by project basis and correspondingly maintain the RA.
• While some agencies have had success in funding RA maintenance from SPR or MPO work plan funds, finding funding and resources for RA maintenance is an issue.

4.3 Discussion Overview

Participants at the workshop were not sure about what it would take to keep the RA updated in terms of expertise and resources, but they agreed that the project implementer will play an important role in that process.

In-house RA development may provide some maintenance benefits like having a better understanding of the process and saving money; however staff turnover is a problem and may cancel out the knowledge benefit. Retaining proficient staff will be an issue for all.

Most regions are taking over maintenance of the RA unless the RA is too extensive and then it may be more cost effective to have a consultant do the work. Having a good consultant can also have other benefits. One region’s consultant had the experience and initiative and promoted the benefits of the RA to regional partners. This made the overall process much easier. Also, if internal staff resources are constrained, having a consultant can be very beneficial.

Some regions see difficulty with their RA maintenance process in being able to track and manage changes that result from individual projects. A thorough configuration management process helps track changes comprehensively. Most regions agreed that websites seem to be the most popular tool for facilitating RA communication and updates to the baseline documentation. Changes in the RA can also be highlighted with websites. This can be part of continuous RA website improvement.

Some regions plan to do their RA update to be aligned with the TIP. Others vary with some regions planning to maintain and update their architecture on an as-needed basis and some regions are planning to update periodically. Note: The RA maintenance approach for the 8 regions in attendance at the workshop is captured under each regions description in Appendix B.

Some regions only have funding to update the RA within a limited time frame and they are not sure about the sources for future funding. Some agencies have had success in funding RA maintenance from SPR or MPO work plan funds.

Sometimes maintainers may not be aware of all changes that have been made that might affect the RA. The participants agreed that there needs to be a well defined process in place to acknowledge and make changes to the RA since there may be multiple sources for changes. Stakeholders may be required to submit a change consistency certification when proposing changes. These proposed changes can then be evaluated by a review committee with final approval being determined by a body such as an executive committee.

Changes in the National ITS Architecture and Turbo are not a reason to change the RA unless the changes affect the components in a regions RA. There are no plans for a National ITS Architecture version 6.0 right now, but unexpected events could initiate changes.

5. Concluding Remarks

The development and use of the RA can assist in promoting ITS implementation in a region. It can facilitate involving new stakeholders in the larger transportation process. It can help reduce redundancy and aid funding decisions. Adopting or endorsing the RA assists in integrating it with the transportation planning process and promoting its use.

The RA can help the planning process by serving as a source of information. The RA can help the planning process through the ITS inventory, stakeholders and planned ITS projects. The RA and the transportation planning process support each other through better system and inter-jurisdictional integration and through increased stakeholder participation in the LRTP development. It is important to formally adopt the RA to fully utilize the relationships developed during RA development.

The use of a RA and systems engineering for project development provides some benefits and presents some challenges to project implementers. The RA saves time and provides value by creating a baseline for ITS projects that use a systems engineering process. Some of the initial work may have already been done in developing the RA. A starting point thus exists for project development. New processes and procedures can be developed in State DOTs and local agencies to improve coordination between the RA and the SE process.

It is important to maintain the RA after it has been developed. Overall transportation planning issues and project implementation decisions will serve as a basis for change and drive the maintenance effort. The RA is meant to continually evolve. It must change as plans change, ITS projects are implemented, and the ITS needs and services evolve in the region. The RA must be maintained so that it continues to reflect the current and planned state of ITS systems. Maintaining the RA may also present some coordination and resource challenges. Sustaining the continued involvement of stakeholders in the maintenance process will help to ensure that the RA remains current and useful as an ITS planning and implementation framework.

Appendix A - Peer Exchange Invitation and Agenda

Dear Attendee,

The Federal Highway Administration cordially invites you to attend the “Using Your Regional ITS Architecture Peer Exchange Workshop” to be held on 7 & 8 December 2004 in Kansas City, MO. Attached is the invitation letter and enclosures you will be receiving by mail shortly.

The purpose of this workshop is to harness the knowledge and experience of the attendees in using and maintaining their Regional ITS Architectures. The discussions and lessons learned during this Peer Exchange Workshop will be documented and widely distributed for use by the participants and other regions. Approximately 24 individuals will attend this workshop representing eight regions.

This workshop will be held at the Fairmont Hotel, Phone: (816) 756-1500. Federal Highway Administration will pay for travel, lodging and per diem for this workshop. One of the attachments discusses how the invitational travel will work, and I ask that you please call the Fairmont Hotel and make your reservation as soon as possible. Please make your reservation to arrive on 6 December. **For all other arrangements, please contact Barbara McClary at (202) 366-2163.

We would like to briefly contact you to gather some information about your region and architecture. Information about all the participating regions and their architectures will be mailed to you 2 weeks before the workshop.

Thank you for your participation in the Peer Exchange Workshop. Please contact me at (202) 366-2199 or by email with your RSVP and if you have any questions.

Regards and we look forward to meeting you in Kansas City,

Pam

Pamela M. Kordenbrock
ITS Engineer
Federal Highway Administration
400 Seventh Street, SW Room 3404
Washington , DC 20590
202-366-2199
202-366-8712
pamela.kordenbrock@fhwa.dot.gov

Using Your Regional ITS Architecture
Peer Exchange Workshop Agenda
7 December 2004

8 December, 2004