Regional ITS Architecture Assessment Guide

Transcription

1 Regional ITS Architecture Assessment Guide Remote Traveler Support Toll Administration Emergency Management Personal Information Access Transit Management Traffic Management ns Fixed Point-to-Fixed Point Communica May 23, 2012 Vehicle Roadway

2 Table of Contents 1 INTRODUCTION REGIONAL ITS ARCHITECTURE ASSESSMENT Assessment Areas Reading the Architecture Completing the Checklist Architecture Scope and Region: Stakeholders: System Inventory: Needs and Services: Operational Concept Functional Requirements Interfaces/Flows Project Sequencing Agreements Standards Identification Use the Regional Architecture Maintenance Plan Completing the Assessment

3 1 INTRODUCTION The purpose of this document is to provide guidance about conducting a regional ITS architecture assessment. It references and provides instruction for completing a separate checklist/questionnaire that is used to conduct the assessment. 2 REGIONAL ITS ARCHITECTURE ASSESSMENT 2.1 Assessment Areas The process of reviewing a Regional ITS Architecture is based on twelve items derived from both the April 8, 2001 USDOT ITS Architecture and Standards Conformity Rule/Policy and from the architecture development process described in the Regional ITS Architecture Guidance Document: Content Criteria Architecture Implementation Criteria 1. Architecture Scope 8. Project Sequencing 2. Stakeholders 9. Agreements 3. System Inventory 10. Standards Identification 4. Needs and Services 11. Using the Regional ITS Architecture 5. Operational Concept 12. Maintenance Plan 6. Functional Requirements 7. Interfaces/Flows 2.2 Reading the Architecture While it may be difficult to read every word and analyze every graphic, it is good to browse the documents, orienting yourself to how the sections are arranged and linked together. Concentrate on the introductory sections and flip through all of the materials to get a sense of the overall breadth of the architecture and to assess the level of detail to which the architecture was written and verify how consistent each of the sections or products are with each other. The cheat sheet (prepared in an earlier session or provided by the facilitators) can be used to identify the sections of the architecture documentation that relate to the criteria areas to be reviewed where is the inventory listed, the stakeholders, service packages, interfaces, etc. Read the Executive Summary, if there is one, carefully since that should contain the scope of the architecture and the ways it was envisioned to be used. If a Turbo file is included, try to open it using Turbo Architecture. If the region s database was developed prior to the release of the version of Turbo you have, you may see a prompt to either Convert or Open the architecture for the purpose of this review it is sufficient to Open the file. Review the file for completeness by selecting each of the tabs to see how 3

4 much information has been included. Then compare the contents of the tabs like Inventory, Services, etc. with the contents of the document. Be sure to document any inconsistencies in the appropriate sections of the checklist. There are several reports within Turbo that can help identify any issues or areas for further investigation: Architecture Summary Unconnected Stakeholders Inventory Unconnected Elements Operational Concept (Roles and Responsibilities) Functional Requirements Inventory to Service Package Comparison Unsupported Flows Additional Integration Options Region Project Sequencing Agreements Standards Look for consistency between the reports and the text of the documents or website. The Unconnected reports provide a quick way to find problem areas. Some of the detailed questions in the next section will describe what to look for in these and other reports. If time becomes an issue then you and your reviewers may need to either divide the effort by assigning different portions to different reviewers or prioritize what gets reviewed perhaps by making sure the documentation is reviewed and saving the review of the Turbo database for when time allows. 2.3 Completing the Checklist The checklist walks through all 12 criteria areas mentioned in section 2.1 above. The following items provide detailed guidance and suggestions of what to look for in each one of the 12 criteria areas Architecture Scope and Region: The regional architecture documentation (document and/or web site) should include a section that defines the scope of the architecture. Scope information may also be included on the Start Tab in Turbo Architecture. When the scope is defined more than once in the regional architecture documentation (e.g., the scope is included in a document, on a web site, and also in the Turbo Architecture database), then each of the scope descriptions should be consistent. This is fundamental information that should be easy to find and available to stakeholders that may not have access to the Turbo Architecture software. Comprehensive guidance and supporting examples are available in Section 3.2 of the Regional ITS Architecture Guidance Document. a. Is the geographic region of the architecture clearly defined? If so, are the boundaries still accurate and applicable for the next update? 4

5 The geographic region covered by the architecture should be defined early in the architecture documentation and may also be included in the Geographic Scope field on the Start Tab in Turbo Architecture. The boundary is normally defined using a map and supporting narrative that describes the map in enough detail to clearly convey what is inside and what is outside the region. The geographic scope should be defined in enough detail to determine the state(s), county(ies), and city(ies) that are covered. Instances where a regional architecture boundary does not coincide with a jurisdictional boundary should be identified. For example, the geographic scope description should clearly indicate that only a portion of a county is included if that is the case. Also, the description should identify if only a portion of a service area (e.g., a transit service area) is included in the geographic region and identify any overlapping or adjacent ITS architectures that are also relevant to the region (see 1.d below). For an architecture that includes a metropolitan area, this definition must clearly relate the architecture boundary to the metropolitan planning area boundary. This is fundamental information of interest to all stakeholders, so this information should be included in a document or web site that is readily accessible to stakeholders. b. Has a timeframe for the architecture been defined? If so, is the timeframe adequate to support intended use in planning, programming, and project implementation? The time horizon of the architecture should be defined early in the architecture documentation and may also be defined in the Timeframe field on the Start Tab in Turbo Architecture. The timeframe should be specified in years and related to the planning horizon of the long range plan, the TIP/STIP planning cycle, or any other regularly occurring regional planning step that relates to or coincides with the architecture time horizon. The time horizon should be greater than five years, shorter timeframes should be well justified. This is fundamental information of interest to all stakeholders that ultimately influences how much should be included in the architecture, so the time horizon should be included in a document or web site that is accessible to stakeholders. c. Has the range of services included in the regional architecture been defined? If so, is the range of services still applicable to the next update? The range of services covered by the architecture should be defined early in the architecture documentation and may also be defined in the Service Scope field on the Start Tab in Turbo Architecture. The scope description should include a summary of the transportation services that are covered and specifically identify any transportation services that are relevant to the region, but covered by other architectures. For example, commercial vehicle services and other statewide services are frequently covered in a statewide architecture and not included in metropolitan area architectures. Any omission of services should be clearly identified with a reference to the architecture(s) that include or will include the services. Like the 5

6 other scope areas, the general discussion of services should be easy to find and access in an architecture document or web site. d. Are all adjacent/overlapping ITS architectures that should be considered in the next update identified? The regional ITS architecture scope should be compatible with the scope of other adjacent and overlapping ITS architectures. For example, a regional ITS architecture for a metropolitan area should take the statewide architecture and any adjacent metropolitan area architectures into account when the scope is established to minimize redundant (and possibly conflicting) definitions in more than one architecture. Any adjacent and overlapping ITS architectures should be identified early in the architecture documentation. The identification of adjacent and overlapping architectures should include the name of the architecture(s), the sponsoring agencies, a summary of the scope of the adjacent/overlapping architectures, and their relevance to the region. The FHWA Statewide and Regional Architecture Development tracking page, can be used to determine the architectures that should be identified. The Start Tab in Turbo architecture can be used to identify adjacent/overlapping architectures in the Related Architectures list Stakeholders: The regional architecture documentation (document and/or web site) should include a section that identifies stakeholders. Stakeholder information may also be included on the Stakeholders Tab in Turbo Architecture. When stakeholders are listed more than once in the regional architecture documentation (e.g., stakeholders are listed in a document, on a web site, and also in the Turbo Architecture database), then each of the stakeholder lists should be consistent. This is fundamental information that should be easy to find and available to stakeholders that may not have access to the Turbo Architecture software. Comprehensive guidance and supporting examples are available in Section 3.3 of the Regional ITS Architecture Guidance Document. a. Are the stakeholders identified in sufficient detail to understand who the players are including agency/department name and jurisdiction? A stakeholder list should be included in the architecture documentation (document and/or web site). The stakeholder list may also be included on the Stakeholders Tab in Turbo Architecture. The stakeholders in the list should be identified at a fairly high organizational level for example, at the agency level for small agencies or at the department/division level for larger agencies. Each stakeholder in the list should include a name and short description that specifies the organization(s) and jurisdiction(s) represented (e.g., Anywhere County Sheriff). In cases where acronyms are used in the stakeholder names, the acronyms should be spelled out in the supporting documentation. When the stakeholder list includes generic stakeholders (e.g., Municipal Public Works 6

7 Departments), the supporting definition should specify the organizations that are represented. In Turbo Architecture, Stakeholder Groups can be specified on the stakeholder tab to support definition of generic stakeholders. b. Is the stakeholders list up-to-date? Is it still commensurate with the anticipated scope of the updated regional architecture? The list of stakeholders should include all the organizations that participate in the transportation services identified in the architecture scope section. The stakeholder list should include federal, state, county, and city/local agencies, depending on the regional scope. Every regional architecture will normally include traffic, transit, public safety, and planning agencies in the stakeholder list. Many other types of organizations (commercial vehicle, rail, various private sector organizations, etc.) may also be included. The Regional ITS Architecture Guidance Document includes a list of candidate stakeholders (see Table 1) that can be used to identify stakeholders that may have been missed. The stakeholder list can also be compared with the inventory to determine if the appropriate stakeholders have been defined. Table 1: Candidate Stakeholders (from Regional ITS Architecture Guidance Document) Transportation Agencies Transit Agencies/Other Transit Providers Planning Organizations Public Safety Agencies State Departments of Transportation (DOT) Local Agencies (City & County) o Department of Transportation o Department of Public Works Federal Highway Administration (FHWA) State Motor Carrier Agencies Toll/Turnpike Authorities Bridge/Tunnel Authorities Port Authorities Department of Airport or Airport Authority Local Transit (City/County/Regional) Federal Transit Administration Paratransit Providers (e.g., Private Providers, Health/Human Services Agencies) Rail Services (e.g., AMTRAK) Intercity Transportation Services (e.g., Greyhound) Metropolitan Planning Organizations (MPOs) Council of Governments (COGs) Regional Transportation Planning Agency (RTPA) Law Enforcement o State Police and/or Highway Patrol o County Sheriff Department o City/Local Police Departments Fire Departments o County/City/Local Emergency Medical Services Hazardous Materials (HazMat) Teams 911 Services 7

8 Other Agency Departments Activity Centers Fleet Operators Travelers Private Sector Other Agencies Information Technology (IT) Planning Telecommunications Legal/Contracts Event Centers (e.g. sports, concerts, festivals, ski resorts, casinos, etc.) National Park & US Forest Services Major Employers Airport Operators Commercial Vehicle Operators (CVO o Long-Haul Trucking Firms o Local Delivery Services Courier Fleets (e.g., US Postal Services, Federal Express, UPS, etc.) Taxi Companies Commuters, residents, bicyclists/pedestrians Tourists/Visitors Transit Riders, others Traffic Reporting Services Local TV & Radio Stations Travel Demand Management Industry Telecommunications Industry Automotive Industry Private Towing/Recovery Business Mining, Timber or Local Industry Interest Tourism Boards/Visitors Associations School Districts Local Business Leagues/Associations Local Chambers of Commerce National Weather Services (NWS) Air & Water Quality Coalitions Bureau of Land Management (BLM) Academia Interests, local Universities National and Statewide ITS Associations (e.g. ITS America, ITE ITS members, etc.) Military There are a couple of techniques that can be used to spot check the stakeholder list in Turbo Architecture. The Unconnected Stakeholders report can be used to identify stakeholders that are not associated with any inventory elements. This is a good way to find ancillary or unused stakeholder entries that can be removed. Also, you can sort the inventory by stakeholder on the Inventory tab and look for the Not Specified category at the top of the list of inventory elements. This category will include any inventory elements that have no assigned stakeholder. 8

9 c. Were the key stakeholders involved in the architecture development process? Will the same stakeholders be involved in the update? The architecture documentation should identify the stakeholders that were actually involved in the architecture development process. Turbo Architecture does not allow for special designation of stakeholders who were involved in the process. For example, the architecture documentation may include workshop attendee lists, a record of stakeholder comments received, or any other artifact of the development process that documents direct stakeholder participation in the development effort. Although individual stakeholder names may be included, the real objective of this question is to determine if the appropriate organizations were involved. The list of involved stakeholder organizations should include a good cross section of the stakeholder agencies with representatives from each of the service areas and representation from state, county, and local levels, as appropriate. Review the list of stakeholders that were involved in the last update and note any additional stakeholders that should be involved in the next update. d. Was a champion established, either individual or group, to lead the development of the architecture? Will the same champion lead the update? The architecture documentation should provide some insight into the organization of the architecture development team and identify the individual or group that led the architecture development effort. Turbo Architecture does not designate a champion. The champion is frequently a representative (or representatives) of the agency that sponsored the architecture development effort. A contractor should never be identified as the champion System Inventory: The regional architecture documentation (document and/or web site) should include a section that defines the System Inventory of the architecture. A system inventory consists of a list of all relevant ITS systems in the region, including the agency who owns and/or operates the system, system status (e.g., does it exist or is it planned), and a mapping to the subsystems and terminators in the National ITS Architecture. a. Has a system inventory been defined that includes a list of applicable regional system elements along with descriptions and assigned stakeholders? The architecture documentation (document and/or web site) should include a list of elements that represent the systems/subsystems in the region. The inventory will also be included on the Inventory Tab in Turbo Architecture if Turbo was used. The inventory list should be organized so that stakeholders can easily find their own inventory elements. Each inventory element should include a name, a short description of the purpose of the element, a list of one or more associated stakeholders, and some indication of the status of the element (e.g., does it already exist or is it planned). Review the elements to verify that they represent systems 9

10 rather than organizations (e.g., State DOT Traffic Operations Center rather than State DOT Traffic Operations Division). Also verify that the inventory does not go into excessive detail (e.g., number/type of controllers) since this level of detail will increase future maintenance. b. Is the inventory up-to-date? Is it still commensurate with the anticipated scope of the updated regional architecture? It may be that the inventory was accurate when the architecture was originally created, but it is now in need of update to reflect deployments in the region. Consider systems that have recently been implemented or updated in the region and check the architecture to determine if these newer systems are accurately depicted. Check for systems that are at the boundary of the region to determine if they were included in the inventory. Note the identified discrepancies. c. Have the National ITS Architecture subsystems and terminators been correctly linked to regional elements? The linkage between inventory elements and National ITS Architecture subsystems or terminators (collectively known as entities) is technically important, but can be largely transparent to the broad cross-section of stakeholders in the region. This mapping is technically important because it determines the functionality and interfaces that will be associated with each inventory element. Improper mappings are frequently the root cause of incorrect or awkward definitions in other areas of the architecture. The mapping to subsystems and terminators may be included in the regional architecture documentation (document or web site). At a minimum, this information should be included in a Turbo Architecture database. In Turbo, the mapping to Subsystems/Terminators is defined on the Inventory tab see the Selected Subsystems/Terminators field on the right side of the tab. You can also use the Sort by: Subsystems/Terminators option on the left side of the Inventory Tab to sort the inventory elements by subsystem/terminator. Sort the inventory elements in this way and then look at the elements that are grouped under several of the subsystems to see if there are any obvious disconnects. For example, a TMC that is not mapped to the Traffic Management Subsystem is a potential error. Alternatively, the Turbo Inventory Report can also be used to generate an inventory listing that is sorted by entity. Finally, the Turbo Unsupported Flows report will identify interfaces that are not supported by the current subsystem/terminator mappings. Inventory elements that are included in this report may have missing subsystem/terminator mappings or there may be other problems. See the Turbo Architecture documentation for more information. Each inventory element should be linked to one or more entities either National ITS Architecture entities or User Defined entities (see question 4e). The function of the element should be consistent with the descriptions of the assigned entities. In general, each element should be mapped to just a few entities. Particularly scrutinize 10

11 cases where a particular element has been mapped to more than four entities to verify the mappings. Another indication of improper mappings is a case where a single element is mapping to entities of more than one class (Center, Field, Vehicle, or Traveler). A complete list of subsystems and terminators is included in the National ITS Architecture ( d. Does the inventory take into account all current adjacent or overlapping regional ITS architectures? Most regional architecture inventories include elements from other regions (e.g., a traffic operations center in a neighboring state) so that the interfaces between regions can be defined. Where these elements are included, the owning architecture should be identified in addition to the inventory information described in 4.a. Naming conventions for these shared elements should be consistent so that the same element is assigned the same name when it is represented in multiple architectures. The region should have a process in place to coordinate the maintenance of inventory elements that are included in more than one architecture so that consistency will be maintained over time. e. (Optional) Does the inventory appropriately map regionally unique elements to userdefined entities that are described in sufficient detail to understand their function? User-Defined entities may be defined in an ITS architecture when the existing National ITS Architecture subsystems and terminators do not adequately cover the desired functionality for the region. User defined entities should be transparent to most stakeholders, so it is OK to relegate these definitions to an appendix in the documentation and/or a Turbo Architecture database. User defined entities are accessed in Turbo from the Tools pull-down menu. The user defined entities that are defined should truly be unique and non-overlapping with the National ITS Architecture subsystems and terminators. At a minimum, user defined entities should include a name and a description that describes their function Needs and Services: The regional architecture documentation (document and/or web site) should include a section that defines the Needs and Services of the region. A description of the regional needs and the transportation services required to address those needs is usually the next step in the definition of a regional ITS architecture. Included in this list is an indication of whether the service currently exists or is planned as well as a mapping to Service Packages in the National ITS Architecture (or equivalent). Note that the service terminology in the National ITS Architecture and Turbo Architecture was changed in Version 7.0 from Market Packages to Service Packages. These terms may be used interchangeably it is likely that the older Market Package terminology will exist in regional ITS architectures for some time. 11

12 a. Are transportation needs for the region defined and described? If so, are the documented needs consistent with the current needs of the region? (Needs may be identified by reference to another document, such as a Strategic Plan.) Regional transportation needs should be identified in the architecture documentation. If regional needs are defined in another document, then this document should be referenced in the architecture documentation. Turbo Architecture Version 5.0 or later can be used to identify needs (or goals/objectives/strategies) using the Planning tab. Whether needs are embedded in the regional architecture documentation or referenced in another document, each need should include a unique name and a description that elaborates on the need in enough detail to support service identification. The description of needs should include enough information to determine the areas in the region that have the need. For example, Alleviate congestion in freeway interchanges and CBD is better than Alleviate congestion. The regional needs identified in the architecture should be related to the goals and objectives identified in the long rang plan for the region to facilitate use of the architecture in long range planning. Also review the needs to determine if the list requires update to make it consistent with the current needs of the region. b. Are transportation services, derived from the needs, defined and described? If so, do the documented services still cover the region s needs? Transportation services that apply to the region should be identified in the architecture documentation (document and/or web site). Transportation services will also be included on the Services tab in Turbo Architecture, if Turbo was used. Each transportation service that exists or is planned should be listed and described. Most regional architectures use the National ITS Architecture service packages as a basis for their tailored list of services. At a minimum, this list will consist of an ordered list of the service packages that were selected for the region. The list may be further tailored using Service Package instances so that names and descriptions are more relevant to the region. Each transportation service should include a name, a description, and status (e.g., existing, planned, or future). There should be clear highlevel traceability from regional needs to transportation services. Also review the services to determine if the documented services still cover the region s needs or if there are obvious gaps or omissions. c. Are the services adequately represented in the regional architecture? (i.e. Are services(service packages) identified and linked to inventory elements?) The link between transportation services and inventory should be identified in the architecture documentation (document and/or web site). This information will also be included in Turbo Architecture see the Selected Elements field on the Services tab if Turbo was used. Each transportation service should be linked to one or more inventory elements, which indicates the portion of the regional architecture that will participate in each service. The Inventory to Service Package Comparison report in 12

13 Turbo Architecture can be used to check for potential issues. For example, this report begins with a list of inventory elements that do not participate in any transportation services. The elements in this list may be missing links to transportation services since elements should typically participate in at least one service. The listed elements could be discussed with the region to determine whether mappings are missing or perhaps the elements are involved in other transportation services that are depicted in the architecture, but not related to the National ITS Architecture service packages Operational Concept The regional architecture documentation (document and/or web site) should include a section that defines the Operational Concept of the architecture. An operational concept defines the roles and responsibilities of the primary stakeholders and the systems they operate in the region. Operational concepts for mid-sized regions and larger are often broken down into ITS functional domain-specific areas for more focused discussion such as traffic management or incident management. a. Has an architecture operational concept been described in sufficient detail to understand the roles and responsibilities of the primary stakeholders in the region in the delivery of ITS services? An operational concept should be included in the architecture documentation (document and/or web site). This information will also be included on the Ops Concept tab in Turbo Architecture if Turbo Architecture was used. The operational concept should be related to transportation services. If Turbo Architecture was used, Role and Responsibility Areas will be defined that are related to one or more service packages. Whatever the mechanism, it is important that the link between transportation services and operational concept is documented. Roles and responsibilities should be defined for each primary stakeholder for related transportation service(s), either in a table or in a formatted report. A role and responsibility statement is a short factual statement like Monitor traffic flow on freeways or First responder to incidents. Formal shall language is not required. In general, the roles and responsibilities should focus on roles and responsibilities that impact more than one stakeholder. If a Turbo Architecture database is available, the Operational Concept (Roles and Responsibilities) report can be sorted by stakeholder and compared with the list of stakeholders to identify stakeholders that are excluded from the Operational Concept. This provides some measure of the completeness of the operational concept. b. Are the documented roles and responsibilities consistent with current operations strategies of stakeholders in the region? Review the identified roles and responsibilities to verify they are current and accurately reflect the real-world roles and responsibilities for the identified agencies in the region. Note any discrepancies. 13

14 c. Are the roles and responsibilities of the operational concept appropriately reflected in the architecture? The roles and responsibilities identified for each stakeholder should be consistent with other parts of the architecture. This consistency can be measured by selecting a role and responsibility and then examining the remainder of the architecture to determine if it has been reflected. For example, if a stakeholder has a role Monitor traffic flow on freeways, then at least one of the inventory elements associated with that stakeholder should include functional requirements and interfaces that support traffic flow monitoring. Spot check a few of these implied connections to determine whether the roles and responsibilities are consistent with the remainder of the architecture definition. To spot check the inventory elements that are associated with a stakeholder in Turbo Architecture, select the Sort By: Stakeholder option under the list of inventory elements on the Inventory tab Functional Requirements The regional architecture documentation (document and/or web site) should include a section that defines the Functional Requirements of the architecture. A set of high-level functional requirements must be created for regionally significant systems in the region. Regionally significant systems include Traffic Management Centers, Emergency Management Centers, Transit Management Centers, and other systems that will be implemented or enhanced with ITS projects. Functional requirements should be high level descriptions of what each ITS element will do in the region. They can be used to reach a common understanding among stakeholders, define a project's scope and requirements, or help identify common functions to reduce redundancy in region-wide ITS systems. a. Have high-level functions been defined for each regionally significant element in the architecture? Functional requirements should be included in the architecture documentation and may also be included on the Requirements Tab in Turbo Architecture, if Turbo was used. Depending on the level of detail in the requirements, a functional requirements report for the entire inventory may be too long to include in the body of a document. In these cases, the detailed functional requirements can be included in the Turbo Database or on a web site, and the precise location of the detailed information can be referenced from the document. At a minimum, the architecture documentation should include a list of the functions (e.g., functional areas or equipment packages) for each inventory element and a reference to additional information sources (appendices, web sites, or databases) for more detailed requirements, as applicable. There are several rules of thumb that an assessor can use to determine if elements are regionally significant and should have functional areas defined. Elements that are regionally significant typically: 1) will be implemented or enhanced with ITS projects, 2) are not defined in another regional 14

15 ITS architecture, 3) provide surface transportation-related services, and 4) are mapped to National ITS Architecture subsystems. If Turbo Architecture was used, the Autoselect capability on the Requirements tab can be used to do a quick check of the functional areas that are included in the architecture. Choose Autoselect to bring up the Autoselect Functional Areas form, adjust the options so that you Autoselect Functional Areas for the entire architecture and allow the tool to both add and remove functional areas. Select Continue to and then select Entire Architecture and both Add and Remove Functional Areas options. A table will be shown that lists all the functional area selection changes that Turbo recommends. Review the list to see if there are any apparent omissions or errors that should be discussed further with the region. b. Are the requirements unambiguously stated in terms of shall statements or similar language such that the required functions of each system can be easily understood? If Turbo Architecture was used, then the functional requirements will be written as formal shall statements (e.g., The center shall collect operational and maintenance data from transit vehicles. ) This type of language should also be used for usersupplied requirements. Note that the default National ITS Architecture requirements do have some ambiguity (e.g., they sometimes include open ended lists) so many regional ITS architectures will also have some level of ambiguity in their requirements. If the requirements are clear, they are probably good enough. Save your most critical review of requirements language for when the project is developed. One indicator of potentially insufficient tailoring is if all possible requirements have been selected. You can use Turbo Architecture to review the database and determine whether some level of selectivity has been used in choosing functional requirements for regionally-significant elements Interfaces/Flows The regional architecture documentation (document and/or web site) should include a section that defines the interfaces that are included in the architecture. Interfaces are defined at two levels of detail - as simple connections between elements ( Interconnects ) and as directed flows that show the exchange of information between elements (information flows or architecture flows the terms are used synonymously). While the interfaces are a critical component of the regional ITS architecture, a complete listing of interfaces can be too long to include in the body of a document, which means they could be relegated to an appendix or database. Whatever the documentation approach, the interfaces should be available to project sponsors that need to use the interfaces to define their projects. a. Are information flows defined between elements with descriptions of the information exchanged and their deployment status (existing, planned, etc.)? Every information flow, including user defined information flows, should include a short one or two sentence description that describes the information that is carried by 15

16 the flow. In most cases, flow descriptions from the National ITS Architecture will be used and there is little need to review these standard descriptions. Focus your review on the user defined flow descriptions since these must be created by hand and may be forgotten or incorrect. Also verify flow status (i.e., is a particular flow really existing?) using your knowledge of the region. You can also spot check for consistency by comparing flow status with inventory status (e.g., look for existing flows that are sent by planned elements) or by comparing request flow status with companion response flow status (e.g., look for existing request flows that have planned companion response flows. If you find these types of apparent errors, a more detailed cross check of flow status can be performed. If Turbo Architecture was used, the Interfaces tab is the best place to review flow status values. The interfaces can be sorted by element name, flow name, or status value on this tab and filters can be used to focus on specific interfaces to quickly review the interface status values from different perspectives. Consult the Turbo Architecture user manual and on-line help for more information. b. Does the architecture include appropriate linkages to elements outside the region or to elements from overlapping or adjacent regional architectures? Most regional architectures include interfaces to elements that are outside the region (e.g., a traffic operations center in a neighboring state or a statewide data collection system that is defined in a statewide architecture.) Spot checking these interfaces to verify that they are appropriate is much like verifying any other interfaces. If you have access to the adjacent or overlapping architecture, it is a good idea to review the overlapping architecture to see if these interfaces at the edge of the regional ITS architecture are also defined in other regional ITS architecture(s). In general, the overlap between regional ITS architectures should be kept to a minimum by defining a particular interface in only one architecture. When the same interface is defined in more than one architecture, the interface should be identical (same information flows with matching descriptions and status). Identify any discrepancies and determine if there is good reason for any scope overlap that is identified. c. Does the architecture address the significant integration opportunities implied by the inventory, needs/services, and the operational concept? Are the identified interfaces up-to-date? A significant proportion of the architect s time is invested in making sure that the interfaces are appropriate based on inventory, needs/services, and operational concept. Due to the number of flows that are included in a regional ITS architecture, this is an area where only a spot check can be performed during a review. In the majority of cases, the interfaces were developed in Turbo Architecture, and the Turbo Architecture tool should be used to do this spot check. In Turbo Architecture, go to the Interfaces tab and use different sorts and filters to look at the flows from different perspectives. For example, look at the flows for a particular element to get a sense if the element is appropriately interfaced. Try a sort by architecture flow name to see if likely architecture flows like incident information have been omitted from selected 16

17 element interfaces. Also, use several of the Turbo reports to look at the interfaces. In particular, the Unsupported Flows report will identify flows that are not supported by the National ITS Architecture definition (for example, there are flows going to/from an ISP that should be going to/from a Traffic Management Subsystem). The Unconnected Elements report will identify elements that have no interfaces. In the majority of cases, unconnected elements are an indication that interfaces are missing. Finally, the Check Request Flows tool (under the Tools pull-down menu) can be used to determine if there are apparent inconsistencies between the request and response flows. d. (Optional) Does the architecture consider regionally unique interfaces (defined via user-defined flows) and are they described in sufficient detail to understand their purpose? Many regional ITS architectures include custom interfaces/information flows that go beyond what is identified in the National ITS Architecture. This evaluation criterion is optional since the absence of user defined flows does not necessarily mean the architecture is deficient. When they are included, user defined flows should be reviewed to verify they are: 1) appropriate, 2) clearly defined, and 3) not overlapping with National ITS Architecture flows. If Turbo Architecture was used to define interfaces, then Turbo Architecture can be used to perform these checks. Select Add Flows under the Tools menu. Look through the list of user defined flows and check the flow descriptions to make sure they are clear. Also check to see if any of the flows are redundant with National ITS Architecture flows. This check requires knowledge of the flows in the National ITS Architecture in order to identify potential overlaps. In general, the user defined flows should represent niche or newer applications that may not be included in the National ITS Architecture. If you see general flows like incident data in the list, these are likely to overlap with National ITS Architecture flows and may be an indicator of redundant user defined flow issues. If many user defined flows are defined, then it is likely that corresponding user defined functions should be identified. A disparity between user defined/tailored functions and user defined flows may indicate a discrepancy that should be reported Project Sequencing The regional architecture documentation (document and/or web site) should include a section that defines a sequence of ITS projects. Project sequencing defines the order in which projects will be implemented, but it may be specified in general terms (e.g., near, mid-, and long term projects). Sequencing should be driven by technical considerations (dependencies between projects) and institutional considerations (funding, regional priorities, etc.). These considerations that were used in project sequencing should also be documented. The project sequencing information should be accessible to transportation planners and project sponsors who need to use this information to identify, fund, and initiate projects. a. Have projects been defined to include the agencies involved, timeframe, and how each is tied to the regional architecture? 17

18 Each project that is included in the project sequencing must be defined in enough detail so that the user can understand the purpose and general scope of the project. The project must be tied to the regional ITS architecture definition so that the subset of the regional ITS architecture that is related to the project can be determined. For example, the project can be tied to a service package (or service package instance). Whatever mechanism is used, the inventory elements and information flows that are associated with the project should be identified in the architecture documentation. The agency(ies) associated with each project should be identified, either directly or indirectly through the relationship between inventory elements and stakeholders. Every project should have an associated timeframe frequently, this will be a general timeframe like near-term, mid-term, or long-term. General timeframes are OK and possibly even preferable to specific calendar year timeframes since the more specific timeframes will increase architecture maintenance requirements. The project sequencing report from Turbo Architecture will list the high-level scoping information from each project architecture contained within the database. b. Is the list of projects up-to-date and consistent with ITS projects that are planned and/or programmed for the region? The project sequencing has a relatively short shelf life since projects are implemented each year and new projects are identified and programmed with each Transportation Improvement Program (TIP) cycle. Review the project sequence and compare the listed projects with your knowledge of local ITS projects that are planned, programmed, and in-development to determine how substantial the updates to the project sequence will be. The current TIP can also be reviewed to determine if the project sequence is relatively up-to-date. The project sequencing documentation should identify the Transportation Improvement Program or other programming document(s) that include the ITS projects, and these projects should be included in the architecture project sequencing in a way that is traceable to the TIP/other documents. c. Have the relationships to the regional architecture and the interdependencies between projects been defined? Each project should be tied to the regional ITS architecture in a consistent way so that relationships and interdependencies between projects can be identified. For example, the reader should be able to identify projects that implement capabilities on the same inventory element or enhance the same architecture interface. These dependencies should be reflected into the project sequencing, although this may be difficult to determine based only on the project sequencing data since project sequencing is largely driven by other (cost/benefits/regional priorities) factors. 18

19 d. Has an initial sequencing of currently defined projects been established? The near-term projects in the project sequencing should be correlated with ITS projects that have been programmed for the region. The timeframes that are identified for each of these currently defined projects is the minimum amount of information that is required to support this criterion since the timeframe assignments sequence the projects in a general sense. d. (Optional) Have opportunities to coordinate implementation schedules with other transportation improvements been investigated? To enhance architecture usage, the project sequencing should be aligned with the transportation plans and programming documents for the region. The project sequencing documentation should describe the information that was used to establish the project sequencing, including references to related planning and programming documents if applicable. Near-term projects may be aligned with major capital improvements that are planned or programmed to realize efficiencies. If considered, these relationships to capital projects should be documented in the project sequencing section of the documentation Agreements The regional architecture documentation (document and/or web site) should include a section that lists the Agreements that will be required to support the integration opportunities identified in the architecture. A list of agreements between the stakeholder organizations whose ITS systems will be exchanging information should be generated prior to implementing relevant projects. This list simply identifies the agreements that should be established but does not define the agreements themselves. a. Have existing interagency agreements in the region been identified/considered by the regional architecture? Is the list of existing agreements up-to-date? The list of agreements should include any interagency agreements that already exist in the region to support ITS implementation, operation, and maintenance. Existing agreements should be identified with enough information so that the involved agencies, the nature of the agreement, and enough identification information so that the actual agreement can be located if necessary. The Agreements tab in Turbo Architecture, and the Agreements report, provide a way to list and describe the agreements and associate them with the participating and lead stakeholders. Frequently, a regional ITS architecture will not include any existing agreements although various mutual aid and other operating agreements are likely to exist in the region. This is an area where the FHWA division office may be well positioned to identify missing agreements since FHWA may be party to some agreements or at least aware of important enabling agreements in the region. If no existing agreements are identified, then there should be some explicit reference to lack of existing 19

20 agreements in the documentation with some rationale. If the list of agreements is completely silent on existing agreements, this should be flagged as a potential issue. b. Have future agreements been identified to implement the regional architecture and support project interoperability? Is the list of future agreements complete and up-todate? The list of agreements should identify future interagency agreements that will be required to support regional ITS architecture implementation. Future agreements should include the nature of the agreement, the involved agencies, and the relationship to either ITS projects or the regional ITS architecture. It is appropriate for the region to focus on nearer term agreements in the list of agreements for example, those that are required to support near and mid-term projects. The agreements documentation can also include other optional information such as the process and procedures for executing agreements between agencies Standards Identification The regional architecture documentation (document and/or web site) should include a section that defines the ITS standards that are related to the architecture, at a minimum. The ITS standards list should be tailored so that it only includes ITS standards that are actually candidates for use in the region. In addition to the list of ITS standards, the architecture documentation should also include a standards plan that defines how ITS standards will be implemented or considered in the region over time. a. Has a plan been documented for how ITS standards will be considered, selected, and/or applied across the region? A plan or strategy for implementing ITS Standards in the region should be included in the architecture documentation. This plan should identify the basic strategy for ITS standards implementation, including a survey of existing ITS standards usage, an identification of the opportunities for ITS standards implementation and likely candidates, and a plan for implementing the candidate ITS standards within the context of project implementation in the region. The plan should consider interfaces within the region and interfaces to systems in neighboring regions. This plan could also include other aspects including educating stakeholders on the importance of standards, identification of points of contact within the region for candidate ITS standards, using agreements to control and encourage consistent standards usage, and a review of interoperability issues that should be addressed. b. Has a listing of ITS standards been generated and tailored that are applicable to the region and projects coming out of the regional ITS architecture? Applicable ITS standards and other information exchange standards that are or will be used in the region should be identified in the regional ITS architecture documentation. The ITS standards lists in most regional ITS architectures were 20