 |
  |
Regional ITS Architecture Guidance Document
|
|
Regional ITS Architecture Guidance Document
This Appendix contains resources that support the maintenance of regional ITS architectures:
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.
Table 19: Sample Change Request Form
Table 20. 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. |
The following provides an example outline for an architecture maintenance plan that follows the guidance given in this document. The exact form and content of each region's plan should be tailored to meet the needs and resources of the region.
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.
The following maintenance plan was developed as part of the Inland Empire ITS Architecture in June 2003.
Start of Inland Empire Example
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:
8.2.1 Who is responsible for Architecture Maintenance?
Just as a group of Stakeholders were key to the development of the Inland Empire Area Architecture, it is imperative that Stakeholders stay involved in the on-going maintenance. Once regional architecture has been completed and approved by all participating agencies, an Inland Empire Architecture Maintenance Team should be developed that has at least one representative from SANBAG, RCTC, SCAG, Caltrans Traffic Operations and Caltrans Transportation Planning, as appropriate (a mix of planning and operations personnel could serve on this Team). This Maintenance Team should make modification decisions together with each of the four agencies (SANBAG, RCTC, SCAG and Caltrans) having one vote in regional decisions for modifying the architecture. In order to ensure that the architecture stays up-to-date, the first action of this Team should be to determine which agency (SANBAG, RCTC, SCAG, or Caltrans) will take formal responsibility for making physical changes toward maintaining the architecture. This leadership role could also rotate on an annual basis for an equal share of responsibility and accountability or, if agreed upon, one agency can take responsibility for the formal database maintenance.
8.2.2 What has to be maintained?
There are several different parts and reports that make up the Inland Empire Regional Architecture. Some require more frequent updates than others, but the entire document will need a periodic review for consistency with regional vision and goals. The current version of Regional ITS Architecture will be established as the baseline Architecture and maintenance time frames identified in this Chapter will begin upon completion.
The Inland Empire Area regional ITS architecture is stored in Microsoft Access databases and is represented through a set of outputs including reports and diagrams. The most significant portions of the architecture will be maintained through updates in the electronic database using TurboArchitecture™. Additionally, the Inland Empire area regional ITS architecture contains several other documents that should be updated at regular intervals:
To aid the Inland Empire in architecture version document control, the filename of the database should contain the date on which the architecture was updated. This will allow the current version to be easily identified.
The following information should be maintained in the TurboArchitecture™ databases:
Outputs such as interconnect and architecture flow diagrams, inventory lists, Stakeholders lists and other diagrams and reports can be produced by a member of the Maintenance Team from TurboArchitecture™ outputs, so they are by-products of the architecture database. These outputs can be updated as necessary for meetings or outreach activities.
8.2.3 When will the Architecture be updated (how often)?
Depending upon the outcome of the SCAG Regional Architecture efforts, the Turbo Architecture™ databases from each of the subregions could become an appendix to the RTP and, as the RTP undergoes a formal update once every three years, the architecture could undergo any major modifications at that time. This will be a natural result of the architecture being stream lined into the regional planning process to ensure that the Architecture continues to accurately represent the region. The operational concept, system functional requirements, project sequencing list, and the list of agency agreements represent high-level views of the Inland Empire Area architecture and do not necessarily need to be modified each time a revision is made to the architecture. However, these documents will be modified as the architecture is broadened to address new needs and services or on an as needed basis.
8.2.4 What is the process by which the Architecture will be modified/changed?
Because changes can arise from many sources, and very likely will arise from some sources outside the technical expertise of a single agency, it is a good idea for a group of people from different Stakeholder areas to be involved in maintenance of the architecture. Representatives from traffic, transit, emergency management, and other key Stakeholders from the team that developed the architecture should provide input to the Maintenance Team for review. Each county has a Technical Advisory Committee (TAC), comprised of the City and County staff, as well as other ITS Stakeholders. These monthly meetings are an ideal place to remind agencies of the architecture, and for the TACs to be a point of contact to discuss ITS architecture updates and processes. Getting input from the Stakeholders guarantees that the architecture continues to reflect the desires of the Stakeholders in the region.
To allow Stakeholders to use the architecture for their planning and deployment activities, the current architecture database should be available from the Inland Empire Maintenance Team. For easy access, other regional Stakeholders should be notified by e-mail when the architecture database and all other current documentation has an exact location or website from which to be accessed.
In addition to maintaining the architecture, this maintenance plan should be reviewed periodically for required changes. This maintenance plan was developed during the initial development of the Inland Empire Area Regional ITS Architecture. Use of the architecture and modifications to it may differ from what was anticipated. Revising the plan will ensure that the goal of architecture maintenance is realized.
8.3 The Change Management Process
The change management process is the procedure for modifying the Architecture. It specifies how changes are identified, how often they will be made, and how the changes will be defined, reviewed, implemented and released.
8.3.1 How Changes Are Identified
The Inland Empire Area regional ITS architecture was created as a consensus view of what ITS systems the Stakeholders in the region have currently implemented and what systems they plan to implement in the future. The architecture will need to be updated to reflect changes resulting from project implementation or resulting from the planning process itself. There are many actions that may cause a need to update the architecture.
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.
End of Inland Empire Example
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.
Start of NE Illinois Example
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:
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:
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:
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:
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-
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
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
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:
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.
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.
End of NE Illinois Example
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.
Start of Oahu Example
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:
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:
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:
3.2 Technical Advisory Committee
Function: To serve as a technical resource to the Policy Committee
Areas of Responsibility:
3.3 ITS Technical Task Force
Composition:
Function: To serve as the ITS technical expert arm of the TAC
Areas of Responsibility:
3.4 Citizen Advisory Committee
Function: to provide public input to the Policy Committee
Areas of Responsibility:
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
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.
As needed, members from the following agencies will be invited to participate on the Task Force:
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:
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:
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:
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:
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:
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:
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
End of Oahu Example
TOC Previous Page Next Page
