Document farmingtonnm_gov_doc_7e760a285d

The Farmington Regional ITS Architecture Update Draft Documentation April 2015 Submitted By: Consensus Systems Technologies Corporation 17 Miller Avenue, PO Box 517 Shenorock, NY 10587-0517 [PHONE REDACTED] ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page ii Table of Contents 1. Introduction 1 1.1. Purpose 1 1.2. Document Overview 2 1.3. Scope of the Architecture 2 2. Farmington Regional ITS Architecture Development Process 4 2.1. Process to Update the Architecture 4 2.1.1. Conduct Stakeholder Teleconferences 5 2.1.2. Create Initial Architecture Update 5 2.1.3. Stakeholder Outreach Workshop 5 2.1.4. Draft Architecture Update-1 6 2.1.5. Stakeholder Review 6 2.1.6. Finalize Architecture 6 2.1.7. Architecture Documentation 7 2.1.8. Deliver Final Architecture Products 7 2.2. Requirements of the Final FHWA Rule and FTA Policy on 7 2.2.1. Specific Requirements of the Final FHWA Rule or FTA Policy 7 2.2.2. How the Final Rule and FTA Policy Requirements are Met 7 3. ITS Architecture Concepts 9 4. Identification of Stakeholders 4.1. Champion 4.2. Regional Stakeholders 4.3. Operational Concepts 5. Systems Inventory 5.1. Systems by Stakeholder 5.2. Systems by Architecture Entity 6. Needs and Services 6.1. Needs Identification 6.2. 6.3. Comparison of Needs and Services 7. Interfaces and Information Exchanges 7.1. Top Level Regional System Interconnect Diagram 7.2. Customized Service Packages 7.3. Regional Architecture Information 8. Functional Requirements 100 9. Standards 103 9.1. Discussion of Key Standards for the Region 103 9.2. Reference to the Detailed Standards information on the Web 106 10. Project Sequencing 109 10.1. Process For Selecting Projects 109 10.2. How to Use the Recommended Project 117 11. Agreements 119 11.1. Types of Agreements 119 11.2. Existing Agreements 120 11.3. Potential Agreements 121 12. Using the Farmington Regional ITS Architecture 124 12.1. Using the Farmington Regional ITS Architecture in the Planning Process 124 ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page iii 12.1.1. Operational Strategies 127 12.1.2. Strategy Evaluation and Prioritization 128 12.1.3. Metropolitan Transportation Plan 130 12.1.4. Issues/Challenges 131 12.1.5. Recommendations 131 12.2. Using the Farmington Regional ITS Architecture for Programming 131 12.2.1. Architecture Use in Programming Federal Funds 132 12.2.2. Architecture Use in Organization Capital Planning 133 12.2.3. Architecture Use to Identify and Define Projects 133 12.2.4. Challenges 134 12.2.5. Recommendations 134 12.3. Using the Farmington Regional ITS Architecture in Project Definition 135 12.4.5. Issues/Challenges 140 12.4.6. Recommendations 141 13. Maintaining the Architecture 142 13.1. Roles and Responsibilities for Maintenance 143 13.1.1. Definitions 143 13.1.2. Stakeholders 144 13.1.3. Maintenance Working Group 144 13.1.4. Responsible Agency 145 13.1.5. Maintenance Manager 145 13.2. Timetable for Maintenance 145 13.2.1. Periodic 146 13.2.2. Event-Driven Updates 146 13.3. Architecture Baseline 147 13.4. Change Management Process 147 13.4.1. Identify Change 148 13.4.2. Evaluate and Review the Change Request 149 13.4.3. Update Baseline 151 13.4.4. Notify Stakeholders 152 Appendix A: Acronyms 153 Appendix B: Functional Requirements 156 Farmington Regional ITS Architecture 164 Maintenance Change Request (MCR) Form 164 ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page iv Table of Figures Figure 1. Farmington MPO Area Boundary 3 Figure 2. Farmington Regional ITS Architecture Update Process 4 Figure 3. Information flows 10 Figure 4. Example of a National ITS Architecture Service Package 11 Figure 5. Example of Farmington Regional ITS Architecture Customized Service Package 12 Figure 6. Farmington Regional ITS Architecture System Interconnect Diagram 93 Figure 7. Example Customized Service Package 97 Figure 8. Example of Element Detail With Interfaces 98 Figure 9. Example of Architecture Flows Between Elements 99 Figure 10. Example of 107 Figure 11. Example of Standards Mapping Page 108 Figure 12. Example Service Package: APTS02 - Transit Fixed Route Operations for Red Apple Transit 121 Figure 13. ITS Architecture and the Transportation Planning Process 126 Figure 14. Supporting the Transportation Planning Processes 127 Figure 15. Project Implementation Process 135 Figure 16. Change Management Process 148 List of Tables Table 1. Mapping of Requirements to Architecture Outputs 7 Table 2. Stakeholders 14 Table 3. Stakeholder Roles and Responsibilities 17 Table 4. Inventory Sorted by Stakeholder 30 Table 5. Summary of Transportation Needs/Priorities 37 Table 6. Summary of High Priority Transportation Needs 39 Table 7. Selected Regional Services (Service Packages) 40 Table 8. Mapping of Needs to Services 43 Table 9. Applicable ITS Standards 103 Table 10. List of Sources Used for Identifying Projects 110 Table 11. Farmington ITS Projects 112 Table 12. Types of Institutional Agreements 119 Table 13. Existing Institutional Agreements 120 Table 14. Potential Institutional Agreements 122 Table 15. Regional Project Development Process Relation to FHWA System Engineering Process 136 Table 16. Functions (Equipment Packages) Assigned to Architecture Elements 156 Table 17. Equipment Package Descriptions 159 ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page v Revision History Filename Version Date Author Comment FarmingtonITSArchitecture 2015-3- 31 0.1 3/31/2015 J.Baker Initial Draft Draft Farmington ITS Architecture Document 2015-4-7 0.2 4/7/2015 J. Baker Complete First Draft ---PAGE BREAK--- 1. Introduction The Farmington Regional Intelligent Transportation Systems (ITS) Architecture Update is a roadmap for transportation systems integration in the Farmington Metropolitan Planning Organization area over the next 20 years. The architecture has been developed through a cooperative effort by the regional transportation agencies, covering all modes and all roads. The architecture represents a shared vision of how each agency’s systems will work together in the future, sharing information and resources to provide a safer, more efficient, and more effective transportation system for travelers in the region. The architecture is an important tool that will be used by:  Operating Agencies to recognize and plan for transportation integration opportunities in the MPO region;  Planning Agencies to better reflect integration opportunities and operational needs into the transportation planning process; and  Other organizations and individuals that use the transportation system in the Farmington MPO region. The architecture provides an overarching framework that spans all of these organizations and individual transportation projects. Using the architecture, each transportation project can be viewed as an element of the overall transportation system, providing visibility into the relationship between individual transportation projects and ways to cost-effectively build an integrated transportation system over time. The architecture also is coordinated with the New Mexico Statewide ITS Architecture (updated in 2012) to ensure consistency at those jurisdictional and operational points where regionally-based operations coincide and/or integrate with statewide planning and operations. 1.1. Purpose The Farmington Regional ITS Architecture Update represents a consensus blueprint for ITS investments in the Farmington MPO region. This Farmington Regional ITS Architecture Update is an update of the previous version of the Farmington Regional ITS Architecture that was last revised in 2012. The development of this update began by reviewing the existing 2012 architecture and the updated transportation planning documents that were available. With the participation of ITS agencies (stakeholders) in the region, one-on-one interviews were held and then one stakeholder workshop, where the architecture was interactively updated. The architecture goes on to define possible integration opportunities between agencies within the region and adjoining regions and identifies how cooperation between the agencies in the deployment of ITS systems can be used to satisfy transportation needs. This architecture can be used to efficiently structure implementations of ITS technologies. By creating a long range plan for the implementation of these systems and technologies, agencies can: ---PAGE BREAK--- Page 2  Prepare for future expansion  Develop coordinated deployments of ITS  Leverage funding  Identify standard interfaces In addition to structuring implementations of ITS technologies, the Farmington Regional ITS Architecture allows the region to comply with the FHWA Rule/FTA Policy on Architecture and Standards. The FHWA Final Rule 23 CFR 940, (and corresponding FTA policy) to implement Section 5206(e) of the TEA-21 requires that ITS projects funded through the Highway Trust Fund conform to the National ITS Architecture and applicable standards. The Rule/Policy requires that the National ITS Architecture be used to develop a local implementation of the National ITS Architecture, which is defined as a regional ITS architecture. This update of the Farmington Regional ITS Architecture will bring the regional architecture into full compliance with this Rule/Policy, which will facilitate the approval of federal funds to support ITS projects in the region. 1.2. Document Overview This document is organized into thirteen main sections and four Appendices. Section 1 provides introductory information on the project, this document, and discusses the scope of the architecture. Section 2 describes the process used to develop the Farmington Regional ITS Architecture Update. Section 3 gives a brief introduction and overview of the National ITS Architecture, and how it relates to this regional ITS architecture. The stakeholders are identified in Section 4, while their systems are inventoried in Section 5. The needs addressed by ITS and the services used to address those needs are covered in Section 6. The interfaces and information exchanges are described in Section 7. The definition of functional requirements for the elements of the architecture is described in Section 8. A discussion of ITS standards applicable to the region is provided in Section 9. A listing of planned ITS projects in the region, along with sequencing of these projects, are described in Section 10. A discussion of agreements is provided in Section 11. Finally, Section 12 provides guidance on using the regional ITS architecture and Section 13 presents the architecture maintenance plan. The Appendices include a list of Acronyms (Appendix a detailed listing of the functions assigned to each element (Appendix and the Maintenance Change Request Form (Appendix 1.3. Scope of the Architecture The geographic scope of the architecture is the entire Farmington MPO boundary, which is shown graphically in Figure 1. The Farmington MPO region covers San Juan County, the City of Farmington, The City of Aztec, and the City of Bloomfield. There is one other ITS architecture thatoverlaps with the Farmington Regional ITS Architecture: the New Mexico Statewide ITS Architecture. The New Mexico Statewide ITS Architecture provides a general expression of systems in the state, while the Farmington regional ITS ---PAGE BREAK--- Page 3 architecture provides specific examples of the systems within the Farmington MPO region. For example, the Statewide ITS Architecture describes interfaces to the element MPO/RPO Traffic Database, while the Farmington architecture describes a specific example of this for the region, the Farmington MPO Data Warehouse. The Statewide ITS Architecture was updated just prior to this update of the Farmington architecture and there was significant review of the Statewide ITS Architecture to verify that the contents of both architectures are consistent between the two architectures. Figure 1. Farmington MPO Area Boundary As mentioned in the introduction, the timeframe considered for the Farmington Regional ITS Architecture is a 20-year outlook for ITS activities in the region, with an emphasis on those ITS activities likely to be implemented in the next 5 years. This means that the architecture addresses existing ITS systems as well as those planned for development over the next 20 years. The regional ITS architecture represents a snapshot of the currently anticipated ITS and other projects based on information gathered from stakeholders, and research from agency websites or published agency documents. The architecture covers services across a broad range of ITS, including traffic management, maintenance and construction operations, incident management, emergency services, transit management, traveler information, and archived data management. ---PAGE BREAK--- Page 4 2. Farmington Regional ITS Architecture Development Process 2.1. Process to Update the Architecture The development of the Farmington Regional ITS Architecture Update relied heavily on stakeholder input to ensure that the ITS architecture reflected local and regional needs and plans. The development process used is illustrated in Figure 2. Figure 2. Farmington Regional ITS Architecture Update Process The following process steps were used to develop the ITS architecture:  Conduct kickoff teleconference and brief teleconferences with key stakeholders in the region to determine major changes to the architecture  Create an initial architecture update focusing on ITS elements and a draft set of customized ITS Services to be provided based. This includes updating the architecture to version 7 of the National ITS Architecture.  Conduct stakeholder outreach through a one-day workshop on February 10, 2015.  Create a complete updated architecture definition for review (web-based).  Allow stakeholder review of the draft regional ITS architecture and submit comments  Finalize the ITS architecture based on review comments.  Develop and deliver a draft Architecture document.  Following comment resolution deliver the final architecture products. Stakeholder Telecons Create initial architecture Stakeholder workshop Create draft architecture Stakeholder Review Draft Document Deliver Final Architecture Products ---PAGE BREAK--- Page 5 2.1.1. Conduct Stakeholder Teleconferences As a starting point for updating the Farmington ITS Architecture, teleconferences were conducted with key stakeholders. These included:  New Mexico Department of Transportation: District 5  City of Farmington Traffic Engineering  City of Bloomfield  City of Farmington Fire Department  Red Apple Transit (conducted later in process) These five groups represent key stakeholders in the Farmington Region, and were therefore selected to be interviewed prior to creating the initial architecture update. 2.1.2. Create Initial Architecture Update An updated set of ITS elements, services and interconnections were created beginning with the original Farmington regional ITS architecture. The previous version was in the format of version 5.1 of the National ITS Architecture. As part of the update, all components of the architecture were updated to version 7 of the National ITS Architecture, which is the current version. For each existing or future ITS service operating or expected in the region, the service package diagram (the collection of ITS elements, equipment packages, and functions that work together to perform a specific ITS service – see Section 3 for details on the National ITS Architecture) for that service from the National ITS Architecture was edited so that each National ITS Architecture or terminator was associated with the local stakeholder element name. In some cases, multiple instances of the service package were developed where the service had more than one instance in the region. This would be the case if there were multiple agencies performing the same service within the region. This set of customized service packages using the draft elements created previously, was created in preparation for stakeholder outreach so that each could be reviewed and further customized based on actual operating procedures (or theories) for each agency. 2.1.3. Stakeholder Outreach Workshop A one-day stakeholder workshop was held at the Farmington MPO Office on February 10 2015. A key overall objective of the meeting was to develop a regional ITS architecture update that is a consensus architecture, that is, each of the participants understands and agrees to the ITS elements and specific information exchanges between the ITS elements identified in the architecture that they participated in defining. This is not to say that the resulting ITS Architecture has credible funding identified that would lead to full deployment. The ITS architecture only identifies the current set of ITS elements and interfaces that the stakeholders agree to. Existing funding processes will continue to be used to decide how to allocate limited resources for ITS elements and interfaces for deployment. The meeting also incorporated an overview or training in the National ITS Architecture and regional ITS architectures, and a discussion of the scope of the architecture, so that stakeholders would understand and more fully participate in the ITS architecture development ---PAGE BREAK--- Page 6 process. The first part of the workshop focused on understanding ITS, what an ITS Architecture is, and the development approach for the regional ITS architecture update. After some basic training on ITS architectures, the focus shifted to developing the Farmington Regional ITS Architecture update. Stakeholders were asked to participate in identifying and defining their ITS needs while reviewing and revising their draft inventory and the inventory of fellow stakeholders. The second part of the workshop was spent reviewing the customized service package diagrams, adding or deleting diagrams, elements, and interconnections when necessary. 2.1.4. Draft Architecture Update-1 Following the stakeholder workshop, the customized service packages were revised and a draft architecture was created. Using the customized service package diagrams (as modified during and post the workshop), the Turbo Architecture database was updated, “built”, and utilized to create a draft ITS architecture. This involved the following activities:  Updating the ITS inventory, stakeholders list and project list.  Revising the customized service packages  Development of a draft Operational Concept  Creating a Turbo Architecture database that represents the sum of all of the customized service packages.  Creating a set of project architectures, which mapped projects identified by stakeholders to their relevant stakeholders, inventory, service packages, and operational concepts. A draft of this architecture document was created. There was also a hypertext version of the complete Turbo Architecture database that was created and placed on a generally accessible website This website describes each element of the ITS architecture and all of their interconnections with other elements. The website was developed using additional software tools that go beyond the basic Turbo Architecture software. 2.1.5. Stakeholder Review Stakeholders were notified by email (collected at the kick-off meeting, the stakeholder meetings and through independent research on the internet) that a review period for the Farmington Regional ITS Architecture Update had commenced, and feedback was solicited. Stakeholders were encouraged to review the regional ITS architecture on the website, and were encouraged to provide feedback electronically from the website. 2.1.6. Finalize Architecture Following the stakeholder review period, the architecture parts were again updated, to resolve the comments received during this time. ---PAGE BREAK--- Page 7 2.1.7. Architecture Documentation A draft Architecture document was created. This document, along with an updated web site, forms a complete description of the Farmington Regional ITS Architecture that is compliant with the architecture and standards Rule. 2.1.8. Deliver Final Architecture Products Following a comment period on the document and revised website, a final architecture document and final updated website will be developed as the final deliverables on the architecture. 2.2. Requirements of the Final FHWA Rule and FTA Policy on Architecture 2.2.1. Specific Requirements of the Final FHWA Rule or FTA Policy The FHWA Final Rule (23CFR 940) and FTA Policy on Intelligent Transportation System Architecture and Standards, which took effect on April 8, 2001, defines a set of requirements that regional ITS architectures should meet. The following is a list of specific requirements from the FHWA Rule/FTA Policy:  A description of the region (scope)  Identification of participating agencies and their systems (inventory)  Operations concepts  Agreements required for implementation  System functional requirements  Interface requirements  Identification of ITS Standards  Sequence of projects required for implementation  Develop a Process for maintaining your regional ITS Architecture 2.2.2. How the Final Rule and FTA Policy Requirements are Met Table 1 shows how the requirements of the rule are met by the outputs developed for the Farmington Regional ITS Architecture: Table 1. Mapping of Requirements to Architecture Outputs Regional ITS Architecture Requirements Where Requirements Documented Description of region Geographic definition, identification of services and a timeframe are given in Section 1 of this document. ---PAGE BREAK--- Page 8 Regional ITS Architecture Requirements Where Requirements Documented Identification of participating agencies and other stakeholders Listing of stakeholders and their definitions is given in Section 4 of this document. An inventory of the elements operated by the stakeholders is contained in Section 5 of this document. The same information is also available in the hyperlinked web site and in the Turbo Architecture database. An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders The operational concept is defined in Section 4 of this document. A list of any agreements (existing or new) required for operations The discussion of existing and needed new agreements is given in Section 11 of this document. System functional requirements The functional requirements of the ITS systems are described in an overview in Section 8 of this document, are presented in detail as Appendix B of this document, They are also provided in detail in the hyperlinked web site and in the Turbo Architecture database. Interface requirements and information exchanges with planned and existing systems and The Interfaces and information flows are described in a general way in Section 7 of this document, and are described in detail in the hyperlinked web site and in the Turbo Architecture database. Identification of ITS standards supporting regional and national interoperability The general identification of standards for ITS in the Farmington region is contained in Section 9 of this document. The detailed descriptions of standards for each interface is described in the hyperlinked web site and in the Turbo Architecture database. The sequence of projects required for implementation Projects, and their sequencing, are covered in Section 10 of this document. Develop and implement procedures and responsibilities for maintaining the architecture as needs evolve within the region. The Maintenance Plan is contained in Section 13 of this document. ---PAGE BREAK--- Page 9 3. ITS Architecture Concepts The Farmington Regional ITS Architecture is an example of a Regional ITS Architecture, which has been defined by FHWA Rule 940 as a “regional framework for ensuring institutional agreement and technical integration for implementation of ITS projects”. Regional ITS architectures, including the Farmington Regional ITS Architecture, are developed in order to provide a guide for the integration of transportation systems. The updated architecture is based upon the US National ITS Architecture Version 7. A complete description of this architecture can be found at http://www.iteris.com/itsarch. The Farmington Regional ITS Architecture Update uses a set of common concepts or terms drawn from the National ITS Architecture to describe the parts of the Farmington region. This section will provide a description of the most common concepts or terms as an aid to the understanding the remainder of the document. What are some of the main parts of an ITS architecture? They are made of the following:  Organizations  Systems operated  Services provided  Functions performed  Information exchanged The organizations that operate systems in the region covered by the architecture are referred to as stakeholders. These are public agencies, private organizations or the traveling public with a vested interest, or a "stake" in one or more transportation elements within a Regional ITS Architecture. The systems operated by the stakeholders are referred to as elements. In the Farmington Regional ITS Architecture the elements represent actual systems, such as Farmington Traffic Operations Center. An element may also represent field devices, for example the element City of Farmington Field Devices. A more thorough discussion of the architecture elements is contained in Section 5. As mentioned above, the Farmington Regional ITS Architecture Update is based upon the National ITS Architecture which contains general terms for these systems (elements). Since these National ITS Architecture terms show up repeatedly in later discussion they will be defined here. The National ITS Architecture uses two terms to describe the systems that make up an architecture. They are:  which represent the primary systems described by the architectures. For example the TMC element mentioned above represents a regional ITS architecture example of the Traffic Management defined in the National ITS Architectures. The National ITS Architecture has 22 defined. ---PAGE BREAK--- Page 10  Terminators, which represent systems that are on the boundary of the architecture. In general only interfaces to the terminators are described in the national architectures. An example of a terminator from the National ITS Architecture is the Weather Service. The National ITS Architecture has 76 terminators defined. As a part of developing a regional ITS architecture, each element of the region is mapped to the and/or terminators that most closely define the functions of the element. This mapping allows the regional version to use the details associated with the and terminators in the National ITS Architecture. As an example, the element in the Farmington Regional ITS Architecture Update called National Weather Service is mapped to the National ITS Architecture terminator Weather Service. The information exchanged between elements (in the Farmington Regional ITS Architecture Update) or between and terminators in the National ITS Architecture is described by information flows or architecture flows. There are hundreds of these flows defined in the National ITS Architecture, and it is this information that is used to create the interface definitions in the Farmington Regional ITS Architecture. For example, in Figure 3 the top two boxes show an interface between two with its information flows defining the exchange of information. A corresponding interface in the Farmington Regional ITS Architecture is shown in the bottom two boxes. Figure 3. Information flows By mapping the Farmington Regional ITS Architecture elements (e.g. Farmington Traffic Operations Center) to National ITS Architecture (or terminators) (e.g. Traffic Management the interfaces defined in the National ITS architecture can be used as the basis for defining the interfaces in the Farmington Regional ITS Architecture. Centre Operations TOC Farmington Traffic Operations Center Emergency Preparedness San Juan County Communications Center incident information Traffic Management Emergency Management National ITS Architecture representation of an interface Farmington Regional ITS Architecture representation of a similar interface incident information ---PAGE BREAK--- Page 11 The next key concept used by the architectures is that of service packages. These represent slices of an architecture that provide a transportation service. In the National ITS architecture, these service packages are combinations of and information flows that are used to provide the service. An example of a National ITS Architecture service package is shown in Figure 4. This shows the and information flows (some of which go to terminators) that perform the collection and distribution of traffic flow and traffic images used to monitor a road network. In the development of the Farmington Regional ITS Architecture, a set of customized service packages were created that define the elements and interfaces used to provide the transportation services in the Farmington Region. Figure 4. Example of a National ITS Architecture Service Package Figure 5 shows one of the customized service packages within the Farmington Regional ITS Architecture (in this case for the City of Farmington). This diagram shows how the city might implement this service. There are two types of interfaces shown in the customized service package:  Traffic Management Center to Roadside Equipment and  Traffic Management Center to Information Service Provider ATMS01 – Network Surveillance Traffic Management traffic operator data traffic operator inputs Collected Traffic Surveillance traffic flow + traffic images traffic sensor control + video surveillance control Other Roadway roadway equipment coordination traffic characteristics Information Service Provider road network conditions Roadway Traffic Maintenance Roadway Basic Surveillance Traffic Map Update Provider map updates map update requests Traffic Operations Personnel Roadway Equipment Coordination ---PAGE BREAK--- Page 12 Figure 5. Example of Farmington Regional ITS Architecture Customized Service Package Notice that the customized service package includes only some of the interfaces that were in the National ITS Architecture service package. It does not include interfaces to personnel or a map update provider element. Elements mapping to these are not included in the Farmington Regional ITS Architecture. One final concept to mention relates to the functions performed by the elements in the architecture. The National ITS Architecture has the concept of an equipment package, which defines a piece of a (within the service package) that performs a specific function. For example, in Figure 4, Collect Traffic Surveillance (identified by the white box within the Traffic Management is a function (or equipment package) that is performed by the Traffic Management when performing the Network Monitoring Transportation Service. In the Farmington Regional ITS Architecture functions have been identified for the key elements from a mapping of equipment packages to elements using a mapping of equipment packages to each element. For example, the Farmington Traffic Operations Center (shown in Figure 5) will implement the Collect Traffic Surveillance equipment package (shown in Figure 4 as functionality in the Traffic Management Further information regarding how functions are defined for each element is found in Section 8 on Functional Requirements. ---PAGE BREAK--- Page 13 4. Identification of Stakeholders 4.1. Champion In order to successfully develop a Regional ITS Architecture for the Farmington Region, it is necessary to have a “champion” who can lead the effort from the agency’s viewpoint. This individual, or group of individuals, should have the following skills/capabilities:  They must have a vision for interconnectivity, partnership and regional integration.  They must have knowledge of the local and regional ITS systems and projects.  They must understand what a regional ITS architecture is and how to use it most effectively in the planning process.  They must be a consensus builder or facilitator, and  They must have executive level access to resources in order to gain the support of various regional or statewide agencies. The Champion for the development of the Farmington Regional ITS Architecture is the Farmington Metropolitan Planning Organization (MPO). A designated Farmington MPO planning staff person will continue to champion the use and maintenance of the Farmington Regional ITS Architecture (along with input and consensus from the stakeholders) beyond the timeframe of this development effort. 4.2. Regional Stakeholders Stakeholder coordination and involvement is one of the key elements to the development of a regional ITS architecture. Because ITS often transcends traditional transportation infrastructure, it is important to consider a range of stakeholders beyond the traditional traffic, transit, and maintenance areas. In addition, it is important to consider stakeholders at a regional level in adjoining regions of the state. The Farmington Regional ITS Architecture includes a wide range of stakeholders. Many of these stakeholders were present at the stakeholder workshop described in Section 2 above. The following is a list of agencies/participants who were either present during the architecture development workshops and provided their input during those workshops, or who were contacted specifically by Corporation for their inputs on the Farmington Regional ITS Architecture:  City of Aztec  City of Farmington – Fire Department  City of Farmington – Traffic Engineering  FHWA ---PAGE BREAK--- Page 14  Farmington Metropolitan Planning Organization  NMDOT – District 5  NMDOT - ITS Bureau  Red Apple Transit  San Juan County EMS The Farmington Regional ITS Architecture is defined by a set of elements (or systems), each of which is owned (or operated or maintained) by a stakeholder. The above listing includes all the agencies that attended stakeholder meetings. Most, but not all of them own, operate, or maintain elements in the architecture. (An example of an agency that does not is FHWA, whose role in the Farmington Regional ITS Architecture is approval of the ITS Architecture and approval of projects for funding by the federal government that are represented therein.) Table 2 provides a listing of the full range of stakeholders who own or operate elements in the Farmington Regional ITS Architecture. The table provides a name and description of the agency, department, or organization represented by the stakeholder. The list of stakeholders can also be found on the Farmington Regional Architecture web page by selecting the “Stakeholders” button on the left side menu bar. Table 2. Stakeholders Stakeholder Name Stakeholder Description Aztec Fire Dept Provides fire, rescue and emergency services to the city of Aztec Aztec Police Dept Provides 911 services and emergency response Bloomfield Fire Dept Provides fire, rescue and emergency services to the city of Bloomfield Bloomfield Police Dept Provides 911 services and emergency response Bureau of Indian Affairs Federal Agency providing emergency services in Navajo lands. City of Aztec Public Works Road maintenance and construction City of Bloomfield Public Works Road maintenance and construction City of Farmington Represents the City of Farmington departments including Red Apple Transit City of Farmington Streets Road maintenance and construction City of Farmington Traffic Engineering Signal operation, timing, and maintenance; Traffic Management Commercial Vehicles Represents commercial vehicles on the roadway Farmington Fire Dept Provides fire, rescue and emergency services to the city of Farmington ---PAGE BREAK--- Page 15 Stakeholder Name Stakeholder Description Farmington Police Dept Provides 911 services and emergency response Ignacio Road Runner Transit Provides transit service between Ignacio, CO and Aztec Local Transit Agencies Represents local transit agencies in the Farmington region Navajo Nation Represents the Navajo Nation Navajo Transit Provides fixed route service throughout Navajo Nation and connects to Red Apple Transit New Mexico Dept of Public Safety Motor Transportation Division and statewide commercial vehicles Newspapers, Television, Radio Stations Represents local media outlets NMDOT - New Mexico Department of Transportation Statewide stakeholder for the New Mexico Department of Transportation. NOAA National Oceanic and Atmospheric Administration Other State Agencies This stakeholder includes DOTs and other traffic management agencies in other states for the purposes of interstate highway coordination. Private Commercial Carriers Private owners of commercial vehicles that carry goods throughout the state Private Sector Traffic Data Providers Vendors that provide traffic data related services Private Traveler Information Systems Represents third-party private industry information systems Private Travelers Personal Computing Devices Represents private travelers accessing information on personal computing devices Red Apple Transit Provides fixed route service: five routes in Farmington and regional routes to Aztec, Bloomfield, and Kirtland. Also provides Paratransit Regional Hospital Providers Represents regional hospital providers, including the San Juan Regional Hospital San Juan County Communications Authority Responsible for operation of the regional public safety answering point. San Juan County Fire Dept Provides fire, rescue and emergency services to San Juan County San Juan County Public Works Road maintenance and construction San Juan County Sheriff Dept Provides 911 services and emergency response San Juan Regional EMS San Juan Regional EMS is the emergency medical services provider for the eastern half of San Juan County. Special Event Promoters Promoters and sponsors of special events Vehicles Represents vehicles on roadways ---PAGE BREAK--- Page 16 The stakeholders listed in Table 2 represent a mix of specific agencies or organizations and generic names used to represent a variety of stakeholders. An example of a specific agency or organization from the architecture is City of Farmington Traffic Engineering, which represents the City of Farmington department responsible for traffic operations throughout the City. An example of a generic stakeholder name would be Other State Agencies, which represents traffic management agencies in neighboring states, such as Arizona and Colorado. Another example of a general stakeholder in the architecture definition is Regional Hospital Providers, which would represent any hospitals in the Farmington MPO region. 4.3. Operational Concepts An operational concept documents each stakeholder’s current and future roles and responsibilities in the operation of the regional ITS system. The operational concept documents these roles and responsibilities across a range of transportation services. The services covered by the Farmington Regional ITS Architecture include:  Traffic Signal Control. The development of traffic signal systems that react to changing traffic conditions and provide coordinated intersection timing over a corridor, an area, or multiple jurisdictions.  Highway Management. The development of systems to monitor freeway traffic flow and roadway conditions, and provide strategies such as ramp metering or lane access control to improve the flow of traffic on the freeway. Includes systems to provide information to travelers on the roadway.  Incident Management. The development of systems to provide rapid and effective response to incidents. Includes systems to detect and verify incidents, along with coordinated agency response to the incidents.  Transit Management. The development of systems to more efficiently manage fleets of transit vehicles or transit rail. Includes systems to provide transit traveler information both pre-trip and during the trip as well as electronic fare payment systems used on transit vehicles.  Traveler Information. The development of systems to provide static and real time transportation information to travelers.  Emergency Management. The development of systems to provide emergency call taking, public safety dispatch, and emergency operations center operations.  Maintenance and Construction Management. The development of systems to manage the maintenance of roadways in the region, including winter snow and ice clearance. Includes the managing of construction operations.  Archive Data Management. The development of systems to collect transportation data for use in non-operational purposes (e.g. planning and research). ---PAGE BREAK--- Page 17 Table 3 identifies the roles and responsibilities of key stakeholders for the specified range of transportation services. Table 3. Stakeholder Roles and Responsibilities RR Area Name Stakeholder RR Description RR Status Commercial Vehicle Operations City of Farmington City of Farmington Fire will respond to HAZMAT incidents. Planned New Mexico Dept of Public Safety NMDOT will develop check point stations for commercial vehicles traveling through MPO region Planned NMDOT will track commercial vehicles carrying HAZMAT material Planned San Juan County Fire Dept SJC Fire responds to HAZMAT situations Existing Emergency Management Aztec Fire Dept Respond to emergencies with the City's fire vehicles. Planned Receive local signal preemption from the City of Aztec traffic signals. Planned Respond to emergencies with the City's police vehicles. Planned Bloomfield Fire Dept Bloomfield Fire Dept Receive local signal preemption from the City of Bloomfield traffic signals. Planned Respond to emergencies with the City's fire vehicles. Planned Bloomfield Police Dept Respond to emergencies with the city's police vehicles. Planned Farmington Fire Dept Receive local signal preemption from the City of Farmington, City of Aztec, City of Bloomfield, and San Juan County traffic signals. Planned ---PAGE BREAK--- Page 18 RR Area Name Stakeholder RR Description RR Status Respond to emergencies with the city's fire vehicles. Planned Farmington Police Dept Respond to emergencies with city Police vehicles. Planned New Mexico Dept of Public Safety Plan and coordinate the response to HAZMAT incidents. Planned Generate Amber Alerts and distribute them to regional emergency management agencies and traffic agencies. Planned Dispatch State Police vehicles in the region. Planned Operate the New Mexico Statewide EOC. Planned Plan and coordinate region wide emergency plans, evacuation and reentry plans and disaster management plans. Planned Generate and coordinate wide area alerts and distribute them to regional traffic and emergency management agencies. Planned Participate in regional incident response and coordination. Planned NMDOT - New Mexico Department of Transportation Aid in the coordination of region wide emergency plans, evacuation and reentry plans, and disaster management plans. Planned Provide evacuation, incident, and transportation system status information to regional public information systems, the media, and on the NDOT website. Planned Receive Amber Alert and other Wide Area Alert information from state police and post alert information on the NMDOT DMS. Planned ---PAGE BREAK--- Page 19 RR Area Name Stakeholder RR Description RR Status San Juan County Communications Authority Receive Amber Alert and other Wide Area Alert information from state police. Planned Aid in the coordination of region-wide emergency plans, evacuation and reentry plans, and disaster management plans. Planned Provide evacuation, incident, and transportation system status information to regional public information systems. Planned Receive early warning information from the New Mexico Statewide EOC Planned Operate the regional EOC. Planned Receive and respond to threat information regarding critical infrastructure. Planned Track location of all regional public safety vehicles. Planned Dispatch all regional police, fire and EMS vehicles and coordinate with all other public safety agencies and communication centers in the region. Planned Respond to transit emergencies/alarms on board transit vehicles or at regional transit facilities. Planned Coordinate with regional hospitals and care facilities during emergencies. Planned San Juan County Fire Dept Respond to emergencies with County fire and EMS vehicles. Planned Receive signal preemption from San Juan County, City of Farmington, City of Aztec, and City of Bloomfield traffic signals. Planned ---PAGE BREAK--- Page 20 RR Area Name Stakeholder RR Description RR Status San Juan County Sheriff Dept Respond to emergencies with County Sheriff vehicles. Planned Receive local signal preemption from San Juan County, City of Aztec, City of Bloomfield, and City of Farmington traffic signals. Planned San Juan Regional EMS Respond to emergencies with San Juan Regional EMS vehicles. Existing Coordinate with local hospitals and care facilities during emergencies. Existing Receive local signal preemption from the City of Farmington, City of Aztec, City of Bloomfield and San Juan County traffic signals. Planned Freeway Management NMDOT - New Mexico Department of Transportation Provide traffic information to the general public through traffic information devices Existing Perform network monitoring for detection and verification of incidents on state owned highways. Existing Provide traffic information reports to NMRoads, regional information service providers, and private information service providers Planned Coordinate traffic information with other State's regional TOCs or Statewide TOCs through NMRoads Planned Coordinate traffic information with other regional TOCs Planned ---PAGE BREAK--- Page 21 RR Area Name Stakeholder RR Description RR Status Incident Management Aztec Police Dept Respond to incidents on surface streets with the city's police vehicles as well as coordinate with all other public safety agencies within the region. Planned Bloomfield Police Dept Respond to incidents on surface streets with city police vehicles, as well as coordinate with other public safety agencies in the region. Existing Farmington Police Dept Respond to incidents on surface streets with city police vehicles, as well as coordinate with other public safety agencies in the region. Existing New Mexico Dept of Public Safety Respond to incidents on state roads with NM DPS vehicles. Planned NMDOT - New Mexico Department of Transportation Coordinate incident response with state police and regional public safety providers Planned Perform incident detection and verification on state highways and provide this information to NMRoads and regional TMCs. Planned San Juan County Communications Authority Dispatch all police, fire, sheriff, and EMS vehicles in response to incidents within the region. Existing Coordinate incident response with all regional municipal public safety agencies. Planned Coordinate incident response with NMDOT and other regional traffic management centers. Planned Receive emergency calls for incidents in the region. Planned ---PAGE BREAK--- Page 22 RR Area Name Stakeholder RR Description RR Status San Juan County Sheriff Dept Respond to incidents on county roads with county sheriff vehicles, as well as coordinate with other public safety agencies within the region. Existing San Juan Regional EMS Respond to incidents on all roadways in the region with San Juan Regional EMS vehicles, as well as coordinate with all other public safety agencies within the region. Planned Maintenance and Construction City of Farmington Streets Collect environmental sensor data with agency field equipment Planned Distribute maintenance plans and work zone information to other regional agencies, including traveler information providers Planned Provide maintenance resources to assist regional emergency management agencies in incident response. Planned Provide winter road maintenance for city streets Planned Dispatch City of Farmington Street maintenance vehicles Planned Manage work zones and monitor work zone safety Planned Coordinate maintenance activities with other regional maintenance and construction agencies. Planned NMDOT - New Mexico Department Provide winter road maintenance for District 5 highways Planned ---PAGE BREAK--- Page 23 RR Area Name Stakeholder RR Description RR Status of Transportation Collect road weather information with agency field equipment and distribute it to regional traffic, maintenance and construction and emergency management agencies. Planned Coordinate maintenance resources for incidents with other regional maintenance providers Planned Provide maintenance of state highways within the region, including pavement maintenance and all other construction activities Planned Distribute maintenance and construction work plans and work zone information to regional traffic operators, maintenance and construction agencies, information service providers, and the media. Planned Provide maintenance resources to assist regional emergency management agencies in incident response. Planned Dispatch agency maintenance vehicles. Planned Surface Street Management City of Aztec Public Works Operate traffic signal systems on city- owned streets. Planned Provide traffic information to regional agencies, including transit, emergency management, maintenance and construction, and the media. Planned Coordinate traffic information with NMDOT(through NMRoads) and with San Juan County Traffic Management Planned ---PAGE BREAK--- Page 24 RR Area Name Stakeholder RR Description RR Status Provide traffic information reports to regional information service providers, private information service providers, and NMRoads. Planned Provide emergency signal preemption for Fire and EMS vehicles. Planned City of Bloomfield Public Works Operate traffic signal systems on city owned streets. Planned Provide traffic information reports to regional information service providers, private information service providers, and NMRoads Planned Coordinate traffic information and control with NMDOT, through NMRoads, and with San Juan County Traffic Management. Planned Provide traffic information to regional agencies, including transit, emergency management, maintenance and construction, and the media. Planned Provide emergency signal preemption for the region's fire and EMS vehicles. Planned City of Farmington Traffic Engineering Maintain signals for San Juan County and the City of Bloomfield. Existing Provide traffic information to regional agencies including transit, emergency management, maintenance and construction and the media. Existing Operate traffic signal systems on City owned streets. Planned ---PAGE BREAK--- Page 25 RR Area Name Stakeholder RR Description RR Status Coordinate traffic information and control with NMDOT, through NMRoads, and with San Juan County Traffic Management. Planned Provide traffic information reports to regional information service providers, private information service providers, and NMRoads. Planned Posting travel information, road closures, detours, and other conditions to DMS Planned NMDOT - New Mexico Department of Transportation Provide traffic information to travelers using State owned DMS Existing Coordinate traffic information with municipal and county TMCs and with other NMDOT TMCs. Planned Operate traffic signal systems on State owned roadways, including traffic signals, sensor systems, and right of way requests. Planned Operate network monitoring equipment (CCTV Cameras, field sensors, etc.) on sensor systems, and right-of-way requests. Planned Provide traffic information to regional agencies including emergency management, maintenance and construction, and the media. Planned Provide traffic information reports to NMRoads, regional information service providers, and private information service providers. Planned San Juan County Public Works Provide emergency signal preemption for fire and EMS vehicles. Planned ---PAGE BREAK--- Page 26 RR Area Name Stakeholder RR Description RR Status Provide traffic information reports to regional information service providers, private information service providers, and NMRoads. Planned Coordinate traffic information an control with municipal TMCs and NMDOT Planned Provide traffic information to regional agencies including transit, emergency management, maintenance and construction and the media. Planned Operate traffic signal systems on county owned streets Planned Transit Services Ignacio Road Runner Transit Coordinate transit service with other regional transit providers Planned Navajo Transit Coordinate transit service with other regional transit providers Planned Red Apple Transit Provide fixed route service within Farmington and to Aztec, Bloomfield, and Kirtland with connections to Navajo Transit and Ignacio Road Runner Existing Track vehicle location and evaluate schedule performance Existing Provide transit schedule and fare information to the agency's transit information center and private sector traveler information systems Planned Provide demand response transit service within Farmington, Aztec and Bloomfield Planned Provide transit security on all agency transit vehicles using silent alarms, sensors, and monitoring systems. Planned ---PAGE BREAK--- Page 27 RR Area Name Stakeholder RR Description RR Status Provide transit electronic fare payment on all agency fixed route and paratransit vehicles Planned Disseminate transit traveler information to the public through regional traveler information systems, private traveler information systems, and kiosks. Planned Traveler Information City of Aztec Public Works Provide traveler alerts to the public through the City of Aztec application. Existing Provide traffic information to the media private traveler information providers, and private travelers. Planned City of Bloomfield Public Works Provide traffic information to the media, private traveler information providers, and private travelers. Planned City of Farmington Traffic Engineering Provide traffic information to the media, private traveler information providers, and private travelers. Planned NMDOT - New Mexico Department of Transportation Coordinate and share traveler information with other traveler information providers in the region. Planned Operate NMRoads system Planned Collect traffic and maintenance and construction information from regional providers. Planned Provide broadcast information to travelers. Planned Provide traffic and maintenance and construction information to the media, private travelers, and various traveler information services (including NMRoads). Planned ---PAGE BREAK--- Page 28 RR Area Name Stakeholder RR Description RR Status Operate NMRoads system. Planned Provide traveler information to private travelers Planned Provide traveler information to the media Planned San Juan County Public Works Provide traffic information to the media, private traveler information services, and private travelers. Planned ---PAGE BREAK--- Page 29 5. Systems Inventory The Farmington Regional ITS Architecture inventory is a list of “elements” that represent all existing and planned ITS systems in the region as well as non-ITS systems that provide information to or get information from the ITS systems. These elements are owned, operated, or maintained by stakeholder agencies, companies, or groups. The focus of the inventory is on those systems that support, or may support, interfaces that cross stakeholder boundaries (e.g. public to private interfaces). The vast majority of the inventory represents ITS systems within the Farmington Region, but the inventory does contain some elements that represent systems in adjoining regions or those that are statewide in nature. An example of an element that is statewide in nature would be “NMROADS Admin”, which represents the statewide traveler information portal operated by NMDOT. The significance of having “NMROADS Admin” in the Farmington Regional ITS Architecture is because it interfaces with the “NMDOT District 5 Traffic Operations Center”, as well as other traffic management centers in the Farmington region. Each element in the inventory is described by a name, the stakeholder, a description, general status (e.g. existing or planned), and the associated or terminators from the National ITS Architecture that the elements is mapped to for modeling purposes. 5.1. Systems by Stakeholder Table 4 sorts the inventory by stakeholder so that each stakeholder can easily identify all the elements that are defined in the architecture. For each element in the inventory, the table provides an element description and an indication of whether the element exists or is planned. The list of elements sorted by stakeholder can also be found on the Farmington Regional Architecture web page by selecting the “Inventory by Stakeholder” button on the menu bar. The majority of elements in the inventory represent a specific existing or planned system. Examples of specific systems are the “Farmington Traffic Operations Center” or the “San Juan County Communications Center.” Some of the elements represent sets of devices, rather than a single specific system or device. An example of this type of element is the element “NMDOT Field Devices”, and represents all of the field devices that are, or will be, operated by NMDOT in the region, including CCTV, DMS, RWIS, and any other field devices that NMDOT may deploy. A third type of element in the inventory is a “generic” element that represents all of the systems of a certain type in the region. An example of this type of element is “Other State TMCs” which represents all traffic management centers operating in other states that may connect to traffic management centers in the Farmington region. These generic elements have been created for two primary reasons. First, they represent elements with similar types of interfaces. So, from a standardization standpoint, describing how one of the major elements in the region (e.g. the NMDOT District 5 TOC) interfaces with various public transit dispatch functions would be the same. Second, describing many systems with a single element helps keep the architecture from growing too large. ---PAGE BREAK--- Page 30 Table 4. Inventory Sorted by Stakeholder Stakeholder Element Name Element Description Status Aztec Fire Dept Aztec Fire Engines Fire, rescue, and medical emergency services Existing Aztec Police Dept Aztec PD Emergency Vehicles Police vehicles would include ITS equipment that provides the communication functions necessary to support safe and efficient emergency response. Planned Bloomfield Fire Dept Bloomfield Fire Engines Fire, rescue, and medical emergency services Existing Bloomfield Police Dept Bloomfield PD Emergency Vehicles Police vehicles would include ITS equipment that provides the communication functions necessary to support safe and efficient emergency response. Planned City of Aztec Public Works Aztec Advisory Traveler Information Systems Equipment for sending out information on road advisories, traffic alerts, and weather conditions. Planned City of Aztec Public Works Aztec Field Devices Sensors and cameras for operational and maintenance purposes Planned City of Aztec Public Works Aztec Maintenance Vehicles Aztec Maintenance vehicles have maintenance equipment and communication functions necessary to support road maintenance and construction. Existing City of Aztec Public Works Aztec Traffic Management Represents traffic management for the City of Aztec. In the future, this may become a traffic management center, capable of managing road equipment including traffic cameras, signal priority, and speed radars. Existing City of Bloomfield Public Works Bloomfield Advisory Traveler Information System Equipment for sending out information on road advisories, traffic alerts, and weather conditions. Planned City of Bloomfield Public Works Bloomfield Field Devices Sensors and cameras for operational and maintenance purposes Planned ---PAGE BREAK--- Page 31 Stakeholder Element Name Element Description Status City of Bloomfield Public Works Bloomfield Maintenance Vehicles Bloomfield Maintenance vehicles have maintenance equipment and communication functions necessary to support road maintenance and construction. Existing City of Bloomfield Public Works Bloomfield Traffic Management Manages road equipment including traffic cameras, signal priority, and speed radars to monitor and control traffic. Planned City of Farmington City of Farmington Regional Tactical Operations Centers City of Farmington Regional Tactical Operations Centers allow Farmington officials to continue operations with a direct connection to the San Juan EOC until Farmington officials have the leisure to physically move to the San Juan EOC in Aztec. Existing City of Farmington Streets Farmington Advisory Traveler Information Systems Equipment for sending out information on road advisories, traffic alerts, and weather conditions. Planned City of Farmington Streets Farmington Streets Maintenance Yard Represents the maintenance facility for the City of Farmington Planned City of Farmington Streets Farmington Streets Vehicles Streets vehicles have maintenance equipment and communication functions necessary to support road maintenance and construction. Existing City of Farmington Traffic Engineering Farmington Field Devices Sensors and cameras for operational and maintenance purposes Planned City of Farmington Traffic Engineering Farmington Traffic Operations Center Manages all traffic signals; manages all road equipment including traffic cameras, signal priority, and speed radars to monitor and control traffic. Existing Farmington Fire Dept Farmington Fire/Rescue Vehicles Fire and rescue services. Also respond to HAZMAT emergencies Existing Farmington Police Dept Farmington PD Emergency Vehicles Police vehicles would include ITS equipment that provides the communication functions necessary to support safe and efficient emergency response. Planned Ignacio Road Runner Transit Ignacio Transit Management Center Represents the Transit Management Center for Ignacio Road Runner Transit Planned ---PAGE BREAK--- Page 32 Stakeholder Element Name Element Description Status Local Transit Agencies Local Agency Traveler Information System Represents transit information systems for local transit agencies, such as Red Apple Transit or Navajo transit. These could include web sites or other sources of information dissemination. Planned Navajo Nation Navajo Nation Field Devices Represents field devices, such as traffic signals, owned and operated by the Navajo Nation. Planned Navajo Transit Navajo Transit Management Center Represents the Transit Management Center for Navajo Transit Planned New Mexico Dept of Public Safety DPS Motor Transportation Division Commercial Vehicles Commercial vehicles include ITS equipment that supports safe and efficient commercial vehicle operations. This equipment monitors vehicle operation and provides the driver and motor carrier real- time information. Existing New Mexico Dept of Public Safety Electronic Bypass Stations Represents the pre-pass system for electronic bypass of commercial vehicles Planned New Mexico Dept of Public Safety Mobile Weigh Stations Includes both weigh in motion and safety inspections for the DPS Existing New Mexico Dept of Public Safety New Mexico Statewide EOC The statewide emergency operations center located in Albuquerque. Existing New Mexico Dept of Public Safety NM DPS The district dispatch center for the NM DPS (State Police). Planned New Mexico Dept of Public Safety NM DPS Vehicles Emergency vehicles that are owned and operated by the NM DPS (State Police). Planned New Mexico Dept of Public Safety NM MTD Fixed Weigh Stations Fixed point weigh stations owned and operated by the New Mexico Motor Transportation Division Existing Newspapers, Television, Radio Stations Newspapers, Television, Radio Stations Represents local media outlets that may disseminate traveler information Existing NMDOT - New Mexico Department of Transportation NMDOT District 5 TOC The traffic operations center for NMDOT District 5. In the future, the NMDOT District 5 TOC will control all NMDOT ITS field equipment and coordinate with all other agencies. Planned NMDOT - New Mexico Department of NMDOT Field Devices Field Devices include sensors, displays, and cameras for operational purposes of maintenance and construction and for Existing ---PAGE BREAK--- Page 33 Stakeholder Element Name Element Description Status Transportation regional traveler information. NMDOT - New Mexico Department of Transportation NMDOT Maintenance Vehicles Vehicles include ITS devices that provide the sensory, processing, storage, and communications functions necessary to support highway maintenance and construction. Planned NMDOT - New Mexico Department of Transportation NMDOT Maintenance Yards Represents NMDOT maintenance yards in Shiprock, Bloomfield and Farmington Planned NMDOT - New Mexico Department of Transportation NMDOT Signal Lab The NMDOT Signal Lab manages traffic signal systems statewide that are owned and operated by NMDOT Existing NMDOT - New Mexico Department of Transportation NMDOT Statewide Crash Information System Statewide database of vehicle crash records Planned NMDOT - New Mexico Department of Transportation NMDOT Statewide TMC NMDOT Transportation Management Center located in Albuquerque. Existing NMDOT - New Mexico Department of Transportation NMDOT Statewide Transit Database NMDOT Statewide Transit Database is a repository for transit operations data. Planned NMDOT - New Mexico Department of Transportation NMROADS Admin Traveler information portal managed by NMDOT that provides static and real-time information on traffic conditions, road conditions, weather conditions, road construction information and transit related information. The website also provides access to current CCTV images and DMS signage. NMRoads has a larger role as an operating environment where info is input and output between ITS centers, even allowing device control for remote devices, creating a web-based operational system. Existing NOAA National Weather Service Service for national, regional and local weather information Existing Other State Agencies Other State TMCs Represents TMCs located in other states, such as Arizona and Colorado, for the purposes of interstate traffic coordination on Planned ---PAGE BREAK--- Page 34 Stakeholder Element Name Element Description Status highways. Private Commercial Carriers Commercial Vehicles This represents ITS equipment in privately owned commercial vehicles. Equipment could include hand held devices, such as smart phone, used to perform clearance. This classification applies to all such vehicles ranging from small panel vans used in local pick-up and delivery services to large, multi-axle tractor trailer rigs operating on long haul routes. Planned Private Commercial Carriers Fleet Management Systems Dispatch function of Commercial Vehicle Fleets Planned Private Traveler Information Systems Private Traveler Information Systems Represents third-party private traveler information systems. Planned Private Travelers Personal Computing Devices Private Travelers Personal Computing Devices Represents private travelers accessing information on personal computing devices Existing Red Apple Transit Red Apple Transit Kiosks Implement Kiosks for public informational displays supporting various levels of interaction and information access. Planned Red Apple Transit Red Apple Transit Operations Center Operations center that would coordinate bus tracking, dispatch and maintenance; disseminate transit rider information and notices to kiosks- Ride Right will be the contractor taking over in March 2015. Planned Red Apple Transit Red Apple Transit Vehicles Transit vehicles include ITS devices that support the safe and efficient movement of passengers. These systems collect, manage, and disseminate transit-related information to the driver, dispatch personnel, and transit riders. Planned Regional Hospital Providers Regional Hospitals Represents regional hospitals, such as the San Juan Regional Hospital. Existing San Juan County Communications Authority San Juan County Communications Center The County's Consolidated 911 Dispatch Center Existing ---PAGE BREAK--- Page 35 Stakeholder Element Name Element Description Status San Juan County Communications Authority San Juan County EOC The Regional EOC is located in Aztec Existing San Juan County Fire Dept San Juan County Fire Vehicles Fire, rescue, and medical emergency services Existing San Juan County Public Works San Juan County Advisory Traveler Information Equipment for sending out information on road advisories, traffic alerts, and weather conditions. Planned San Juan County Public Works San Juan County Field Devices Sensors and cameras for operational and maintenance purposes Planned San Juan County Public Works San Juan County Maintenance Vehicles County Maintenance vehicles have maintenance equipment and communication functions necessary to support road maintenance and construction. Existing San Juan County Public Works San Juan County Traffic Management Manages road equipment including traffic cameras, signal priority, and speed radars to monitor and control traffic. Planned San Juan County Sheriff Dept San Juan County Sheriffs Emergency Vehicles Emergency vehicles include ITS equipment that provides the sensory, processing, storage, and communications functions necessary to support safe and efficient emergency response. Planned San Juan Regional EMS San Juan Regional Emergency Medical Vehicles San Juan Regional Emergency Medical vehicles provide emergency medical services for all of the Farmington region. Existing Special Event Promoters Special Event Promoters Promoters and sponsors of special events. They may coordinate with traffic and emergency management agencies. Planned Vehicles Vehicles Represents vehicles on roadways Planned ---PAGE BREAK--- Page 36 5.2. Systems by Architecture Entity Each element in the Farmington Regional ITS Architecture inventory is mapped to one or more entities from the National ITS Architecture. In version 7.0 of the National ITS Architecture (on which this architecture is based) there are 98 entities defined. These 22 and 76 terminators describe a wide array of systems that provide ITS services, or interface with systems that provide ITS services. The mapping of Farmington Regional ITS Architecture elements to National ITS Architecture entities has two primary benefits. First, it allows the full set of information flows contained in the National ITS Architecture to be used in the description of Farmington Regional ITS Architecture interfaces. Secondly, it allows the elements of the Farmington Regional ITS Architecture to be grouped by like entity. A list of the elements in the Farmington Regional ITS Architecture sorted by entity can be found on the Farmington Regional Architecture web page by selecting the “Inventory by Entity” button on the left side menu bar. This list on the web page allows the users of the architecture to immediately identify all the elements that have functions relating to transit management, or traffic management, or any other or terminator defined by the National ITS Architecture. The Farmington Regional ITS Architecture inventory contains the following number of elements mapped to different types of entities:  Archived Data Management: 2  Emergency Management: 5  Information Service Providers: 9  Maintenance and Construction Management: 8  Traffic Management:9  Transit Management: 3 ---PAGE BREAK--- Page 37 6. Needs and Services 6.1. Needs Identification Transportation needs identify the transportation problems that can be solved by ITS services. They also represent a link to transportation planning efforts that define the strategies used to address transportation problems. These strategies involve capital improvements as well as operational improvements. ITS solutions usually involve services that improve the efficiency, scope, or safety of operations. The initial set of user needs described below was developed from information collected as part of the New Mexico Statewide ITS Architecture development effort and customized based upon the Farmington stakeholder meetings. Table 5 below, shows an where it was determined the regional priority was for the user need. One user need prioritization shows a specific reference to public services (“fire/EMS and police). This is done to show the prioritization difference between different public safety agencies. . Table 5. Summary of Transportation Needs/Priorities Need Area Specific ITS Need High Medium Low Not a Need Incident Management Need improved incident detection, management and coordination X Need to reduce delays due to accidents or construction X Need to identify alternate routes for the traveling public X Improve response to HAZMAT incidents. X Traffic Management Need to improve traffic congestion mitigation. X Need to improve traffic mitigation on the east-west corridors X Need to provide early warning of poor visibility conditions (dust, thunderstorms, etc.) X Need to improve traffic signal interconnect and coordination to improve mobility X Need traffic signal preemption for emergency vehicles (needs to be expanded) Fire/EMS Police Need to enhance communications and information sharing between regional agencies X ---PAGE BREAK--- Page 38 Need Area Specific ITS Need High Medium Low Not a Need Need to know travel times on major routes X Need to know delays on major routes X Need to alert drivers of speeding (automated alert systems) X Need for remote monitoring for infrastructure and at intersections X Emergency Management Need to improve emergency notification/dispatch and response times X Need to improve traffic safety X Need to expand remote traveler support services (information plus roadside assistance) X Need improved tracking of emergency vehicles X Need to identify alternate routes for emergency vehicles X Need to improve evacuation planning X Public Transportation Need to improve/enhance rural traveler service X Need to improve urban traveler service Need to improve transit coordination among city/county/tribal governments X Need better communication with transit customers X Need to encourage major employers to implement transit use incentives. Need automated maintenance system for transit fleets X Need to improve efficiency of demand- responsive transit (enhanced information) X Need to improve schedule operations for fixed-route transit vehicles X Need interactive ITS services (transit- related) X Need to deploy AVL on regional transit vehicles X Maintenance Operations Need to improve vehicle routing and detours/information X ---PAGE BREAK--- Page 39 Need Area Specific ITS Need High Medium Low Not a Need Need advanced and up-to-date road closure and construction zone information X Need to reduce delays due to accidents or construction X Need to know location of maintenance vehicles X Need to improve work zone safety (alert drivers of wrong-way movements) X Traveler Information Need real-time roadway and traffic conditions information X Need real-time information about weather conditions/location X Need easier access to traveler services information (locations, types of services, etc.) X Need special event traffic information X Information Management Need to collect transportation information for use by planners X For simplicity, the needs summary below identifies high priority needs and maps these to stakeholder groups. The seven groups whose needs were considered are:  NMDOT District 5  Public Safety (Police, Fire, EMS, Emergency Management)  Municipal (primarily traffic and public works) - City of Farmington, City of Bloomfield, City of Aztec  County (primarily traffic and public works) – San Juan County  Transit – Red Apple Transit  Planning (MPO/RPO) - Farmington MPO Table 6 provides a summary of the high priority transportation needs along with the group(s) for which these needs are high priority. Table 6. Summary of High Priority Transportation Needs Need Area Specific ITS Need Group Traffic Management Need to improve traffic signal interconnect and coordination to improve mobility NMDOT, Municipal, County Need traffic signal preemption for emergency vehicles (needs to be expanded) Fire/EMS ---PAGE BREAK--- Page 40 Need Area Specific ITS Need Group Emergency Management Need to improve emergency notification/dispatch and response times Public Safety Need to improve traffic safety NMDOT, Public Safety, Municipal, County Need improved tracking of emergency vehicles Public Safety Need to identify alternate routes for emergency vehicles Public Safety Need to improve evacuation planning Public Safety Maintenance Operations Need to improve work zone safety (alert drivers of wrong-way movements) NMDOT, Municipal, County Maintenance Operations Need to reduce delays due to accidents or construction NMDOT, Municipal, County Traveler Information Need real-time roadway and traffic conditions information NMDOT, Municipal, County Need real-time information about weather conditions/location NMDOT, Municipal, County 6.2. Services The ITS systems in the region currently provide a wide array of transportation services and that list will grow as more systems are developed or upgraded. The current and planned services can be described by the set of service packages that are shown in Table 7. This set of services is a subset of the services contained in the National ITS Architecture, and represent all of the selected services (service packages) based on information gathered at stakeholder meetings, needs assessments, and review of planning documents. Each of the service packages is currently implemented, or planned for implementation by one or more stakeholders in the region. For those services where one or more stakeholders have already implemented it, the status is set to existing. Table 7. Selected Regional Services (Service Packages) Service Package Service Package Name Service Package Status AD1 ITS Data Mart Planned APTS01 Transit Vehicle Tracking Existing APTS02 Transit Fixed-Route Operations Existing APTS03 Demand Response Transit Operations Planned ---PAGE BREAK--- Page 41 Service Package Service Package Name Service Package Status APTS05 Transit Security Planned APTS07 Multi-modal Coordination Planned APTS08 Transit Traveler Information Planned ATIS01 Broadcast Traveler Information Planned ATIS02 Interactive Traveler Information Planned ATMS01 Network Surveillance Existing ATMS02 Traffic Probe Surveillance Existing ATMS03 Traffic Signal Control Existing ATMS06 Traffic Information Dissemination Planned ATMS07 Regional Traffic Management Planned ATMS08 Traffic Incident Management System Planned ATMS12 Roadside Lighting System Control Planned ATMS19 Speed Warning and Enforcement Planned ATMS21 Roadway Closure Management Planned ATMS22 Variable Speed Limits Planned ATMS24 Dynamic Roadway Warning Planned CVO06 Weigh-In-Motion Planned CVO10 HAZMAT Management Planned CVO11 Roadside HAZMAT Security Detection and Mitigation Planned EM01 Emergency Call-Taking and Dispatch Existing EM02 Emergency Routing Existing EM06 Wide Area Alert Planned ---PAGE BREAK--- Page 42 Service Package Service Package Name Service Package Status EM07 Early Warning Systems Planned EM08 Disaster Response and Recovery Planned EM09 Evacuation and Reentry Management Planned EM10 Disaster Traveler Information Planned MC01 Maintenance and Construction Vehicle and Equipment Tracking Planned MC02 Maintenance and Construction Vehicle Maintenance Planned MC03 Road Weather Data Collection Planned MC04 Weather Information Processing and Distribution Planned MC06 Winter Maintenance Planned MC07 Roadway Maintenance and Construction Planned MC08 Work Zone Management Existing MC10 Maintenance and Construction Activity Coordination Existing Traffic Incident Management, identified as ATMS08 in the above table, is one of the key services that are planned throughout the region. Although it is technically called “Traffic Incident Management”, and identified numerically in the National ITS Architecture as ATMS08, a broader view of this service includes several service packages, including:  ATMS03 – Surface Street Control  ATMS04 – Freeway Control  ATMS06 – Information Dissemination  ATMS07 – Regional Traffic Control  ATMS08 – Traffic Incident Management  EM1 – Emergency Call-Taking and Dispatch  EM2 – Emergency Routing As indicated by Table 7 above, all of these services are identified as existing or planned for the Farmington Regional ITS Architecture. ---PAGE BREAK--- Page 43 6.3. Comparison of Needs and Services The priority needs identified in Section 6.1 will be addressed by the ITS services described in Section 6.2. Table 8 provides a mapping of the priority needs to ITS services identified in the previous section. Table 8. Mapping of Needs to Services Need Area Specific ITS Need ITS Service Addressing Need Service package Traffic Management Need traffic signal interconnect and coordination to improve mobility Surface Street Control ATMS03 Regional Traffic Control ATMS07 Need traffic signal preemption for emergency vehicles. Emergency Routing EM02 Emergency Management Need to improve emergency notification/dispatch and response times Traffic Incident Management ATMS08 Emergency Response EM01 Emergency Routing EM02 Need to improve traffic safety Network Surveillance ATMS01 Surface Street Control ATMS03 Freeway Control ATMS04 Traffic Information Dissemination ATMS06 Traffic Incident Management ATMS08 Need to expand remote traveler support services (information plus roadside assistance) Roadway Service Patrols EM04 Interactive Traveler Information ATIS02 Need improved tracking of emergency vehicles Emergency Routing EM02 Need to identify alternate routes for emergency vehicles Emergency Routing EM02 Need to improve evacuation planning Evacuation and Reentry Management EM09 Maintenance Operations Need to improve work zone safety (alert drivers of wrong-way movements) Work Zone Safety Monitoring MC09 Traveler Information Need real-time roadway and traffic conditions information Network Surveillance ATMS01 Traffic Information Dissemination ATMS06 Broadcast Traveler Information ATIS01 Need real-time information about weather conditions/location Traffic Information Dissemination ATMS06 Road Weather Data Collection MC03 ---PAGE BREAK--- Page 44 Need Area Specific ITS Need ITS Service Addressing Need Service package Weather Information Processing and Distribution MC04 ---PAGE BREAK--- Page 45 7. Interfaces and Information Exchanges 7.1. Top Level Regional System Interconnect Diagram A system interconnect diagram, or sausage diagram, shows the systems and primary interconnections in the region. The National ITS Architecture interconnect diagram has customized for the Farmington Region based on the information gathered from the ---PAGE BREAK--- Page 46 and system inventory. ---PAGE BREAK--- Page 47 ---PAGE BREAK--- Page 48 Figure 6 on the following page summarize the existing and planned ITS elements for the region in the context of a physical interconnect. Elements (and their primary associated National ITS Architecture entity) are called out in the boxes surrounding the main interconnect diagram. In the center of the figure, the rectangles represent the of the National ITS Architecture. The Farmington Regional ITS Architecture has elements that map to 16 of the 22 possible of the National ITS Architecture. In addition, the Farmington Regional ITS Architecture has elements that map to 4 terminators of the National ITS Architecture. These terminators are shown on the right side (in yellow) of the diagrams below. Terminators include entities such as Care Facilities (which maps to Regional Medical Centers). The diagram also identifies the three basic types of communications used to interconnect the elements of the architecture. These communications types are defined as:  Fixed point to fixed point Communications: A communications link serving stationary sources. It may be implemented using a variety of public or private communications networks that may physically include wireless microwave) as well as wireline infrastructure. Both dedicated and shared communications resources may be used.  Wide Area Wireless Communications: A communications link that provides communications via a wireless device between a user and an infrastructure-based system. Both broadcast (one-way) and interactive (two-way) communications services are grouped into wide-area wireless communications. These links support a range of services including real-time traveler information and various forms of fleet communications.  Dedicated Short Range Communications: A wireless communications channel used for close-proximity communications between vehicles and the immediate infrastructure. It supports location-specific communications for ITS capabilities such as toll collection, transit vehicle management, driver information, automated commercial vehicle operations, and pre-emption or priority ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 93 Figure 6. Farmington Regional ITS Architecture System Interconnect Diagram ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 96 7.2. Customized Service Packages The service packages identified in the National ITS Architecture (see Section 3) have been customized to reflect the unique systems and connections within the Farmington region, as well as connections just outside of the region (e.g. other counties). Each customized service package can be shown graphically, with the service package name, the entity from the National ITS Architecture and the specific Farmington elements associated with the entity. In addition the service packages show the information flows that are exchanged (or will be exchanged) between elements. Figure 7 is an example of an ATMS service package for Traffic Signal Control that has been customized for the City of Farmington. This service package shows the two Traffic Management and Roadway, and the associated elements. Information flows (called “architecture flows” in the National ITS Architecture) between the indicate what information is being shared. The service packages that were customized for the Farmington Regional ITS Architecture can be found on the Farmington Regional Architecture web page by selecting the “Service packages by Functional Area” button on the left side menu bar. Under the “Service package by Functional Area” tab, service packages are grouped by functional areas (e.g. Traffic Management, Maintenance and Construction, and Public Transportation). Each set of customized service packages (based on the functional area) can be viewed by clicking on the Service package Diagram icon under each area heading. It is important to note that while the service package table on the web page shows all of the service packages from the National ITS Architecture, only those selected for the region are included in the diagrams. The selected service packages on the web page also are highlighted in the web page table with bold print and are indicated as existing or planned. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 97 Figure 7. Example Customized Service Package 7.3. Regional Architecture Information Flows While it is important to identify the various systems and stakeholders as part of the Regional ITS Architecture, a primary purpose of the architecture is to identify the between transportation systems in the region. The interconnect (sausage) diagrams ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 98 previously in ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 99 ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 100 Figure 6 showed the high level relationships of the elements in the region. The service packages from the National ITS Architecture represent services that can be deployed as an integrated capability, and the customized service package diagrams show the information flows between the and terminators (elements within the region) that are most important to the operation of the service packages. How these systems interface with each other is an integral part of the overall architecture. There are 160 different elements identified as part of the Farmington Regional ITS Architecture. These elements include City, County and Regional traffic operations centers, transit centers, transit vehicles, public safety dispatch centers, media outlets, and others — essentially all of the existing and planned physical components that contribute to the region’s intelligent transportation system. Interfaces have been defined for each element in the architecture. For example, the City of Farmington Traffic Operations Center has planned interfaces with 15 other elements in the region ranging from field equipment to transit centers. Some of the interfaces are far less complex. For example the Red Apple Transit Kiosks has interfaces with only one other element in the architecture, the Red Apple Transit Operations Center. The Farmington Regional ITS Architecture defines a total of 174 interfaces from one element to another. Elements and their interfaces are accessible via the Farmington Regional ITS Architecture web page by clicking on the “ITS Inventory” button. On the web page, elements are listed alphabetically in the column on the left, and the description of each element appears on the right. By clicking on (selecting) an element, the element detail page comes up where the user can view the element definition, who the stakeholder is, the current status of the element, and the other elements with which the selected element interfaces with. Figure 8 below is an example of a portion of the element detail page for the City of Farmington Traffic Operations Center. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 101 Figure 8. Example of Element Detail With Interfaces By clicking on (selecting) an element that interfaces with the City of Farmington Traffic Operations Center, more detailed information about the particular interface is pulled up (e.g. architecture flows). Architecture flows between elements define specific information that is exchanged by the elements. Each architecture flow has a direction, name and definition. Most of the architecture flows match ones from the National ITS Architecture (the mapping of elements to National ITS Architecture entities allowed the developers to match the architecture flows to the appropriate interfaces). In some cases, new “user defined” flows have been created for interfaces or connections that are not expressed in the National ITS Architecture (NOTE: User defined flows have a “_ud” at the end of the flow name to indicate they are user defined). These architecture flows define the interface requirements between the various elements in the region. The Farmington Regional ITS Architecture defines 829 triplets (a source element, architecture flow and destination element) throughout the region. An example of architecture flows between two elements is shown in Figure 9. In this interface, the architecture flows that go between the San Juan County Communications Center and the City of Farmington Traffic Operations Center are shown. Although both of these elements are existing, the architecture flows on this interface are shown as planned (indicated by the after ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 102 each flow). This signifies that these elements do not currently share data communications (since the architecture flows are all shown as planned). Each of the individual element interfaces can be accessed on the Farmington Regional ITS Architecture web page by following the instructions listed previously. Specifically, the user can click on the “ITS Inventory” button, select the element whose interfaces they are reviewing in order to bring up the element detail page. Once on the element detail page, scrolling down to the “Interfaces” and clicking on (selecting) an interfacing element, more detailed information about the particular interface is pulled up (e.g. architecture flows). Once you have selected the interfacing element, a screen should appear that is similar to the diagram shown in Figure 9 (which shows all of associated architecture flows). Selecting any of the architecture flows will provide a definition, and any standards associated with that architecture flow are noted. Figure 9. Example of Architecture Flows Between Elements ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 103 8. Functional Requirements Functional requirements are a description of the functions or activities that are currently performed by the ITS elements or that are planned to be performed in the future. For the Farmington Regional ITS Architecture, these functions have been developed by using the functional assignments underlying the National ITS Architecture. In the National ITS Architecture, a service package is defined by equipment packages, and architecture flows, which operate together to perform a particular transportation service. Equipment Packages represent pieces of a that perform a single function. (Further descriptions of these National ITS Architecture concepts are in Section Note: there are no equipment packages defined for the Terminators of the National ITS Architecture since they represent systems on the boundary of the architecture and, therefore, do not have functional descriptions within the architecture. Hence any element mapped only to a National ITS Architecture terminator - e.g. National Weather Service - will not have functions assigned to it. To consider an example of this mapping beginning with service packages, the Surface Street Control (ATMS03) service package is composed of the three Traffic Management equipment packages, Collect Traffic Surveillance, TMC Signal Control and Traffic Equipment Maintenance, and four Roadway equipment packages, Field Management Stations Operations, Roadway Basic Surveillance, Roadway Signal Control and Roadway Equipment Coordination. The definitions of these seven equipment packages, copied from version 7 of the National ITS Architecture, are:  Collect Traffic Surveillance This equipment package remotely monitors and controls traffic sensors and surveillance CCTV) equipment, and collects, processes and stores the collected traffic data. Current traffic information and other real-time transportation information is also collected from other centers. The collected information is provided to traffic operations personnel and made available to other centers.  TMC Signal Control – This equipment package provides the capability for traffic managers to monitor and manage the traffic flow at signalized intersections. This capability includes analyzing and reducing the collected data from traffic surveillance equipment and developing and implementing control plans for signalized intersections. Control plans may be developed and implemented that coordinate signals at many intersections under the domain of a single traffic management and are responsive to traffic conditions and adapt to support incidents, preemption and priority requests, pedestrian crossing calls, etc.  Traffic Equipment Maintenance – This equipment package monitors the operational status of field equipment and detects failures. It presents field equipment status to Traffic Operations Personnel and reports failures to the Maintenance and Construction Management The equipment package tracks the repair or replacement of the failed equipment. The entire range of ITS field equipment may be monitored by this equipment package including sensors (traffic, infrastructure, environmental, security, ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 104 speed, etc.) and devices (highway advisory radio, dynamic message signs, automated roadway treatment systems, barrier and safeguard systems, cameras, traffic signals and override equipment, ramp meters, beacons, security surveillance equipment, etc.).  Field Management Stations Operations This equipment package supports direct communications between field management stations and the local field equipment under their control.  Roadway Basic Surveillance This equipment package monitors traffic conditions using fixed equipment such as loop detectors and CCTV cameras.  Roadway Signal Controls – This equipment package includes the field elements that monitor and control signalized intersections. It includes the traffic signal controllers, signal heads, detectors, and other ancillary equipment that supports traffic signal control. It also includes field masters, and equipment that supports communications with a central monitoring and/or control system, as applicable. The communications link supports upload and download of signal timings and other parameters and reporting of current intersection status. This equipment package represents the field equipment used in all levels of traffic signal control from basic actuated systems that operate on fixed timing plans through adaptive systems. It also supports all signalized intersection configurations, including those that accommodate pedestrians.  Roadway Equipment Coordination – This equipment package supports direct communications between field equipment. It includes field elements that control and send data to other field elements. This includes coordination between remote sensors and field devices Dynamic Message Signs) and coordination between the field devices themselves direct coordination between traffic controllers that are controlling adjacent intersections.). The approach used in the Farmington Regional ITS Architecture was to begin with the mapping of equipment packages to elements as an initial definition of the functions being performed by each element. Then this mapping is tailored, or customized, in the Turbo Architecture tool to provide a more accurate picture of the functions performed by each element. The Turbo Architecture tool also contains a detailed mapping of functional requirements (written as “shall” statements) to each equipment package. This mapping to functional requirements has been customized for each element, selecting only those requirements that are appropriate given the definition and connectivity of the element. In some cases the functional requirement has been customized to better reflect the functions of the element. This detailed mapping of functional requirements to elements is contained in the Turbo Architecture database and is provided in tabular form in a separate Excel file. The mapping of elements to the basic functions (equipment packages) is provided on the hyperlinked web site version of the architecture. The detail page for each element (which is accessed by clicking on the hyperlinked element name within the “ITS Inventory”, “Inventory by ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 105 Stakeholder” or “Inventory by Entity” tabs) has a list of the equipment packages assigned to the element. Sometimes the user may need to scroll down to see the equipment packages. For example, the San Juan County Communications Center element has the following equipment packages assigned to it:  Emergency Call-Taking  Emergency Dispatch  Emergency Response Management  Emergency Routing  Emergency Evacuation Support  Emergency Early Warning System  Emergency Commercial Vehicle Response A summary of the Equipment Packages mapped to each key element of the architecture is also contained in Appendix B. This represents a first level of detail that can be obtained in the hyperlinked web site in connection with functionality. The additional level of detail, or detailed functional requirements, can be accessed by clicking on any of the equipment packages associated with the element you under review. Using the above example, viewing the San Juan County Communications Center element detail page the user can see the equipment packages listed above. If the user were to select one of the equipment packages (all listed as hyperlinks), the equipment package detail page would appear. This page lists the detailed functional requirements that have been customized for the Farmington Regional ITS Architecture as well as providing a full description of what this equipment package contains and a listing of all element that are associated with this equipment package. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 106 9. Standards The following subsections provide a discussion of ITS standards potentially applicable in the region and how to identify the standards that might be applicable on a specific interface within the architecture. 9.1. Discussion of Key Standards for the Region ITS standards establish a common way in which devices connect and communicate with one another. This allows transportation agencies to implement systems that cost-effectively exchange pertinent data and accommodate equipment replacement, system upgrades, and system expansion. Standards benefit the traveling public by providing products that will function consistently and reliably throughout the region. ITS standards contribute to a safer and more efficient transportation system, facilitate regional interoperability, and promote an innovative and competitive market for transportation products and services. The use of ITS standards is very important to project development in the region. Table 9 identifies the ITS standards that are potentially applicable to the region. This table was created by taking the standards information available in the Turbo Architecture database (which identifies standards applicable to each architecture flow) and taking the total set of standards that result from all of the selected flows. The table provides the status of the standards effort as of January 2012 (the most recent update of the information). The table lists the abbreviation of Standards Development Organization (SDO) in the first column, the name of the standard in the second column and the number of the standard in the third column. Regular updates of SDO activities will help ensure that the latest standards are utilized. The SDOs involved in the development of ITS standards that are listed in the table include:  American Association of State Highway and Transportation Officials (AASHTO)  American National Standards Institute (ANSI)  American Public Transportation Association (APTA)  American Society for Testing and Materials (ASTM)  Institute of Electrical and Electronics Engineers (IEEE)  Institute of Transportation Engineers (ITE)  National Equipment Manufacturers Association (NEMA)  Society of Automotive Engineers (SAE) Table 9. Applicable ITS Standards SDO Standard Title Document ID AASHTO/ITE Traffic Management Data Dictionary (TMDD) and Message Sets for External Traffic Management Center ITE TMDD ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 107 SDO Standard Title Document ID Communications (MS/ETMCC) AASHTO/ITE/NEMA Data Element Definitions for Transportation Sensor Systems (TSS) NTCIP 1209 AASHTO/ITE/NEMA Field Management Stations (FMS) - Part 1: Object Definitions for Signal System Masters NTCIP 1210 AASHTO/ITE/NEMA Global Object Definitions NTCIP 1201 AASHTO/ITE/NEMA NTCIP Center-to-Center Standards Group NTCIP C2C AASHTO/ITE/NEMA NTCIP Center-to-Field Standards Group NTCIP C2F AASHTO/ITE/NEMA Object Definitions for Actuated Traffic Signal Controller (ASC) Units NTCIP 1202 AASHTO/ITE/NEMA Object Definitions for Closed Circuit Television (CCTV) Camera Control NTCIP 1205 AASHTO/ITE/NEMA Object Definitions for Closed Circuit Television (CCTV) Switching NTCIP 1208 AASHTO/ITE/NEMA Object Definitions for Conflict Monitor Units (CMU) NTCIP 1214 AASHTO/ITE/NEMA Object Definitions for Data Collection and Monitoring (DCM) Devices NTCIP 1206 AASHTO/ITE/NEMA Object Definitions for Dynamic Message Signs (DMS) NTCIP 1203 AASHTO/ITE/NEMA Object Definitions for Electrical and Lighting Management Systems (ELMS) NTCIP 1213 AASHTO/ITE/NEMA Object Definitions for Environmental Sensor Stations (ESS) NTCIP 1204 AASHTO/ITE/NEMA Object Definitions for Signal Control and Prioritization (SCP) NTCIP 1211 APTA Standard for Transit Communications Interface Profiles APTA TCIP-S- 001 3.0.4 ASTM Dedicated Short Range Communication at 915 MHz Standards Group DSRC 915MHz ASTM Standard Practice for Metadata to Support Archived Data Management Systems ASTM E2468- 05 ASTM/IEEE/SAE Dedicated Short Range Communication at 5.9 GHz Standards Group DSRC 5GHz IEEE Incident Management Standards Group IEEE IM IEEE Standard for Message Sets for Vehicle/Roadside Communications IEEE 1455- 1999 SAE Advanced Traveler Information Systems (ATIS) Bandwidth Limited Standards Group ATIS Low Bandwidth SAE Advanced Traveler Information Systems (ATIS) General Use Standards Group ATIS General Use SAE Dedicated Short Range Communications (DSRC) Message Set Dictionary SAE J2735 ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 108 NTCIP C2F: NTCIP Center-to-Field Standards Group Table 9 above specifies the NTCIP Center-to-Field (NTCIP C2F) Group of Standards, which addresses the communications protocols between a center and the ITS field devices it manages. The family includes the communications profiles that cover the interfaces between a traffic management center and dynamic message signs, ramp meters, environmental sensors, or under its control. These protocols are common across all Center-to-Field interfaces in the National ITS Architecture, and rather than repeat the entire list for each architecture flow, we have created this summary entry – the NTCIP C2F Group of communications standards. The “vocabulary” (objects) is specific to the actual architecture flow in the National ITS Architecture and is therefore mapped to the corresponding Data Object standard. (In the example above, the “Object Definitions for Dynamic Message Signs” standard would be mapped to the specific control and data flows between the Traffic Management and the Roadway DMS equipment). In order to satisfy a wide spectrum of system and regional communications requirements, Center-to-Field ITS deployments should each implement the combinations of the following NTCIP C2F communications protocols that best meet their needs. This Group includes the following Standards Activities:  NTCIP 1102: Base Standard: Octet Encoding Rules (OER)  NTCIP 1103: Simple Transportation Management Protocol (STMP)  NTCIP 2101: Point to Multi-Point Protocol Using RS-232 Subnetwork Profile  NTCIP 2102: Subnet Profile for PMPP Over FSK modems  NTCIP 2103: Subnet Profile for Point-to-Point Protocol using RS 232  NTCIP 2104: Subnet Profile for Ethernet  NTCIP 2201: Transportation Transport Profile  NTCIP 2202: Internet (TCP/IP and UDP/IP) Transport Profile  NTCIP 2301: Application Profile for Simple Transportation Management Framework (STMF)  NTCIP 2302: Application Profile for Trivial File Transfer Protocol  NTCIP 2303: Application Profile for File Transfer Protocol (FTP) NTCIP C2C: NTCIP Center-to-Center Standards Group Table 9 above specifies the NTCIP Center-to-Center (NTCIP C2C) Group of Standards, which address the communications protocols between two centers (e.g. two traffic management centers exchanging information to facilitate regional coordination of traffic signals). Some of the communication protocols covered by this family are CORBA, DATEX-ASN and FTP. These protocols are common across all Center-to-Center interfaces in the National ITS Architecture, ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 109 and rather than repeat the entire list for each architecture flow, we have created this summary entry – the NTCIP C2C Group of communications standards. The standards that describe the “vocabulary” (data elements and messages) are mapped to specific architecture flows rather than the entire set of NTCIP C2C interfaces. In the regional traffic coordination example above, the “Traffic Management Data Dictionary” and the “Message Set for External TMC Communications” standards would be mapped to the specific flows between two Traffic Management In order to satisfy a wide spectrum of system and regional communications requirements, Center-to-Center ITS deployments should each implement the combinations of the following NTCIP C2C communications protocols that best meet their needs. This Group includes the following Standards Activities:  NTCIP 1102: Base Standard: Octet Encoding Rules (OER)  NTCIP 1104: Center-to-Center Naming Convention Specification  NTCIP 2104: Subnet Profile for Ethernet  NTCIP 2202: Internet (TCP/IP and UDP/IP) Transport Profile  NTCIP 2303: Application Profile for File Transfer Protocol (FTP)  NTCIP 2304: Application Profile for Data Exchange ASN.1 (DATEX)  NTCIP 2306: Application Profiles for XML Message Encoding and Transport in ITS Center to Center Communications 9.2. Reference to the Detailed Standards information on the Web Site The previous section provides a general discussion of the standards environment in the region. However the architecture does contain a far more detailed standards view, one that maps applicable standards to the individual information flows that goes from one element to another. This detailed information is contained in the hyperlinked web site and can be accessed through the links to the architecture flows shown as part of each interface. Each element description page has a set of links that describe the information flowing to and from the element to other elements of the architecture. Selecting any of these interface links brings the user an interface page. For example, the interface between the City of Farmington Traffic Operations Center and the City of Farmington Field Equipment is shown in Figure 10. There are ten information flows going to the Field Equipment element and nine coming back from it. Selecting one of the flows provides information regarding the flow and gives a list of ITS standards that are applicable to the flow. An example, for the roadway information system data flow, is shown in Figure 11. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 110 Figure 10. Example of Interface ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 111 Figure 11. Example of Standards Mapping Page ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 112 10. Project Sequencing The incorporation of the Farmington Regional ITS Architecture into the planning process will ultimately yield projects that are linked to the ITS architecture. Through the deployment of projects produced from the planning process, the services supported in the Farmington Regional ITS Architecture have been and will continue to be implemented and made a reality in the transportation system. Project implementation completes the evolution from: transportation needs to services, to functional descriptions in the regional ITS architecture, to project identification in the planning process and to project definition and deployment. The overarching goal of the Farmington Regional ITS Architecture development process is that this evolution takes place with the maximum amount of integration knowledge possible, so as to efficiently and economically implement the ITS systems required to serve the transportation community and users. Key to this process or evolution is to understand what dependencies or relationships exist between systems and projects so that an order can be identified for deployment. Given the importance of integration of ITS, and the dependencies of one system on another or one project on another, it is critical to view the entire transportation system at a high functional level. The Farmington Regional ITS Architecture provides this view point and aids in understanding the relationships between the ITS systems in the region. Project sequencing defines the order in which ITS projects should be implemented. A good sequence is based on a combination of transportation planning factors that are used to prioritize projects and the project dependencies that show how successive ITS projects can build on one another. In most cases, the first projects in the project sequence will already be programmed and will simply be extracted from existing transportation plans. Successive projects will then be added to the sequence based on the project dependencies and other planning factors (e.g. stakeholder priorities). 10.1. Process For Selecting Projects Projects were developed via interviews with key stakeholders, from existing project documentation, such as the regional Transportation Improvement Program (TIP), and from input from attendees at the Stakeholder Workshop. The Farmington Regional ITS Architecture has been updated based on the needs for the region over the next 20 years. This ITS architecture identifies which systems (operated by agencies in the Farmington MPO region or adjacent to the Farmington MPO region) should be interfaced to maximize integration opportunities throughout the region. Based on the existing and future needs throughout the State and, more specifically, the Farmington MPO, the first step of the process was to identify existing or future deployment opportunities. To better identify these opportunities, reviewed the regional planning documents supplied by the Farmington Regional ITS Architecture stakeholders or located on the stakeholders’ websites. Table 10 notes the sources that were consulted in order to develop the final list of projects: ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 113 Table 10. List of Sources Used for Identifying Projects No. Title 1 2014 - 2019 Transportation Improvement Program (TIP) for the Farmington Metropolitan Planning Organization 2 Strategic ITS Plan for the State of New Mexico V2- September 30, 2012 3 Stakeholder Outreach Meeting - 2/10/2015 4 Individual Stakeholder Meetings (face-to-face, telephone, electronic mail) 5 Generated by the Architecture Development Team These project documents and other inputs detailed many projects and programs scheduled to be implemented over a period of 1-20 years, with an emphasis on the next 3 years. Although it is important for all of these documents to identify the ITS needs and priorities for specific stakeholders, ITS projects must be included in a regional TIP to receive federal funding. The TIP provides a mechanism for locally elected officials, Farmington MPO member agencies, and staff to review the region’s capital programming. It represents a consensus among major transportation interests in the region as to what improvements should have priority for available funds. Some of the ITS projects identified by this process were included in the current 2014- 2019Farmington MPO TIP. Therefore, they had a funding allocation (estimated cost) assigned to them. These ITS projects were compared to the Statewide TIP (and other supporting documents) to determine if the proposed ITS project had an existing funding source. If a TIP’s description was similar to that of the STIP, the projects were combined and the STIP information (regarding funding) was used. In most cases, the funding source is some source of federal funds that are to be matched (by proportion – e.g. 80% federal and 20% local/state). These projects are documented in the initial ITS project table. There were also TIP (and STIP) projects that did not identify ITS in the project description, but were viewed as potentially having an ITS component (e.g. signal coordination or signal preemption for an intersection improvement). In this situation, stakeholders were asked to provide feedback regarding the likelihood of ITS being incidental to the TIP project. Where appropriate, TIP and STIP projects have been included as having ITS components (e.g. signals, DMS, CCTV, etc.) within their project description. In the case where it was unclear if ITS elements were to be included in a construction project, the project was left in the table as a place holder for a potential ITS application. Projects that were determined to have no ITS components in their project description were removed from the initial ITS project list. Additionally, a few general projects were documented as a placeholder for all of the ITS projects that are currently ongoing or are in the planning process (for NMDOT). The second step in the process (after identifying which projects were ITS related) was to obtain stakeholder feedback on the proposed ITS projects and their prioritization. Input from stakeholders was used and later refined to establish which projects were allocated to the short ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 114 term (0-5 years), medium term (6-10 years), and long term (over 10 years). Obtaining stakeholder feedback was necessary for the following reasons:  Ensure the ITS Project was consistent with stakeholder needs.  Establish an estimated timeline or priority for ITS Project deployment and denoting a general order for project implementation.  Understand the relationship and traceability between ITS projects and the Farmington Regional ITS Architecture (through customized service package prioritization). Projects listed as part of the regional TIP process, or by the STIP, were identified as short term projects based on the implied relatively short timeframe of the related TIP. A majority of this process was accomplished throughout stakeholder workshop and individual discussions on the project level. During the architecture review workshop held in February 2015, a draft list of projects was presented and input from the stakeholders was incorporated into the project list. During the workshop, comments were received from stakeholders regarding ITS project names, timeframes, funding sources, responsible agencies and programmed projects. In addition, stakeholders were able to identify additional sources where the could find ITS projects that have been planned for the region. The results of the workshop, various stakeholder inputs after the workshop, and the project sequencing analysis are provided in Table 11. The information included in each of the project functional areas is as follows:  ID. The ID number associated with this project.  Project Name. The name of the proposed ITS project.  Location. The location of the proposed project.  Description. The description of the project or services to be provided.  Lead Agency. The primary agency or stakeholder responsible for the initiation, implementation, and maintenance of the ITS project and its components  Service packages. Maps the proposed ITS project to a transportation service (customized service package) identified in the Farmington Regional ITS Architecture, which reflects traceability from ITS project to the Farmington Regional ITS Architecture. It is important to note that if there are one or more customized service packages listed in this column then it is included as part of the regional ITS architecture.  Priority. Indicates the estimated timeframe for an ITS project to be deployed. It is estimated that short-term projects will be implemented in 0-5 years; medium-term projects will be implemented in 5-10 years; and long-term projects will be implemented in over 10 years.  Source. Indicates the source of the project – for example, whether it was identified through an interview or a document. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 115 Table 11. Farmington ITS Projects ID Project Name Location Description Lead Agency Service Package Priority Source 1 NMDOT RWIS This project, which focuses mainly on bridge construction, includes installing a RWIS to measure bridge surface conditions. The RWIS would be connected to a DMS to advise motorists about unsafe pavement conditions. NMDOT ATMS06-1, MC03-1 Short Interview 2 Interstate Coordination Statewide This project would tie in NMDOT District 5 TOC to Colorado and Arizona regional or statewide systems to coordinate on highways near state borders, including 550, 170, and 491. This project would also involve deploying additional DMS and coordinating DMS with other states to redirect traffic when passes or roads going to other states are closed. NMDOT ATMS07-2, ATMS06-1 Medium Interview 3 NMDOT CCTV 550 & 516 This project would deploy CCTV on 550 north of Aztec and on 516. NMDOT ATMS01-4 Short Interview 5 City of Bloomfield Fiber Expansion Citywide This project would expand the fiber network in the City of Bloomfield City of Bloomfield ATMS03-2 Medium Interview 6 City of Bloomfield Signal System Upgrade Citywide This project would upgrade the traffic signal system in the City of Bloomfield City of Bloomfield ATMS03-2 Medium Interview 7 City of Bloomfield Riverwalk City of Bloomfield Riverwalk The City of Bloomfield Riverwalk will create a new retail center in Bloomfield. As part of this project, a new traffic signal will be installed, as well as CCTV City of Bloomfield ATMS01-2, ATMS03-2 Short Interview 8 City of Bloomfield Flasher City of This project will install flasher signals in the City of City of ATMS19-1 Short Interview ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 116 ID Project Name Location Description Lead Agency Service Package Priority Source Signals Bloomfield Bloomfield, which will flash if a vehicle goes too fast. Bloomfield 9 City of Bloomfield and NMRoads Coordination City of Bloomfield This project will connect the City of Bloomfield with NMRoads City of Bloomfield ATMS07-1 Medium Interview 10 City of Farmington CCTV expansion City of Farmington This project will expand CCTV, which are currently deployed only for signals, for monitoring roadways in the City of Farmington City of Farmington Traffic Engineering ATMS01-3 Short Interview 11 Regional Signal System Coordination Countywide This project would allow the City of Farmington to remotely connect with City of Bloomfield and San Juan County signal systems City of Farmington Traffic Engineering ATMS03-3 Short Interview 12 City of Farmington Signal Upgrade Citywide This project would upgrade the City of Farmington signal system to a Centrax system City of Farmington Traffic Engineering ATMS03-3 Short Interview 13 City of Farmington RWIS Citywide This project would deploy an RWIS system and connect it to both the City of Farmington Street and The City of Farmington Traffic Engineering City of Farmington Streets MC03-2 Short Interview 14 City of Farmington Communications System Upgrade Citywide This project would upgrade the City of Farmington communications system and add microwave and video sensors to the network City of Farmington Traffic Engineering ATMS01-3 Medium Interview 15 City of Farmington Operations Center Upgrade City of Farmington Operations Center This project would upgrade the City of Farmington Operations Center City of Farmington Traffic Engineering ATMS01-3, ATMS03-3, ATMS07-1 Medium Interview 16 City of Farmington Signal Preemption Upgrade Citywide This project would upgrade the signal preemption capabilities in the City of Farmington. This would modernize emergency signal preemption in the City of Farmington and allow the Operations City of Farmington Traffic Engineering ATMS03-3, EM02-4, EM02-5 Medium Interview ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 117 ID Project Name Location Description Lead Agency Service Package Priority Source Center to adjust signal timing. 17 City of Aztec Signal Maintenance Citywide This project would create an operational agreement to allow the City of Farmington to monitor and maintain the signal system for the City of Aztec. City of Farmington Traffic Engineering ATMS03-3 Medium Interview 18 City of Farmington Signal System Power Upgrade Citywide This project would add Uninterruptible Power Supply (UPS) to City of Farmington traffic signals City of Farmington Traffic Engineering ATMS03-3 Medium Interview 19 Navajo Nation Tribal Traffic Signals Maintenance Navajo Nation This project would create an operational agreement to allow the City of Farmington to monitor and maintain the signal system for the Navajo Nation. City of Farmington Traffic Engineering ATMS03-3 Medium Interview 20 City of Farmington Roadway Lighting Citywide This project would upgrade the roadway lighting system for the City of Farmington. This would include installing LED street lights to provide power savings, and provide remote monitoring of the lighting system from the City of Farmington Operations Center City of Farmington Traffic Engineering ATMS12-1 Medium Interview 21 City of Farmington Signal Timing Upgrades Citywide This project would upgrade the City of Farmington traffic signal timing City of Farmington Traffic Engineering ATMS03-3 Medium Interview 22 City of Farmington Traffic Counting Citywide This project would upgrade traffic signal controllers to monitor detections and give turning movement counts, as well as timing counts to allow capacity analysis City of Farmington Traffic Engineering ATMS03-3 Medium Interview 23 E Pinion Hills Blvd E Pinion Hills Blvd from NM 516 to Hubbard Full rebuild of the intersection of Pinion Hills and NM 516, including signalization upgrades City of Farmington Traffic Engineering ATMS03-3 Short FFY2014- 2019 TIP ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 118 ID Project Name Location Description Lead Agency Service Package Priority Source 24 Arterial Route to Bloomfield Phase 1 US 550/NM 173 and NM 173 to 1 mile East of US 550 Install traffic signal at intersection City of Aztec ATMS03-1 Short FFY2014- 2019 TIP Unfunded Project List 25 NMDOT DMS Expansion Regionwide This project would install additional DMS at US 550, US 64, and NM 170 NMDOT ATMS06-1 Medium NMDOT D5 ITS Needs 26 San Juan County Communications Authority Communications Upgrade San Juan County The San Juan County Communications Authority communications upgrade will upgrade the computer aided dispatch (CAD) system for San Juan County, allowing the Comm Authority to automatically dispatch police and fire vehicles in the region. San Juan County Communicati ons Authority EM01-1, EM01-3, ATMS08-4, ATMS08-6 Short Interview 27 Farmington Fire Department CCTV City of Farmington This project would install CCTV on command and fire vehicles. The live video feed would be viewable at the San Juan County Communications Center Farmington Fire Department ATMS08-6 Short Interview 28 Arterial Route to Bloomfield Phase 2 City of Aztec This project will install CCTV on the new arterial running from Aztec to Bloomfield City of Aztec ATMS01-1 Short Workshop 29 San Juan EMS AVL and GIS Upgrade San Juan EMS This project will upgrade the San Juan EMS GIS and AVL systems. It would also allow EMS vehicles to transit medical information back to the hospital. San Juan County EMS EM01-1, EM02-12, EM02-13, EM02-14 Short Workshop 30 Tablets on Buses Regionwide This project will install tablets on fixed route buses to provide communications from dispatch to drivers. Red Apple Transit APTS02-1 Short Interview 31 Regional Transit Information Regionwide This project would provide transit information onto Google Transit Red Apple Transit APTS08-1 Short Interview ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 119 ID Project Name Location Description Lead Agency Service Package Priority Source 32 Coordination with Navajo Transit Regionwide The project would create a link with Navajo Transit to provide coordination between the transit agencies. Red Apple Transit APTS07-1 Medium Interview 33 Coordination with Ignacio Transit Regionwide The project would create a link with Ignacio Transit to provide coordination between the transit agencies. Red Apple Transit APTS07-1 Medium Interview ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 120 10.2. How to Use the Recommended Project Sequencing The recommended ITS project sequencing (Table 11 above) should be used as an input for the Transportation Improvement Plan (TIP) and Long Range Transportation Plan (LRTP) for Farmington MPO and the Strategic/Long Range Plan for other organizations for planning purposes (as described in Section 12). The planning process allocates ITS projects funding in coordination with other transportation projects. As displayed in Table 11, projects are classified as short/medium/long-term timeframes. These projects should be represented in the regional transportation plans, either the TIP, MTP. . As these sequenced projects go through the planning process, the ones identified as short-term would be transitioned in the TIP and/or local Capital Improvement Plans. Since the table defines a short-term project as being deployed in 0-5 years and the TIP defines a project as being deployed in 1-4 years, stakeholders are required to further examine the short-term projects and determine which should be represented in the TIP. The key question stakeholders may ask is, “Now that we have a comprehensive list of ITS projects separated by timeframes, how do I use the projects to address the needs described in Section 6.1. To answer this question, stakeholders should focus on the following concepts:  Why is this Important. Stakeholders should remember the reasons for going through the process of creating sequenced ITS projects. Ultimately they want to deploy projects that support the needs expressed in their ITS Architecture.  Who’s in Charge. Stakeholders should consider identifying a person or group that is responsible for managing how ITS Projects get deployed. This person or group would be aware of the big picture by familiarizing themselves with all of the planned activities and ensure integration opportunities are maximized in project deployments.  Systematic Process. Stakeholders should ensure that projects are managed in a systematic manner.  Funding Allocation. Stakeholders should ensure funding is allocated appropriately to support projects that have dependencies or synergies to be utilized. This is important if there are future projects that will depend on a short term or current project. The short term or current project must be funded appropriately to support the accommodation of known future project features or interfaces, thus avoiding redesign for future project accommodation.  Project List Management. Stakeholders should prioritize projects within their common timeframes based on the aforementioned concepts. It is important for short-term projects to be reviewed by stakeholders prior to being transitioned into the TIP. A member of the ITS Subcommittee, or a group of members, should be responsible for removing projects from the regional list once implemented. Although project lists may reflect a single project, projects are typically broken into multiple phases and are implemented in an incremental manner. For example, many ITS projects are partially deployed as part of larger construction projects. A project’s scope might involve interfacing with ten agencies and funding constraints may require agencies to be ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 121 interconnected one at a time. In this situation, a project might by implemented in five years, if two agencies are being interconnected per year. If a project is partially implemented due to unforeseen circumstances (e.g. limited funding received), then the list manager should update the project to reflect the remaining components that need to be implemented. The key point for project list management is projects will be implemented in an incremental manner, therefore the members of the ITS Subcommittee designated as the list manager(s) should keep accurate records of the incremental process and meet with stakeholders to determine how funding should be reallocated.  Desired Outcome. Stakeholders should remember the desired outcome, which is to deploy projects to maximize integration opportunities throughout the Farmington. Therefore, when projects are transitioned into the project development phase, stakeholders should always be aware of other project deployment activities (even if the other activities require a project to be deployed at a different time). This mindset will require stakeholders to be flexible in developing interfaces what will allow for future expansion based on overall regional needs. An important issue to remember is when a project it to be implemented, stakeholders should convene to determine the specific details for deploying a project (e.g. how many phases will be required for this project and which components of service packages are allocated to a particular phase?). Table 11 should be used as a guide in which agencies/systems and interfaces consider during the discussion and design phase of project implementation. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 122 11. Agreements There are several types of arrangements associated with the interfaces included when deploying ITS projects within the region. The identification of institutional agreements required is crucial to the development of consensus architecture. This section documents the agreements associated with the Farmington Regional ITS Architecture, whether existing or planned. 11.1. Types of Agreements There are several types of arrangements associated with the interfaces included when deploying ITS projects within the Farmington region. Data exchanges between systems require agreements on the transmission protocol and data formats to ensure compatibility. Coordinating field device operations owned by different agencies requires defined procedures for submitting message requests and rules governing when such requests can be honored. Such coordination can be done with informal arrangements such as a Memorandum of Understanding (MOU). Sharing control of field devices operated by different agencies, on the other hand, involves more liability issues, which requires more formal agreements. Coordinated incident response may also require formal agreements, but also requires group training of personnel from various agencies. While all interfaces involve agreements for data compatibility, agreements for procedure and operation as well as training can also be critical elements to optimizing the benefits of the architecture. Table 12 identifies types of potential agreements that could be used by agencies in the region. . It is recognized, however, that a specific agreement mechanism used among stakeholders may be different between them (for example the nature and limitations associated with a MOU might vary between stakeholders). This should be taken into consideration when identifying and pursuing the proper agreement mechanism. Table 12. Types of Institutional Agreements Type of Agreement Description Handshake Agreement Early agreement between one or more partners Not recommended for long term operations. Memorandum of Understanding Initial agreement used to provide minimal detail and usually demonstrating a general consensus. Used to expand a more detailed agreement like an Interagency Agreement which may be broad in scope but contains all of the standard contract clauses required by a specific agency. May serve as a means to modify a much broader Master Funding Agreement, allowing the master agreement to cover various ITS projects throughout the region and the MOUs to specify the scope and differences between the projects. Interagency Agreement Between public agencies transit authorities, cities, counties, etc.) for operations, services or funding Documents responsibility, functions and liability, at a minimum. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 123 Type of Agreement Description Intergovernmental Agreement Between governmental agencies Agreements between universities and State DOT, MPOs and State DOT, etc.) Operational Agreement Between any agency involved in funding, operating, maintaining or using the right-of- way of another public or private agency. Identifies respective responsibilities for all activities associated with shared systems being operated and/or maintained. Funding Agreement Documents the funding arrangements for ITS projects (and other projects) Includes at a minimum standard funding clauses, detailed scope, services to be performed, detailed project budgets, etc. Master Agreements Standard contract and/or legal verbiage for a specific agency and serving as a master agreement by which all business is done. These agreements can be found in the legal department of many public agencies. Allows states, cities, transit agencies, and other public agencies that do business with the same agencies over and over cities and counties) to have one Master Agreement that uses smaller agreements MOUs, Scope-of-Work and Budget Modifications, Funding Agreements, Project Agreements, etc.) to modify or expand the boundaries of the larger agreement to include more specific language. In addition to the agreements noted above, one element that must be considered is data ownership. The type of agreement used to address this issue may vary depending upon agencies involved. 11.2. Existing Agreements The identification of institutional agreements, along with if these agreements exist or need to be formulated, is a key output of this effort and should be updated periodically as part of the overall Regional ITS Architecture. During the original stakeholder workshops held in Farmington, to create Version 1 of the architecture stakeholders identified a variety of agreements that currently exist in the region. This list was updated at the stakeholder meeting for the development of Version 2 of the architecture. In addition, the idea of formulating additional institutional agreements was discussed in great detail. From these meetings, and additional discussions with stakeholders who were unable to attend the workshops, a list of existing agreements throughout the Farmington Region was compiled. It is represented in Table 13 below. Table 13. Existing Institutional Agreements Agencies Type of Agreement Reason City of Farmington San Juan County Operational Agreement The City of Farmington provides maintenance to ITS field equipment. City Of Farmington Northern Edge Navajo Casino Operational Agreement This agreement states that the City of Farmington will provide fire department service for the Northern Edge Navajo Casino San Juan County Red Apple Transit Operational Agreement Red Apple Transit will assist in countywide emergency evacuation during countywide emergency response. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 124 11.3. Potential Agreements For each customized service package developed in the architecture, potential institutional agreements can be identified. Agreements are identified on the basis of information being shared across institutional boundaries. Instances that involve the sharing of information wholly within one institution do not require an agreement. For example, Figure 12 illustrates transit fixed route operations for the Red Apple Transit. Taking a look at the “right” side of the diagram, the Red Apple Transit Operations Center is sharing information with the Red Apple Transit Vehicles. Since the Red Apple dispatch system is sharing information to the Red Apple Transit Vehicles, no institutional agreements are necessary because the sharing of information is between elements under the same institutional entity. Taking a look at the “left” side of the diagram yields a different institutional relationship. The Red Apple Transit Operations Center is collecting road network conditions, traffic images, and incident information about the roadways managed by the City of Farmington. Since the Red Apple Transit Operations Center is receiving information from other agency traffic operations centers, institutional agreements may be necessary. Simply put, the City of Farmington (City of Farmington Traffic Operations Center agree to share road network conditions, traffic images and incident information with Red Apple Transit. The same application of this theory would also apply to information service providers as identified in the figure. Also, this particular example shows a unidirectional flow of information, but it is quite common for there to be information going in both directions that would be subject to an agreement. Figure 12. Example Service Package: APTS02 - Transit Fixed Route Operations for Red Apple Transit Each service package identified in the Farmington Regional ITS Architecture and selected as a “high priority service package” was analyzed using the same methodology as described above. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 125 Table 14 documents the results of this analysis and identifies where institutional agreements are needed and what the purpose of the agreement are (i.e. the information that is being shared that would require an agreement). The table is sorted by “Priority Service”, or the transportation service where the agreement has been identified. The “Potential Parties to Agreement” identified the institutional entities that might share information, generally starting with the “source” entity or entities. The “Purpose” column gives a short description of the information being shared. It is important to note that the entities listed in the following table have not been identified in this table as a source or destination for the information being shared, nor does this table contain the status of any institutional agreements. This table is intended to identify the possible agreements between entities. Therefore, this table should be used as a starting point when identifying or pursuing agreements between entities. Table 14. Potential Institutional Agreements Priority Service Potential Parties to Agreement Purpose Emergency Management NMDOT, San Juan County Communications Authority, San Juan Regional EMS, Farmington Fire Department, Aztec Fire Department, Bloomfield Fire Department, New Mexico Dept. of Public Safety Coordinating incident response San Juan County Communications Authority, San Juan Regional EMS, Regional Hospital Providers. Coordinate patient and care facility status, provide care facility status City of Farmington and San Juan County Communications Authority Provide signal preemption City of Bloomington and San Juan County Communications Authority Provide signal preemption City of Aztec and San Juan County Communications Authority Provide signal preemption New Mexico Dept. of Public Safety, Regional Public Safety Agencies, Regional Transit Agencies, Regional Traffic Agencies and NMDOT Provide Amber Alert information NMDOT, San Juan County Communications Authority, , City of Farmington, City of Bloomfield, City of Aztec, Provide early warning information. NMDOT, San Juan County Communications Authority, , City of Farmington, City of Bloomfield, City of Aztec, Coordinating emergency plans for disasters NMDOT, San Juan County Communications Authority, City of Farmington, City of Bloomfield, City of Aztec, Coordinating emergency plans for disasters, evacuations and reentry NMDOT, San Juan County Communications Authority, , City of Farmington, City of Bloomfield, City of Aztec, Red Apple Transit Coordinate transit emergency plans for evacuations and reentry Traffic Incident Management NMDOT, San Juan County Communications Authority, , City of Farmington, City of Bloomfield, City of Aztec Sharing incident data and emergency resources ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 126 Priority Service Potential Parties to Agreement Purpose NMDOT, San Juan County Communications Authority, , City of Farmington, City of Bloomfield, City of Aztec, Special Event Promoters Sharing event plans San Juan County Communications Authority, City of Farmington Streets Sharing incident data and coordinating maintenance and construction resources Traffic Management NMDOT, City of Farmington, City of Bloomfield, City of Aztec, San Juan Sharing road network conditions NMDOT and the Media Sharing traveler information City of Farmington and the Media Sharing traveler information NMDOT and Other State TMCs Sharing Traveler Information Transit Management Red Apple Transit, City of Farmington Sharing road network conditions Red Apple Transit, Private Traveler Information Systems Sharing transit schedule and fare information NMDOT, Red Apple Transit Sharing transit schedule and fare information Red Apple Transit and San Juan County Communications Authority Sharing transit emergency data Red Apple Transit, Ignacio Transit, Navajo Transit Transit service coordination Maintenance and Construction Management NMDOT, City of Aztec, City of Farmington, City of Bloomfield, San Juan County, San Juan Communications Authority, Red Apple Transit Share road weather information NMDOT, City of Farmington, San Juan County, City of Aztec, City of Bloomfield Coordinate maintenance and construction work plans NMDOT, City of Aztec, City of Farmington, City of Bloomfield, San Juan County, San Juan Communications Authority Provide maintenance and construction work plans and current asset restrictions ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 127 12. Using the Farmington Regional ITS Architecture The Farmington Regional ITS Architecture has been created, in part, to be used as a key reference in the transportation planning process. This will ensure all proposed ITS projects are consistent with the regional ITS architecture and additional integration opportunities are considered, leading to more efficient implementations. Planning processes are used to identify projects whose implementation will respond to regional needs. These projects are placed in programming documents such as a Transportation Improvement Program (TIP) in order to secure funding for the projects. Once funded, the projects are implemented. The regional ITS architecture supports all three of these major steps – planning, programming, and implementation. An important aspect of developing an ITS Architecture is establishing an approach to using it. An ITS Architecture provides guidance for planning ITS projects within a region. It also provides information that can be used in the initial stages of project definition and development. This section presents the approach for integrating the ITS Architecture that has been updated for Farmington into the transportation planning/programming process and leveraging the ITS Architecture for project definition. The approach facilitates and provides a mechanism for the projects identified in this document or on the website to be planned and deployed in an orderly and integrated fashion. The primary objective of the ITS Architecture is integration. The integration of transportation systems to share information and coordinate activities provides significant benefits over the operation of systems in a stovepiped fashion. The Farmington Regional ITS Architecture illustrates the information to be exchanged between transportation systems to meet the transportation needs of the stakeholders in the region (addressed in Section 6.1). The ITS Architecture links the needs to ITS services and then to the ITS projects that address them. The ITS Architecture was developed with these objectives in mind through the definition of ITS services or service packages. By defining the ITS Architecture with services that address the needs, projects can be defined through the planning process using the architecture that addresses these needs through deployment. 12.1. Using the Farmington Regional ITS Architecture in the Planning Process One of the most important outcomes of the Farmington Regional ITS Architecture is that it will be used to plan and deploy ITS across the region. To do this, the ITS Architecture must be integrated into the regional planning process. As a result of integrating the ITS Architecture into the planning process, the architecture will link the needs of the regions with the ITS deployments in the field. The goal of the planning process is to make quality, informed decisions pertaining to the investment of public funds for regional transportation systems and services. Using the regional ITS architecture to support these planning activities is an important step in the mainstreaming of ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 128 ITS into the traditional decision-making of planners and other transportation professionals. Once an architecture is complete, it can feed detailed ITS-specific information back into the planning process. Figure 13 shows some of the key steps in the transportation planning process. These steps will be elaborated on in following sections. The process is driven by a regional vision and set of goals. These drive transportation improvement strategies that are a mix of capital improvements and operational improvements. The planning organizations evaluate and prioritize the various strategies, and the resulting output is a document called the Long Range Transportation Plan (or sometimes Transportation Plan or Regional Transportation Plan). This plan is the key output of long range planning. For Farmington, the long range planning document is the current 2010 Metropolitan Transportation Plan 2010- 2035. Note that the 2015 Metropolitan Transportation Plan 2015-2040 is currently under development for the Farmington MPO region. The second document relevant to the planning process is the Transportation Improvement Program (TIP) 2014-2019. Once a project is programmed then project development can begin. All of these steps occur with a variety of critical factors and inputs as shown in the figure. As shown in the figure, a regional ITS architecture may support each step in this process. Regional Vision & Goals Alternate Improvement Strategies Capital Capital Operational Evaluation & Prioritization Of Strategies Development of Long-Range Transportation Plan Development of Transportation Improvement Program Project Development System Operation Budgets Economic Development Public Involvement Environmental Issues Feedback Critical Factors & Inputs Long Range Planning Regional ITS Architecture Title IV ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 129 Figure 13. ITS Architecture and the Transportation Planning Process The Transportation Plan is the expression of Farmington’ long-range approach to planning and implementing the multimodal transportation system. It is the policy forum for balancing transportation investments among modes, geographic areas, and institutions. How can a Regional ITS Architecture support the transportation planning process? In the following basic ways that will be expanded upon below:  The services described in the regional ITS Architecture can provide the basis for operational strategies that can be used to improve the transportation system to meet the region’s vision and goals.  The regional ITS architecture can be used to support evaluation and prioritization of strategies in two ways. The first is through the definition in the architecture of archiving and data collection systems that support collecting the data needed for evaluation. The second is through the detailed definition of ITS projects and their sequencing that can be used to support prioritization efforts.  The definition of an integrated transportation system described by the regional ITS architecture can support the ITS elements of the Transportation Plan.  The process of developing and maintaining a regional ITS architecture can help to enhance the linkage between operations and planning through closer involvement of a wider array of stakeholders from both of these areas of transportation. The discussion below focuses on supporting the MPO transportation planning process, but the architecture can also be used to support the other planning processes used by agencies in the region (e.g. public safety agencies). As shown in Figure 14, agencies that do not use federal funds (or operate through the MPO planning process) will still have some form of long range plan and capital plan whose development can be supported by the regional ITS architecture. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 130 Figure 14. Supporting the Transportation Planning Processes The challenge for achieving integration across planned ITS projects in the regions is to know how they fit together and interact or depend on each other. The regional ITS architecture can be leveraged to bridge the MPO processes to other agencies planning processes that do not use federal funding. If all the processes are using the same reference point, the regional ITS architecture, then project integration can start in the planning phase. 12.1.1. Operational Strategies The Farmington MPO planning process begins with a set of goals which are given in the Transportation Plan as:  Support the economic vitality of the MPO region by providing a balanced, multi‐modal transportation system that moves people, goods and information safely, economically and efficiently  Foster regional coordination and transportation system continuity  Develop and connect transportation systems and associated facilities into a cohesive intermodal system  Minimize congestion on the transportation system  Provide reasonable access to services and jobs for all of the region's residents, regardless of age, income or disability  Minimize negative environmental impacts and enhance the environmental quality of the MPO region  Identify and develop funding sources adequate to build, operate, and maintain the metropolitan transportation system Long Range Transportation Plan (LRTP) Transportation Improvement Program (TIP) ITS Architecture ITS Related Projects MPO Planning Process Funded ITS Related Projects goals, objectives, policies Strategic / Long Range Plan ITS Related Projects Other Agency Planning Process Capital Plan / Budget ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 131  Identify and implement new technology for balanced multi-modal transportation  Develop a transportation system that maintains and/or enhances the existing quality of life and works in concert with cultural and environmental resources and adopted local plans  Integrate transportation and land use planning to improve quality of life and to protect the natural environment  Ensure public safety for all modes  Coordinate with local agencies on security planning and strategies These goals are implemented by a set of strategies. The strategies are defined in each modal chapter of the Plan.. As shown in Figure 13, the strategies are primarily capital improvements or operational improvements. The Regional ITS Architecture can provide an array of potential operational improvements through the services that are defined in it. Strategies that have traditional transportation projects as their primary solution, may add ITS elements or services as a part of the overall strategy solution. For example, to reduce congestion, a corridor is planned for widening. This project could also include incorporation of ITS elements and services to better manage the upgraded corridor. The use of the architecture to support the definition of implementation strategies is assisted by the definition of needs and their mapping to ITS services given in Section 6.1. 12.1.2. Strategy Evaluation and Prioritization Transportation planners use a variety of tools to evaluate and prioritize the various strategies for transportation improvement. Collection of data about the transportation system is a key input to support the evaluation. Several ITS services, described in the regional ITS architecture can support this data collection, providing the planning organization the ability to measure non- recurring congestion, travel times and travel time reliability, and other aspects of system performance and service reliability across all modes. The Farmington Regional ITS Architecture provides a guide for the archiving of transportation data including the collection of data from various ITS operational systems. These archiving capabilities revolve around regional examples of the National ITS Architecture entity, Archive Data Management (such as the NMDOT Statewide Crash Information System). Furthermore the Farmington Regional ITS Architecture has examples of ITS services such as ITS Data Mart, which covers the collection of historical data from a single source. These examples of data archiving services describe connections and information that can be useful to planners in performing their evaluation and prioritization efforts. While the automation of data collection for archiving is usually a future activity (or project), the discussions that occur during the development of the regional ITS architecture often present additional opportunities for data sharing that can occur immediately even before projects for the automation of data sharing are implemented. This sharing of data between operations and planning, as well as the coordination that occurs in the development of the Regional ITS Architecture are examples of linkages between Planning and Operations. The concept of linkage between these two disciplines figures prominently in the FHWA Planning for Operations effort (see http://plan4operations.dot.gov/). A complete treatment of these opportunities is included in the ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 132 FHWA publication: Opportunities for Linking Planning and Operations. This publication can be found at http://www.ops.fhwa.dot.gov/publications/lpo_ref_guide/index.htm. Additional information regarding the using the regional ITS architecture in planning can be found in Applying a Regional ITS Architecture to Support Planning for Operations: A Primer, which can be found at http://www.ops.fhwa.dot.gov/publications/fhwahop12001/index.htm. FHWA has made available several software tools to support the evaluation and prioritization of ITS related strategies developed as part of the planning process. These tools include:  IDAS (ITS Deployment Analysis System) is a software tool developed by the Federal Highway Administration that can be used in planning for Intelligent Transportation System (ITS) deployments. State, regional, and local planners can use IDAS to estimate the benefits and costs of ITS investments – which are either alternatives to or enhancements of traditional highway and transit infrastructure. IDAS can currently predict relative costs and benefits for more than 60 types of ITS investments. For more information see http://idas.camsys.com/.  DYNASMART-P (Dynamic Network Assignment-Simulation Model for Advanced Roadway Telematics- Planning version) is a software tool developed for traffic operations planning applications under Federal Highway Administration’s Dynamic Traffic Assignment (DTA) research program. DYNASMART-P combines dynamic network assignment models, used primarily in conjunction with demand forecasting procedures for planning applications, and traffic simulation models, used primarily for traffic operations studies. For more information see http://www.dynasmart.umd.edu/.  SCRITS (SCReening for ITS) is a spreadsheet analysis tool for estimating the user benefits of Intelligent Transportation Systems (ITS). It is intended as a sketch-level or screening-level analysis tool for allowing practitioners to obtain an initial indication of the possible benefits of various ITS applications. For more information see http://www.fhwa.dot.gov/steam/scrits.htm. Regional ITS Architecture outputs, specifically the project sequencing output may also be useful to planning staff as an aid to evaluation and prioritization of strategies. The architecture provides a short-term and long-term, multi-modal view of the ITS systems in the region. It provides the details of the transportation services and functions that can be provided by the stakeholders via ITS projects. The Regional ITS Architecture also illustrates the interfaces necessary between transportation systems to meet the transportation needs of the region. Finally it translates these details to the definition of a set of projects to be implemented. These projects are grouped by timeframe (e.g. short term, medium term, long term). Key to its usefulness for the strategy evaluation and prioritization (as well as for the LRP as discussed below) is that this list of projects goes well beyond the short term projects that get included in the TIP and STIP (see Section 12.2 for a discussion of how the architecture can be used in developing this program element.) The project sequencing contains information for each project that may be useful to the evaluation or prioritization of the projects including:  Stakeholders involved in the project ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 133  Mapping of the project to ITS Services Note that this project sequencing is not a replacement for prioritization, but rather, an input to the process by which projects are prioritized. In some cases, prioritization may already have occurred and be reflected in the project sequencing outputs. The Farmington Regional ITS Architecture provides a guide for how ITS projects can be deployed to satisfy the goals and objectives defined as part of the planning process. The architecture provides the details on how ITS can be deployed to meet and satisfy the strategies and transportation services identified for the region. These details may include the interfaces, the operational concepts and agreements necessary to implement the strategies and transportation services. With these details, ITS projects can be more clearly defined, funded, and implemented to satisfy the regional goals. 12.1.3. Metropolitan Transportation Plan One of the primary motives for ITS, and the regional ITS architecture, is the need for more effective management of existing transportation infrastructure. Many regions can no longer rely on adding capacity to keep pace with increasing demand. Instead, they are relying on more effective, integrated management of the existing infrastructure. Recognizing this need, many regions are beginning to include a section of the plan on “Management and Operations”, which can be defined as an integrated approach to optimize the performance of existing infrastructure through the implementation of multimodal, intermodal, and often cross-jurisdictional systems, services, and projects. The Regional ITS Architecture can provide the technical underpinning to this portion of the Metropolitan Transportation Plan. One of the primary purposes of the Regional ITS Architecture is to define how an integrated transportation system (of ITS elements) might evolve in a region. To do this, the architecture describes elements (e.g. various ITS assets) that are interconnected to provide operations and management of the transportation system. The architecture development and maintenance process provides an accessible way for transportation planners to become more focused on integrated management and operations. Operations practitioners have a vision for how this integrated transportation system might evolve, and express this via the details of the architecture. In the development of the Metropolitan Transportation Plan, some of the outputs of the regional ITS architecture can be of use in the plan update. The outputs and some indication of their use are:  ITS Projects from the Regional ITS Architecture can provide an input to the Prioritized Plans and Project section (as well as the TIP).  Customized Service Packages from the Farmington Regional ITS Architecture offer service-oriented slices of the architecture that facilitate project definition with an understanding of integration necessary to deliver specific services. The service packages provide planners with insight into the ITS elements to include in a project, which will make the project as comprehensive as possible. They also provide sample Implementation Strategies that include ITS to address strategies. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 134 12.1.4. Issues/Challenges One issue to address in using the architecture to support planning is coordination of ITS project planning between the federally funded projects and the non-federally funded projects. The non- federally funded projects may not be part of the Metropolitan Transportation Plan (and TIP). The ITS Architecture contains systems and projects that bridge both federally and non-federally funded projects and systems. Coordinating all of these projects requires an understanding by all stakeholders of the ITS systems and potential of the entire region. The ITS Architecture provides a common reference point for all stakeholders to gain insight into the integration of the systems in the region. 12.1.5. Recommendations It is recommended that Farmington MPO, as the Metropolitan Planning Organization responsible for the Metropolitan Transportation Plan and TIP, designate an ITS Planner with responsibility for the application and monitoring of the ITS Architecture in the Transportation Planning Process. (This person would likely be assisted by the ITS Subcommittee). The roles and responsibilities should include:  Point of contact for tracking the incremental process of project implementation; projects are typically broken into phases, therefore, someone should be responsible for keeping track of completed and remaining phases and ensure the remaining components are reflected in the planning process for on-going funding support until project completion,  Point of contact for ITS Architecture questions regarding its application in the planning process,  Lead the evaluation of ITS (containing) projects for their compliance with the ITS Architecture,  Outreach to stakeholders about how to use the ITS Architecture in the planning process,  Provide feedback to the Maintenance Manager of the ITS Architecture (if this is a different person) on any ITS Architecture changes needed as a result of project planning,  Liaison between MPO, state, and non-MPO planning organizations to share information about the ITS containing projects in the various planning processes and coordinate integration opportunities. An additional recommendation is that the Regional ITS Architecture be formally adopted by Farmington MPO. This will add “credibility” to architecture for use in planning process and will also encourage rigor in architecture maintenance process (described in Section 13). 12.2. Using the Farmington Regional ITS Architecture for Programming Regional and statewide programming and agency capital planning (a.k.a. budgeting) involve identifying and prioritizing ITS projects, resulting in funded projects. Using the regional ITS architecture to define an ITS project links the needs of the region identified in the architecture ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 135 with the ITS deployed in the field. In the region, ITS projects are deployed by many organizations including NMDOT, transit agencies and many local agencies and authorities. If projects of the various organizations are defined from the same reference point, the Farmington Regional ITS Architecture, then coordination begins in the initial planning and funding phase. ITS projects in the region may be funded by a variety of sources. ITS projects that are funded with federal funds are programmed through the Farmington MPO planning process with input from member transportation agencies in the region. All organizations in a region, whether they use federal funds to deploy ITS or not, perform short term planning via their capital planning (i.e. budgeting) process. 12.2.1. Architecture Use in Programming Federal Funds The Transportation Improvement Program (TIP) is a staged, multiyear, intermodal program of transportation projects that is consistent with the long range transportation plan for the Farmington. The TIP assigns federal funding to a prioritized list of specific projects to be constructed over a several-year period (usually three to six years) after the programs approval. As discussed in the recommendations of Section 12.1.5, the regional ITS architecture can be adopted as part of or by reference in the Metropolitan Transportation Plan. If this is the case, ITS projects should flow from the Transportation Plan into the TIP in the same fashion as capital projects. The architecture can be used to define ITS projects that are submitted for federal funding. In the current TIP, ITS projects are not defined in much detail. Sometimes merely a placeholder for ITS projects is included. A benefit to using a regional architecture to define ITS projects is that the projects can be specified in greater detail thereby allowing more realistic estimates of the ITS services being covered by the project. When project sponsors submit ITS projects for programming, the planning agencies in some regions require that the sponsors submit architecture-related information about the project. It is recommended that the Farmington MPO TIP project identification forms include specific reference to ITS Subcommittee review to ensure consistency with the ITS Architecture. Some agencies merely require yes/no questions to be answered regarding the project’s inclusion in the regional architecture while others request more detailed information such as the elements, services, and/or interfaces of the architecture to be deployed in the project. If an ITS project is submitted which is not included in or is not consistent with the regional architecture, a justification for the project should be required. If it is justified, the impacted stakeholders support the project, and the project is funded, the regional architecture should be revised to incorporate the project. In the TIP, projects that contain ITS elements should be designated as ITS projects so that projects sponsors are aware of the associated requirements from the FHWA/FTA Rule/Policy. The programming process involves prioritizing projects and using federal funds to fund the top priority projects. Each region has a process for prioritizing projects. The regional ITS architecture can be useful in this process as it reflects the vision for ITS in the region so a factor in prioritization should be how well a project fits within the regional architecture. In some ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 136 regions, projects (of some categories) are allotted additional points if they include elements or interfaces of the architecture. The Farmington Regional ITS Architecture may better support programming if the project sequencing and related architecture elements are updated on a maintenance schedule that supports the TIP cycle. The architecture should be updated prior to a project submittal request so that it can be used by project sponsors to identify projects. If thorough updates to the architecture are to correspond to Transportation Plan updates, less major revisions to the architecture can be made to correspond to the TIP cycle. 12.2.2. Architecture Use in Organization Capital Planning All agencies including Farmington MPO, NMDOT, transit agencies, local municipalities, etc. use a budgeting process to allocate funds to projects. The Farmington Regional ITS Architecture includes the existing and planned elements of all stakeholders and how they are or will be interfaced with other ITS elements in the region. Therefore, all organizations can use the architecture to define ITS projects, as defined below, and feed them into their budgeting process. Many ITS improvements are implemented as part of larger capital improvement projects. As traditional capital projects are defined and programmed, it is important to identify the associated opportunities for efficient ITS implementation. The Farmington Regional ITS Architecture is a record of the ITS implementation planned by each agency that can be used to identify these opportunities. Some agencies in other states are considering policies to review each capital project to determine if ITS measures should be included before the project moves forward. Many agencies do this type of review as good practice, but these opportunities would be identified more consistently and “carry more weight” if this check was formally defined and required by an established policy. 12.2.3. Architecture Use to Identify and Define Projects A regional ITS architecture includes a sequence of projects. Projects from the architecture should feed into the programming and/or capital planning processes. ITS projects are taken directly from the plan and submitted for funding (with Federal or other funds.) As the projects defined in a regional ITS architecture are sequenced and have defined characteristics, organizations can use the architecture to define ITS projects to be submitted for funding from any source. To obtain funding, a project sponsor must define a proposed ITS project. The information contained in the Farmington Regional ITS Architecture can be used to define projects with more detail in order to better scope them and establish project budget requirements. Some potential ways a regional ITS architecture can be used to define an ITS project include:  Review the list of stakeholders to identify those that should be involved with the project and those that are or may be impacted.  Use the stakeholder roles and responsibilities defined in the operational concept to clearly define the roles and responsibilities of the stakeholders involved in the project. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 137  Review the relevant service(s) (i.e. service package(s)) to identify elements potentially directly or indirectly associated with the project and recognizing potential partners to share development costs, material and/or labor, facilities, etc.  Use the defined interfaces between ITS elements (in the customized service packages) to identify current and future integration opportunities.  Apply the project description of the project sequencing including costs, technical feasibility, potential institutional issues and readiness to clearly define the project.  Gain a thorough understanding of the elements and interfaces included in a project to more accurately estimate project budgets. 12.2.4. Challenges One critical issue is the coordination of federally and non-federally funded projects in the region. In many regions, non-Federally funded projects are generally not included in the TIP. The Regional ITS Architecture contains all ITS elements and projects within the scope of the architecture irrespective of funding source. As the Farmington Regional ITS Architecture enables understanding and coordination of all ITS related projects for all stakeholders in the region, stakeholders can benefit from using an ITS Architecture to plan, program, and deploy all ITS projects not just those that are Federal funded and therefore, must meet the Rule/Policy requirements. 12.2.5. Recommendations Agencies that sponsor integration projects that are identified in the regional ITS architecture may face several hurdles. Involvement by multiple agencies may add perceived risk to the project and the benefits from the project may be more regional in nature and difficult to quantify as hard savings for a particular agency. The region can offset these hurdles by promoting integration projects to encourage support from individual agency project sponsors. For example, the Maricopa County Area Governments (MAG) MPO (in Arizona) has a documented process for ITS project prioritization that favors ITS integration projects that are identified in the ITS strategic plan and support multiple agencies. A prioritization process like this that favors integration projects with regional benefits can help to offset the hurdles faced by individual agency project sponsors. To ensure ITS is deployed based on the regional vision contained in the Farmington Regional ITS Architecture, a process for local and regional planning and funding of projects based on the Farmington Regional ITS Architecture should be established. Policies and procedures to incorporate ITS projects in the programming/budgeting processes could be set or a group of various ITS stakeholders could be assigned the responsibility for monitoring the deployment of ITS in the region. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 138 12.3. Using the Farmington Regional ITS Architecture in Project Definition Projects that emerge from the planning process can benefit from the use of the Farmington Regional ITS Architecture in their definition and development. Project implementation should follow a systems engineering process. The ITS Architecture is most effective in the early phases of systems engineering processes. Figure 15 shows a typical project implementation process for deploying ITS projects. Figure 15. Project Implementation Process The project implementation process shown in Figure 15 is a systems engineering process. It is a process that can be used to systematically deploy ITS while reducing the risks associated with deployments. The Systems Engineering process is more than just steps in systems design and implementation; it is a life-cycle process. The process recognizes that many projects are deployed incrementally and expand over time. US DOT Rule 940 requires that aspects of this systems engineering process be used for ITS projects that are funded with federal funds. Applying the System Engineering process to ITS project development is a key new requirement that must be addressed by stakeholders using federal funds. The following are some key references that stakeholders can access to assist in using this process: General Resources  FHWA Systems Engineering Website (ops.fhwa.dot.gov/int_its_deployment/sys_eng.htm)  International Council on Systems Engineering (www.incose.org) Training  Introduction to Systems Engineering (CITE- http://www.citeconsortium.org/courses/SE101.html) ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 139  Advanced Systems Engineering for Advanced Transportation Projects (CITE - www.citeconsortium.org/courses/syseng.html) Publications  Building Quality Intelligent Transportation Systems through Systems Engineering (FHWA-OP-02-046): ops.fhwa.dot.gov/its_arch_imp/docs/systems_engineering.doc  Systems Engineering Guidebook for ITS (FHWA California Division/Caltrans): www.fhwa.dot.gov/cadiv/segb  System Engineering for Intelligent Transportation Systems, An Introduction for Transportation Professionals: http://ops.fhwa.dot.gov/int_its_deployment/sys_eng.htm There are similarities between the systems engineering process defined in Figure 15 and the project development process followed by agencies in the region. A typical agency project development process is as follows:  Project Selection  Authorization to Proceed  Project Definition  Purpose and Need  Project Scoping  Conceptual Design  Project Design  Preliminary Plan Development  Semi-Final Plan Development  Final Plan Development  Construction  Testing  Operation and Maintenance Table 15 shows the relationship this project development process has to the FHWA system engineering process. Table 15. Regional Project Development Process Relation to FHWA System Engineering Process Project Development Process Relation System Engineering Process Project Definition Purpose and Need Project Scoping Conceptual Design Concept of Operations High Level Requirements Detailed Requirements ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 140 Project Development Process Relation System Engineering Process Project Design Preliminary Plan Development Semi-Final Plan Development Final Plan Development High Level Design Detailed Design Construction Testing Implementation Integration & Test Verification System Verification Operation and Maintenance Operations & Maintenance The Farmington Regional ITS Architecture can be used to support development of the concept of operations, requirements and high level design steps in the systems engineering process. In deployment of an ITS related project, the ITS Architecture should be used as the starting point for developing a project concept of operations (not to be confused with an Architecture’s Operational Concepts that define the roles and responsibilities of the Architecture’s stakeholders). The concept of operations shows at a high level how the systems involved in a project operate in conjunction with the other systems of the region. According to the NHI course “Introduction to Systems Engineering for Advanced Transportation”, a Concept of Operations includes the following information:  Identification of stakeholders,  Development of a vision for the project,  Description of where the system(s) will be used,  Description of organizational procedures or practices appropriate to the system(s), definition of critical performance parameters associated with the systems(s),  Description of the utilization environment (conditions under which various parts of the system(s) will be used),  Definition of performance measures used to evaluate the effectiveness of the system(s),  Considerations of life cycle expectations, and  Conditions under which the system(s) must operate (e.g. environmental conditions). The customized service package diagrams tailored by the regional stakeholders can also assist in definition of requirements for ITS systems involved in a specific project. The ITS Architecture contains high level functional requirements for all ITS elements in the region. These high level requirements can be the starting point for developing more detailed requirements. The ITS Architecture can support high level system design. The ITS architecture can be used by system designers to identify the ITS standards that are applicable for the interfaces included in the architecture. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 141 12.4. Using the Architecture to Support Development of Systems Engineering Outputs While the above discussion relates the architecture to the general system engineering process, Rule 940 does have a specific set of system engineering analysis requirements that apply to all ITS projects that use funds from the Highway Trust Fund. The required system engineering analysis steps are:  Identification of portions of the regional ITS architecture being implemented (or if a regional ITS architecture does not exist, the applicable portions of the National ITS Architecture) – in this case the regional ITS architecture;  Identification of participating agencies’ roles and responsibilities;  Requirements definitions;  Analysis of alternative system configurations and technology options to meet requirements;  Procurement options;  Identification of applicable ITS standards and testing procedures; and  Procedures and resources necessary for operations and management of the system. The Farmington Regional ITS Architecture can provide inputs for the four steps shown in italics in the above list. This section will detail how to obtain that information from the architecture. In general there are two cases to address in defining how to pull information from the architecture. In general there are two cases to address in defining how to pull information from the architecture:  The project is in the list of projects contained in Table 11 (and hence is identified in the Project Tab of the Architecture website)  The project is not in the current list of projects 12.4.1. Identifying Portions of Architecture Defined by the Project The first step in the Systems Engineering analysis is to identify the portions of the Farmington Regional ITS Architecture that will be implemented by a project 1. The project is in the list of projects. In this case information relating the project to the architecture can be found directly on the hyperlinked website. Select the Projects (or Projects by Stakeholder) Tab. Locate the project in the list and select it. The project details page provides the following information that identifies the portion of the Farmington Regional ITS Architecture addressed by the project:  Stakeholders  Inventory ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 142  Services Review the list of stakeholders and Inventory elements and edit as needed (adding or deleting entries as appropriate). Why might the list of stakeholders and Inventory elements not match the project? The lists contain the best understanding of the project at the time the architecture was updated, but the scope of the project may have changed once implementation began. The Services header shows the customized service package diagrams mapped to the project. Select each and review for applicability. If the entire diagram is covered by the project, then copying the figure from the website (it is in a .gif format) and pasting it into the Systems Engineering Analysis documentation will provide a detailed view of the mapping of the project to the architecture. If the project implements just a portion of the diagram then mark them us as needed to indicate what is covered. This can be done by importing the .gif file to an application like PowerPoint or Visio and performing edits in that tool. If the project as now defined is only partially covered by the architecture, then identify the changes needed to the architecture to fully cover the project (either by text or marked up customized service package diagrams) and notify the Maintenance Manager using the Change Request Form (see Section 13). 2. The project is not in the list of Projects in Table 11 In this case the project is one that was not collected and described directly in the architecture. However the essential scope of the project may still be included in the architecture. In this case the simplest route is to consider what ITS Services the project will address. On the website select Services (or Services by Stakeholder). Review the list of Services (Service Packages) and identify the ones most closely associated with the project. If you are not sure what a particular service package covers, select the Description Tab under Services, which has a description of each service package. Once you have identified the service package, review the customized diagrams under there for applicability. A selection of Inventory, Stakeholders (can be found on Stakeholder Tab, or under the Inventory Details pages on the web), and marked up customized service package diagrams represent a detailed mapping of project to architecture. 12.4.2. Agency Roles and Responsibilities The agency roles and responsibilities can be found in Table 3 of this document. Find the general area of the project (e.g. Incident Management) and then the appropriate stakeholder. Select the roles and responsibilities that most closely address the project and edit or expand as necessary. This information is also be available as part of the Operational Concepts Tab on the website, which is organized by Stakeholder. Selecting a stakeholder in the project moves to a web page that has general roles and responsibilities of the stakeholder organized into general functional areas (such as traveler information). 12.4.3. Functional Requirements Finding applicable functional requirements breaks into two cases as described in the section below: 1. The project is in this list of projects in Table 11. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 143 In this case select the project details page (under Project or Project by Stakeholder Tab). This page contains a list of functional areas requirements from the New Mexico Statewide ITS Architecture associated with the project along with a set of functional requirements associated with the functional area. Select the ones considered applicable for the project as now defined. Alternatively, select each element that is part of the project (also on the project details page) and the functional areas/ functional requirements associated with that element are shown. Select those that are appropriate. 2. The project is not in the list of Projects in Table 11 In this case identify the key elements of the project and go to the Inventory ITS Element detail page on the website. This page contains a list of functional areas/ functional requirements applicable to the element based on all the services it supports in the Farmington Regional ITS Architecture. Select the subset of these requirements applicable to the specific project. 12.4.4. Standards Identification Once again this step breaks into two cases as described below. 1. The project is in this list of projects in Table 11. In this case select the project details page (under Project or Project by Stakeholder Tab). This page contains a list of Standards from the Farmington Regional ITS Architecture associated with the project. Select the ones considered applicable for the project as now defined. 2. The project is not in the list of Projects in Table 11 In this case the applicable standards can be found by selecting the Standards Tab and reviewing the overall list of applicable standards for the region. Alternatively, if specific interfaces have been selected for the project, then go to the Element Details page for each project element, select the relevant interface, and select an architecture flow, which will bring up a details page that includes the applicable standards for that particular architecture flow. How do you show compliance with the rule requirements? Document with a System Engineering Review Form (SERF) how outputs meet requirements. A SERF has been developed for New Mexico by the FHWA Division Office and can be obtained from the FHWA Division representative. 12.4.5. Issues/Challenges One of the challenges of using the ITS Architecture and the System’s Engineering process in the implementation of a project is educating stakeholders about the benefits of the process and the process itself. The systems engineering process is not a new process to many organizations. It may not be called the systems engineering process, but various stakeholders’ processes probably map to the systems engineering process very well (as shown in Table 15). Making these types of linkages between processes makes it easier to incorporate the ITS Architecture as a tool in the process. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 144 Another challenge is engaging a broader stakeholder base on a project when the ITS Architecture indicates that possibility. For example a project might map to a specific customized service package that contains 10 elements owned by 8 stakeholders. Yet the initial project definition is for 3 elements owned by 2 stakeholders. Might the project, to provide the service shown in the architecture, include more elements owned by additional stakeholders? The entire activity of seeking integration opportunities is more institutional than technical. There will be instances where getting more stakeholders involved in a project will increase its complexity or cross jurisdictional boundaries that may not have been considered in the initial scope. It is important to explore these integration opportunities so that, at the very least, they are accounted for and supported in the project design even though they may not be implemented with that specific project. The ultimate goal is to make ITS deployment as economical as possible. One way this can be accomplished is by deploying projects across institutional boundaries where different stakeholders get benefit from the ITS deployment. 12.4.6. Recommendations It is recommended that Farmington MPO, NMDOT, and other agencies involved in deploying ITS projects modify their project development/implementation processes to incorporate the use of the Farmington Regional ITS Architecture. There is no standard definition of how or what process modifications are required – it is merely a function of each agency’s project development processes. It is recommended that training then be developed and given to representatives of the key agencies to describe the impact of the Farmington Regional ITS Architecture on the project development process, and to describe the new requirements that have been placed on ITS project development when federal funds are used. The process modifications should be distributed to stakeholders so they are aware of the steps to follow and are aware that this process is a necessary part of any project receiving federal funding. It is also recommended that an individual or group be identified in each organization (Farmington MPO, NMDOT, etc.) to review project submittals and evaluate compliance with the Farmington Regional ITS Architecture. It is important to work with the FHWA Division Office Representative in establishing a review process given that they will be involved in approval of projects with federal funding. The generation of a checklist would make the evaluation more structured and facilitate a consistent approach to each project. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 145 13. Maintaining the Architecture The Farmington Regional ITS Architecture is not a static set of outputs. It must change as plans change, ITS projects are implemented, and the ITS needs and services evolve in the region. This section describes the maintenance plan for maintaining the Farmington Regional ITS Architecture. The plan covers the following four key areas:  Who will be involved in the maintenance of the architecture?  When will the architecture be updated?  What will be maintained?  How it will be maintained (i.e. what configuration control process will be used)? The Farmington Regional ITS Architecture is 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 Farmington Regional ITS Architecture will need to be updated to reflect changes resulting from project implementation or resulting from the planning process itself. Types of changes may include:  Changes for Project Definition. When actually defined, a project may add, subtract or modify elements, interfaces, or information flows from the Farmington Regional ITS Architecture. Because the Farmington Regional ITS Architecture is meant to describe the current (as well as future) regional implementation of ITS, it must be updated to correctly reflect how the developed projects integrate into the region. Also, once projects are implemented, interfaces that were shown in the architecture as planned should now be changed to existing.  Changes for Project Addition/Deletion. Occasionally a project will be added or deleted through the planning process and some aspects of the Farmington Regional ITS Architecture that are associated with the project may be expanded, changed or removed.  Changes in Project Priority. Due to funding constraints, or other considerations, the planned project sequencing may change. Delaying a project may have a ripple effect on other projects that depend on it. Raising the priority for a project’s implementation may impact the priority of other projects that are dependent upon it.  Changes in Regional Needs. Transportation planning is done to address regional needs. Over time these needs can change and the corresponding aspects of the Farmington Regional ITS Architecture that addresses these needs may need to be updated.  Changes in other Regional/Statewide ITS Architectures. Changes made in the New Mexico Statewide ITS Architecture can affect the Farmington Regional ITS Architecture, necessitating changes to maintain consistency between the architectures. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 146  New Stakeholder: When new stakeholders come to the table, the Farmington Regional ITS Architecture will need be updated to reflect their place in the regional view of ITS elements, interfaces, and information flows.  Changes or Evolution in ITS Standards applicable to ITS Projects in Farmington: The architecture maps ITS standards to interfaces (and hence to projects). Over time, this mapping will need to be updated as standards release new versions, or as new standards are developed. Finally, the National ITS Architecture may be expanded and updated from time to time to include new user services or better define how existing elements satisfy the user services. These changes should also be considered as the Farmington Regional ITS Architecture is updated. The National ITS Architecture may have expanded to include a user service that has been discussed in a region, but not been included in the Farmington Regional ITS Architecture, or been included in only a very cursory manner. 13.1. Roles and Responsibilities for Maintenance Responsibility for maintenance of the Farmington Regional ITS Architecture lies with the Farmington Metropolitan Planning Organization, since they perform the primary regional planning organization functions, and will be one of the primary users of the architecture. A group of core stakeholders, currently constituted as the ITS Steering Committee, will act as an “institutional framework” to review proposed changes to the architecture. This group of core stakeholders is important because the Farmington Regional ITS Architecture is a consensus framework for integrating ITS systems. As it was a consensus driven product in its initial creation, so it should remain a consensus driven product as it is maintained. This section defines the stakeholders and their roles and responsibilities for the maintenance of the Farmington Regional ITS Architecture. 13.1.1. Definitions The following groups or persons have a role in the maintenance of the architecture:  Stakeholders. Any government agency or private organization that has a role in providing transportation services in the region.  Maintenance Working Group. A group of stakeholder representatives who are responsible for the technical review of updates/changes to the Farmington Regional ITS Architecture, and for approving changes to go into the architecture.  Responsible Agency. The stakeholder agency with primary responsibility for maintenance of the architecture.  Maintenance Manager. The person responsible for overseeing and guiding the maintenance efforts. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 147 13.1.2. Stakeholders Stakeholders are any government agency or private organization that is involved with or has an interest in providing transportation services in the region. Each stakeholder owns, operates, and/or maintains one or more ITS element in the region and, therefore, should be included in architecture. The success of the change management process outlined in this Maintenance Plan is highly dependent on the participation of the stakeholders identified in the architecture. Without stakeholders participation in tracking the development of their ITS systems, and properly updating the architecture, the change management process will not succeed and the usefulness of the architecture will diminish over time. The primary responsibility of the stakeholder agencies is to submit changes to the Farmington Regional ITS Architecture that are brought on by new plans or projects that are being planned or deployed for the stakeholder agency. The stakeholder agency must submit the changes in the Farmington Regional ITS Architecture to the Maintenance Working Group. If stakeholders desire more involvement in the architecture review process, they can get involved through voluntary participation in the Maintenance Working Group. Each Stakeholder agency that is part of the Maintenance Working Group will designate an Authorized Representative who can sign off on architecture related changes for the agency. 13.1.3. Maintenance Working Group The Farmington Regional ITS Architecture Maintenance Working Group, or the Maintenance Working Group for short, has the following responsibilities:  Collecting and compiling proposed changes and updates to the architecture from stakeholder agencies.  Evaluating each proposed change from a technical standpoint, and reaching a consensus on the proposed change (this may require contacting additional stakeholders if one or more of their systems are affected).  Approving changes to the architecture.  Making any institutional or policy related decisions that arise in the maintenance of the architecture The maintenance working group for the Farmington region will be the ITS Steering Committee that is already in existence. The Maintenance Working Group (the ITS Steering Committee or subset of) will elect a Chairperson (and Vice-Chairperson in their absence) to conduct any meetings that need to be held. The Chairperson is responsible for calling meetings, developing an agenda for meetings, and leading the meetings. The Chairperson will be elected for a two-year term by a simple majority vote of a Working Group meeting where there is a quorum (2/3 of the member representatives present). It might be prudent if the Chairperson of the ITS Steering Committee also serves as the Chairperson of the Maintenance Working Group. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 148 13.1.4. Responsible Agency The Responsible Agency is the government agency that formally maintains the architecture. The Responsible Agency assigns resources for making the physical changes to the architecture baseline, and for coordinating the maintenance of the architecture. The Responsible Agency for the Farmington Regional ITS Architecture is Farmington MPO, since they are the transportation planning organization for the region, and will be primary users of the architecture. While they have responsibility for the maintenance of the architecture, they may use other assets (such as NMDOT personnel) to perform the actual updates to the Turbo Architecture database. 13.1.5. Maintenance Manager The Farmington MPO will appoint a person to serve as Maintenance Manager to coordinate the maintenance activities of the Farmington Regional ITS Architecture. The Maintenance Manager is the coordinator and main point of contact for all maintenance activities, including receiving Change Requests forms, tracking Change Requests, and distributing documentation. This person will be the Champion defined in Section 4.1. The Maintenance Manager has the following responsibilities:  Coordinate the activities of the Maintenance Working Group  Receive Change Request forms and requests for documentation from stakeholders  Distribute the baseline documents and outputs of the architectures to stakeholders.  Maintain the “official” records of the Farmington Regional ITS Architecture, including the baseline documents, meeting minutes, the Change Request Database, and the list of Points of Contacts for the Stakeholder  Ensure the status of each Change Request is properly updated in the Change Request Database  Maintain a complete contact list of all stakeholders within the region. Some of these responsibilities may be delegated to staff or consultants. 13.2. Timetable for Maintenance How often will the Farmington Regional ITS Architecture be modified or updated? What events or timetable will be used for making updates or changes to the architecture? There are two basic approaches that the region will utilize for maintaining the architecture:  Periodic Maintenance. Update the architecture based upon one of the recurring activities of the transportation planning process. For example, it’s natural that the ITS architecture would be updated at the same frequency as the Transportation Plan is updated (every five years) or the Transportation Improvement Program is updated (at least every two years). The update of the architecture will occur several months prior to the transportation planning document update, so that the revised architecture could serve as an input to the planning update. Publication and versioning costs are ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 149 minimized for the periodic maintenance approach since there is a new version only once in the maintenance cycle.  Exception Maintenance. This approach will be followed if there is an urgent need to make a change, or if a minor change is desired to address some stakeholder need. In this case the change can be initiated as needed. Publication and versioning costs are dependent on the frequency of changes made to the regional ITS architecture. 13.2.1. Periodic Updates A comprehensive architecture update will occur every four years, concurrent with a formal update of the TIP. This is a natural result of the Farmington Regional ITS Architecture being a component of the regional transportation planning process. The update is necessary to ensure that the architecture continues to accurately represent the regional view of ITS Systems. The comprehensive update may include adding new stakeholders, reviewing transportation needs and services for the region, updating the status of projects, and reflecting new goals and strategies, as appropriate. Operational concepts, system functional requirements, project sequencing, ITS standards, and list of agency agreements may also be updated at this time. Between major updates of the architecture, the following interim update actions will be performed: On an annual basis, the Maintenance Manager will actively solicit changes from each key stakeholder a set of needed updates. The Maintenance Manager will contact the key stakeholders, via e-mail, written correspondence, or by telephone, and inquire if the stakeholder has any changes to the Farmington Regional ITS Architecture. It is the responsibility of the stakeholders to complete and submit the Change Request Forms to the Maintenance Manager for consideration. Within a defined period, the submitted Change Request Forms will be collected and reviewed by the Maintenance Working Group for consideration in the next minor update of the Farmington Regional ITS Architecture. The Maintenance Plan will also be reviewed at the annual updates for required changes to the Maintenance Plan. Use of the Farmington Regional ITS Architecture and modifications to it may differ from what was anticipated during the initial development of the Maintenance Plan. Revising the Maintenance Plan will ensure that the change management process defined is effective. 13.2.2. Event-Driven Updates There are certain considerations listed above that may call for an event driven update to the architecture. In this case a stakeholder may submit a Change Request Form to the Maintenance Manager and request that the Maintenance Working Group review and approve the change request prior to the next scheduled update of the Farmington Regional ITS Architecture. This may be necessary if a stakeholder suddenly requires federal funding for a previously unplanned ITS project, and needs the ITS project to be included in the Farmington Regional ITS Architecture. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 150 13.3. Architecture Baseline Establishing an architecture baseline requires clear identification of the architecture products to be maintained, including specific format and version information. For the Farmington Regional ITS Architecture, the following are identified as the architecture baseline:  Farmington Regional ITS Architecture Document (this document)  Set of Customized Service Packages (Visio file)  Turbo Architecture Database  Farmington Regional ITS Architecture Web pages  Change Database  Stakeholder List Regarding the Architecture document, the original source document, in Microsoft Word format, will be held by the maintenance manager, while a PDF version of the documents will be available for general distribution. In addition, a version number and date will be included inside the cover page. Each document will use a versioning scheme that identifies the baseline and revision number. For example, the initial release of the documents at the conclusion of this effort will be version 1.00. Minor revisions will be 1.01, 1.02, etc. The next major revision to the document will be version 2.00. Regarding the set of customized service packages, the Visio file will be maintained by the maintenance manager. Regarding the Turbo Architecture Database, the maintenance manager will maintain a zipped version of the final delivered Farmington Regional ITS Architecture database. The name, date, and size of the database file inside the zipped file will 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 will be maintained by the maintenance manager (this task may be shared/coordinated with the NMDOT). The version number of the architecture will be clearly visible somewhere on the home page of the web site so that the version being viewed is immediately identifiable. The Change database will be a Microsoft Access database with the version number in the name of the database. The Stakeholder list will be a Microsoft Excel file with the version number in the name of the file. 13.4. Change Management Process This change management process specifies how changes are identified, how often changes will be made, and how the changes will be reviewed, implemented, and released. The change management process involves five steps:  Identify Change. Review what changes are needed and complete and submit a Change Request Form. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 151  Evaluate and Review Change. An initial evaluation of the Evaluate the change for completeness and consensus. The Maintenance Working Group will then review the results of the evaluation and approve the change.  Update Baseline. Apply the approved changes to the Farmington Regional ITS Architecture documents.  Notify Stakeholders. Inform the stakeholders of the updated changes to the Farmington Regional ITS Architecture documents, and distribute the documents as necessary. The identification of who performs these steps is shown in Figure 16. Figure 16. Change Management Process 13.4.1. Identify Change This involves two issues:  Who can identify a change to the architecture, and  How will the change request be documented? 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 deliberate the change request. On the other end of the spectrum, if too much formality or paperwork is added to the process then many valid or needed changes may go unexpressed. Stakeholder : Identify changes and inform Authorized Representative Authorized Representative : Create Change Request, signs off and sends to Maintenance Manager. , Maintenance Manager: Gathers Change Requests and distributes to Maintenance Working Group Maintenance Working Group : Evaluates Change Requests Approve, reject, or request more information on change End Maintenance Manager : Updates architecture and informs stakeholders. More Information ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 152 Any Stakeholder identified in the Farmington Regional ITS Architecture is allowed to submit Change Requests. This effectively indicates that all changes have the approval of an existing, defined stakeholder in the ITS Architecture. If the Change Request is to add a new Stakeholder and that Stakeholder’s ITS Elements and Interfaces, the Responsible Agency for the architecture must submit the Change Request. A Change Request Form will be used to submit changes for review. The Maintenance Change Request Form for the Farmington Regional ITS Architecture can be found in Appendix C. The Maintenance Change Request Form includes the following information:  Name of change  Description of change  Part of baseline affected (could be check boxes for document, database, web site, and not known)  Rationale for change  Originator name or agency  Date of origination This information entered on the Change Request Form will be added to a change database, maintained by the Responsible Agency. The change database will include following additional fields of information:  Change number (some unique identifier)  Change disposition (accepted, rejected, deferred)  Change type (minor or significant)  Disposition comment  Disposition date  The Maintenance Working Group representatives who are present at the determination of the disposition. 13.4.2. Evaluate and Review the Change Request Upon receiving a Change Request by the Maintenance Manager, an initial evaluation of the Change Request will be made for the impact to the overall architecture or the affected document. The purpose of the evaluation is two-fold:  Verify that the Change Request form and supporting materials is complete and correct  Compare with other Change Request forms and determine if there are any conflicts If the proposal for architecture modification has an impact on other stakeholders, the evaluator(s) will contact the Stakeholders to confirm their agreement with the modification. All Stakeholders directly affected by the proposed change(s) must approve and sign-off the Change Request before the Maintenance Working Group considers the Change Request. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 153 There are several options as to who performs the initial assessment, including:  The Maintenance Manager  Maintenance Working Group  The person submitting the change  A consultant, hired to support the maintenance activities of the architecture Each of the above options has positive and negative implications, but the evaluator must have working knowledge of the architecture to evaluate the proposed changes. The Maintenance Manager or the Maintenance Working Group will assign the evaluation option to use for each change request evaluation received. Upon completing the initial assessment, the Change Request form will be reviewed by the Maintenance Working Group (either at a Maintenance Working Group meeting or via some electronic means). Maintenance Working Group meetings are called by the Maintenance Manager (or their designated representative). Maintenance Working Group meetings called by the Maintenance Manager will occur at least on an annual basis. When calling the annual meeting, the Maintenance Manager will send a reminder to all Stakeholders to update their ITS Elements and Interfaces in the architecture, if necessary. If sufficient Change Request Forms are submitted, the Maintenance Manager may call a Maintenance Working Group meeting at more frequent intervals to review the Change Request forms. The Maintenance Manager will distribute copies of all Change Request Forms submitted and all supporting materials to all Stakeholders prior to the meeting for their review and assemble an agenda. Maintenance Working Group meetings can also be requested by one of the stakeholders if there is an urgent need to update the architecture quickly. The Maintenance Working Group will be provided sufficient time to review the Change Requests before the meeting. During the meeting, the Maintenance Working Group will review the proposed changes and offer any comments. After each Change Request is reviewed, if no further comments are offered by the Maintenance Working Group, the Change Request will be considered approved, and the Chairperson will sign off on the Change Request. If additional comments are made that require action, those comments will be noted on the Change Request form. Where comments (or changes required) are minor in nature they can be made by the submitter of the Change Request form, or by resources designated by the Maintenance Manager and the change considered approved. In the case of major comments or changes to the Change Request, the approval of the change will be deferred until the next meeting of the Maintenance Working Group. If a Change Request is to be withdrawn from consideration, the Chairperson or the Maintenance Manager will be required to sign-off on the Change Request Form to close out the Change Request. At the end of the meeting, the Maintenance Working Group will agree if all the approved changes to the architecture necessitate an immediate update to the baseline, or whether the ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 154 update should await either additional changes or the next major revision. The decision should be based on the number of Change Requests approved and the nature of the approved changes. Meeting Minutes (or notes) will be kept for all Maintenance Working Group meetings. Minutes will include, at a minimum:  an attendance list,  comments made on each Change Request,  and the disposition of each Change Request Form (Approved/Withdrawn/Deferred/Request More Information). Minutes will be distributed to all members of the Maintenance Working Group meeting approximately 5 working days after the meeting. Comments are due within 10 working days to the Maintenance Manager. Approved minutes will be signed by the Chairperson and will be distributed to all Stakeholders and posted on the website. The minutes provide a recording process for the change management process and provide traceability. The Maintenance Working Group will have the option to handling the review and approval process for minor Change Requests via e-mail exclusively rather than through face to face meetings. 13.4.3. Update Baseline Upon approvals of the Change Request Forms, the decision agreed upon by the Maintenance Working Group is implemented. If the decision is to accept the change and update the baseline then the appropriate portions of the architecture baseline are updated and an updated architecture baseline is defined. In addition to updating the baseline documents, databases, or other outputs, the configuration status will be updated. In the discipline of Configuration Management this is known as Configuration Status Accounting. This accounting is performed by having a document (the Configuration Status Report) that defines the following information for each separate output of the architecture baseline:  Output name;  Output revision number;  Date of latest revision;  File Name; and  Location/Point of Contact. Periodically, the information in the various outputs of the architecture baseline will be audited to assure that the different representations of the architecture information (e.g. the database and document) are in sync. This configuration auditing will be performed by the chair of the ITS Committee at least every two years. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 155 Update of the Turbo Architecture Database The updates to the Turbo Architecture database require knowledge of the tool as well as the National ITS Architecture on which it is based. This knowledge may reside with the Responsible Agency, either with agency staff or with consultants contracted to support the maintenance effort, but the plan is that the Responsible Agency delegate this update responsibility to the NMDOT (or any private consultant they might hire) to perform the updates. The update of the actual Turbo Architecture Database would be done by NMDOT as directed by the Responsible Agency (as a result of the maintenance process described in this document). The Farmington Regional ITS Architecture Turbo Architecture database will be updated by NMDOT in response to approved changes from the Regional ITS Architecture maintenance processes. The Responsible Agency will receive from NMDOT a separate version controlled Turbo Architecture Database that contains only the Farmington Regional ITS Architecture. This database would be available for use by regional stakeholders in ITS project development efforts. 13.4.4. Notify Stakeholders Point of Contacts for each stakeholder will be notified by e-mail from the Maintenance Manager when baseline documents have been updated. All baseline documents will also be available to stakeholders from a website or other electronic location, such as an ftp site. It is the responsibility of the Maintenance Manager to ensure the most recent document is available from the website. The Configuration Status Document will be one of those outputs that are available. Request for copies or access to the baseline documents will be made to the Maintenance Manager. After major revisions to the architecture or the baseline documents, the Maintenance Working Group may elect to also provide all baseline documents to members on CD-ROMs, or secured- access files on the Architecture website. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 156 Appendix A: Acronyms Acronym Definition AASHTO American Association of State Highway and Transportation Officials ANSI American National Standards Institute APTA American Public Transportation Association APTS Advanced Public Transportation System ASTM American Society for Testing and Materials ATIS Advanced Traveler Information System ATMS Advanced Traffic Management System AVL Automated Vehicle Location BIA Bureau of Indian Affairs C2C Center to Center C2F Center to Field CCTV Closed Circuit TV CFR Code of Federal Regulations CV Commercial Vehicle CVAS Commercial Vehicle Administration CVCS Commercial Vehicle Check CVO Commercial Vehicle Operations CVS Commercial Vehicle DMS Dynamic Message Sign DMV Department of Motor Vehicles DOT Department of Transportation DPS Department of Public Safety DSRC Dedicated Short Range Communications E9-1-1 Enhanced 9-1-1 EM Emergency Management EMC Emergency Management Center EMS Emergency Medical Services EOC Emergency Operations Center EVS Emergency Vehicle FHWA Federal Highway Administration FMCSA Federal Motor Carrier Safety Administration FMS Fleet and Freight Management ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 157 Acronym Definition FTA Federal Transit Administration FTP File Transfer Protocol GIS Geographic Information System GPS Global Positioning System HAR Highway Advisory Radio HAZMAT HAZardous MATerial(s) HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IEEE Institute of Electrical and Electronics Engineers, Inc. ISO International Standards Organization ISP Information Service Provider ITE Institute of Transportation Engineers ITS Intelligent Transportation Systems MCMS Maintenance and Construction Management MCO Maintenance and Construction Operations MCVS Maintenance and Construction Vehicle MPH Miles per Hour MPO Metropolitan Planning Organization MS/ETMCC Message Set for External TMC Communication MTD Motor Transportation Division NEMA National Electrical Manufacturers Association NMDOT New Mexico Department of Transportation New Mexico Department of Public Safety NTCIP National Transportation Communications for ITS Protocol PIAS Personal Information Access PSAP Public Safety Answering Point RPO Regional Planning Organization RS Roadway RTD Regional Transit District RTS Remote Traveler Support SAE Society of Automotive Engineers SDO Standards Development Organization STIP State Transportation Improvement Program TAS Toll Administration TCIP Transit Communications Interface Profiles ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 158 Acronym Definition TCP Transport Control Protocol TDM Travel Demand Management TEA-21 Transportation Efficiency Act for the 21st Century TIP Transportation Improvement Program TMC Traffic Management Center TMDD Traffic Management Data Dictionary TMS Traffic Management TOC Traffic Operations Center TRMC Transit Management Center TRMS Transit Management TRVS Transit Vehicle USDOT United States Department of Transportation VMS Variable Message Sign VS Vehicle WAA Wide Area Alert WIM Weigh-in Motion WWW World Wide Web ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 159 Appendix B: Functional Requirements This appendix contains two tables describing the functions assigned to each of the major elements of the Farmington Regional ITS Architecture. Table 16 lists the functions (defined from the Turbo Architecture Database as Equipment Packages) assigned to each Element. Table 17 provides a definition of each of the functions defined in Table 16. In addition, these functions are further decomposed into a detailed listing of the functional requirements (defined as a set of “shall” statements) in a separate Excel spreadsheet. Table 16. Functions (Equipment Packages) Assigned to Architecture Elements Element Name Functional Area Aztec Field Devices Field Management Stations Operation, Roadway Basic Surveillance, Roadway Equipment Coordination, Roadway Field Device Monitoring, Roadway Incident Detection, Roadway Short Range Traveler Information Communications, Roadway Signal Controls, Roadway Work Zone Safety, Roadway Work Zone Traffic Control Aztec Fire On-board EV En Route Support, On-board EV Incident Management Communication Aztec Maintenance Vehicles MCV Roadway Maintenance and Construction, MCV Vehicle Location Tracking, MCV Vehicle Safety Monitoring, MCV Work Zone Support Aztec PD Emergency Vehicles On-board EV En Route Support, On-board EV Incident Management Communication Aztec Traffic Management Collect Traffic Surveillance, TMC Evacuation Support, TMC Incident Detection, TMC Incident Dispatch Coordination/Communication, TMC In-Vehicle Signing Management, TMC Regional Traffic Management, TMC Signal Control, TMC Work Zone Traffic Management, Traffic Equipment Maintenance Bloomfield Field Devices Field Management Stations Operation, Roadway Basic Surveillance, Roadway Equipment Coordination, Roadway Field Device Monitoring, Roadway Incident Detection, Roadway Short Range Traveler Information Communications, Roadway Signal Controls, Roadway Work Zone Safety, Roadway Work Zone Traffic Control Bloomfield Fire Engines On-board EV En Route Support, On-board EV Incident Management Communication Bloomfield Maintenance Vehicles MCV Roadway Maintenance and Construction, MCV Vehicle Location Tracking, MCV Vehicle Safety Monitoring, MCV Work Zone Support Bloomfield PD Emergency Vehicles On-board EV En Route Support, On-board EV Incident Management Communication ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 160 Element Name Functional Area Bloomfield Traffic Management Collect Traffic Surveillance, TMC Evacuation Support, TMC Incident Detection, TMC Incident Dispatch Coordination/Communication, TMC In-Vehicle Signing Management, TMC Regional Traffic Management, TMC Signal Control, TMC Work Zone Traffic Management, Traffic Equipment Maintenance Farmington Field Devices Field Management Stations Operation, Roadway Basic Surveillance, Roadway Equipment Coordination, Roadway Field Device Monitoring, Roadway Incident Detection, Roadway Short Range Traveler Information Communications, Roadway Signal Controls, Roadway Traffic Information Dissemination, Roadway Variable Speed Limits, Roadway Work Zone Safety, Roadway Work Zone Traffic Control Farmington Fire/Rescue Vehicles On-board EV En Route Support, On-board EV Incident Management Communication Farmington PD Emergency Vehicles On-board EV En Route Support, On-board EV Incident Management Communication Farmington Streets Vehicles MCV Roadway Maintenance and Construction, MCV Vehicle Location Tracking, MCV Vehicle Safety Monitoring, MCV Work Zone Support Farmington Traffic Operations Center Collect Traffic Surveillance, TMC Evacuation Support, TMC Incident Detection, TMC Incident Dispatch Coordination/Communication, TMC In-Vehicle Signing Management, TMC Probe Information Collection , TMC Regional Traffic Management, TMC Signal Control, TMC Traffic Information Dissemination, TMC Work Zone Traffic Management, Traffic Equipment Maintenance NMDOT District 5 TOC Collect Traffic Surveillance, TMC Environmental Monitoring, TMC Incident Detection, TMC In-Vehicle Signing Management, TMC Roadway Warning, TMC Traffic Information Dissemination, TMC Work Zone Traffic Management, Traffic Equipment Maintenance NMDOT Field Devices Field Management Stations Operation, Roadway Basic Surveillance, Roadway Environmental Monitoring, Roadway Field Device Monitoring, Roadway Incident Detection, Roadway Short Range Traveler Information Communications, Roadway Traffic Information Dissemination, Roadway Warning, Roadway Work Zone Safety, Roadway Work Zone Traffic Control NMDOT Maintenance Vehicles MCV Roadway Maintenance and Construction, MCV Vehicle Location Tracking, MCV Vehicle Safety Monitoring, MCV Work Zone Support Red Apple Transit Kiosks Remote Basic Information Reception, Remote Interactive Information Reception, Remote Transit Information Services ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 161 Element Name Functional Area Red Apple Transit Operations Center Transit Center Fixed-Route Operations, Transit Center Information Services, Transit Center Multi-Modal Coordination, Transit Center Security, Transit Center Vehicle Tracking, Transit Data Collection Red Apple Transit Vehicles On-board Transit Information Services, On-board Transit Security San Juan County Communications Center Emergency Call-Taking, Emergency Commercial Vehicle Response, Emergency Dispatch, Emergency Early Warning System, Emergency Evacuation Support, Emergency Response Management, Emergency Routing San Juan County EOC Emergency Early Warning System, Emergency Evacuation Support San Juan County Field Devices Field Management Stations Operation, Roadway Basic Surveillance, Roadway Equipment Coordination, Roadway Field Device Monitoring, Roadway Incident Detection, Roadway Short Range Traveler Information Communications, Roadway Signal Controls, Roadway Traffic Information Dissemination, Roadway Work Zone Safety, Roadway Work Zone Traffic Control San Juan County Fire Vehicles On-board EV En Route Support San Juan County Maintenance Vehicles MCV Roadway Maintenance and Construction, MCV Vehicle Location Tracking, MCV Vehicle Safety Monitoring, MCV Work Zone Support San Juan County Sheriffs Emergency Vehicles On-board EV En Route Support, On-board EV Incident Management Communication San Juan County Traffic Management Collect Traffic Surveillance, TMC Evacuation Support, TMC Incident Detection, TMC Incident Dispatch Coordination/Communication, TMC In-Vehicle Signing Management, TMC Regional Traffic Management, TMC Signal Control, TMC Work Zone Traffic Management, Traffic Equipment Maintenance Table 17 provides a definition of each of the Equipment Packages (functions) from the previous table. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 162 Table 17. Equipment Package Descriptions Equipment Package Description Collect Traffic Surveillance Management of traffic sensors and surveillance (CCTV) equipment, collection of current traffic conditions, and distribution of the collected information to other centers and operators. Emergency Call-Taking Provides interface to the emergency call-taking systems such as the Emergency Telecommunications System 911) that correlate call information with emergencies reported by transit agencies, commercial vehicle operators, or other public safety agencies. Allows the operator to verify the incident and forward the information to the responding agencies. Emergency Dispatch Dispatch emergency vehicles to incidents, tracking their location and status. Pertinent incident information is gathered and relayed to the responding units. Emergency Early Warning System Monitors alerting and advisory systems, information collected by ITS surveillance and sensors, and reports from other agencies in order to identify potential, imminent, or in-progress major incidents or disasters. Notification is provided to other ITS centers to notify the traveling public. Emergency Evacuation Support Evacuation planning and coordination to manage evacuation and reentry of a population in the vicinity of a disaster or other emergency that poses a risk to public safety. Emergency Response Management Strategic emergency planning and response capabilities and broad inter- agency interfaces to support large-scale incidents and disasters, commonly associated with Emergency Operations Centers. Emergency Routing Routing of emergency vehicles to facilitate the quickest/safest arrival. Routes may be determined based on real-time traffic information and road conditions or routes may be provided by Traffic Management on request. Incident Command Tactical decision support, resource coordination, and communications integration among emergency management agencies for Incident Commands that are established by first responders to support local management of an incident. MCV Roadway Maintenance and Construction On-board systems that support routine non-winter maintenance on the roadway or right-of-way. Includes landscape maintenance, hazard removal (roadway debris, dead animals), routine maintenance activities (roadway cleaning, grass cutting), and repair and maintenance of equipment on the roadway. MCV Vehicle Location Tracking On-board systems to track vehicle location and reports the position and timestamp information to the dispatch center. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 163 Equipment Package Description MCV Vehicle Safety Monitoring On-board systems to detect vehicle intrusions and warn crew workers and drivers of imminent encroachment. Crew movements are monitored so that the crew can be warned of movement beyond the designated safe zone. Used for stationary work zones or in mobile applications where a safe zone is maintained around the moving vehicle. MCV Work Zone Support On-board systems that provide communications and support for local management of a work zone. On-board EV En Route Support On-board systems for gathering of dispatch and routing information for emergency vehicle personnel, vehicle tracking, communications with care facilities, and signal preemption via short range communication directly with traffic control equipment at the roadside. On-board EV Incident Management Communication On-board systems provide communications support to first responders. Incident information is provided to dispatched emergency personnel. Emergency personnel transmit information about the incident and response status. On-board Transit Information Services On-board systems to furnish next-stop annunciation as well as interactive travel-related information, including routes, schedules, transfer options, fares, real-time schedule adherence, current incidents, weather conditions, non-motorized transportation services, and special events. On-board Transit Security On-board video/audio surveillance systems, threat sensors, and object detection sensors to enhance security and safety on-board a transit vehicles. Also includes silent alarms activated by transit user or vehicle operator, operator authentication, and remote vehicle disabling. Personal Basic Information Reception Personal traveler interface that provides formatted traffic advisories, transit, event, and other traveler information, as well as broadcast alerts. Devices include personal computers and personal portable devices such as smartphones and pagers. Personal Interactive Information Reception Personal traveler interface that provides traffic, transit, yellow pages, event, and trip planning information, and other personalized traveler information services upon request. Devices include personal computers and personal portable devices such as smartphones. Rail Operations Coordination Coordination between rail operations and traffic management centers - exchanging train schedules, maintenance schedules, as well as incidents and priority messages that impact highway-rail intersections (HRIs. Supports advanced traffic control strategies and enhanced traveler information. Remote Basic Information Reception Public traveler interface, such as a kiosk, that provides formatted traffic advisories, transit, event, and other traveler information, as well as broadcast alerts. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 164 Equipment Package Description Remote Interactive Information Reception Public traveler interface, such as a kiosk, that provides traffic, transit, yellow pages, special event, and other personalized traveler information services upon request. Remote Transit Information Services Public traveler interface that provides real-time travel-related information at transit stops and multi-modal transfer points, including general annunciation, display of imminent arrival information, the latest available information on transit routes, schedules, transfer options, available services, fares, and real-time schedule adherence. Roadway Basic Surveillance Field elements that monitor traffic conditions using loop detectors and CCTV cameras. Roadway Environmental Monitoring Environmental sensors, surface and sub-surface, that collect weather and road surface information. Weather conditions measured include temperature, wind, humidity, precipitation, and visibility. Sensors measure road surface temperature, moisture, icing, salinity, etc. Roadway Equipment Coordination Field elements that control and send data to other field elements (such as environmental sensors that send data to a DMS or coordination between traffic controllers on adjacent intersections), without center control. Roadway Field Device Monitoring Monitors field equipment operational status and detects and reports fault conditions. Device status, configuration, and fault information are provided to a remote center and a user interface provides information locally to field personnel. Roadway Signal Controls Field elements including traffic signal controllers for use at signalized intersections; also supports pedestrian crossings. Roadway Signal Preemption Field elements that receive signal preemption requests from approaching emergency vehicles and overrides the current operation of the traffic signals Roadway Traffic Information Dissemination Driver information systems, such as dynamic message signs and Highway Advisory Radio (HAR). Roadway Work Zone Safety Work zone intrusion detection devices (to detect vehicle intrusion upon a work zone or crew worker movement across a work zone boundary) and intrusion alerting devices that provide alerts to crew and drivers. Roadway Work Zone Traffic Control Field elements in maintenance and construction areas including CCTV cameras, driver information systems (such as DMS), and gates/barriers that monitor and control traffic and provide information directly to drivers in affected areas. TMC Environmental Monitoring Management of environmental sensors and assimilation of collected data with other current and forecast road conditions and surface weather information from weather service providers and roadway maintenance operations. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 165 Equipment Package Description TMC Incident Detection Remotely monitors traffic sensor and surveillance systems to detect and verify incidents. Also monitors external advisory and incident reporting systems, intermodal freight depots, and border crossings for additional incident information. Identified incidents are reported to operations personnel and other centers. TMC Multimodal Coordination Provides traffic signal priority for transit vehicles based on center-to-center communications with the transit management center; also exchange traffic and transit information. TMC Probe Information Collection Collects, assimilates, and disseminates vehicle probe data collected from roadside beacons and centers controlling transit vehicles, emergency vehicles, toll collection points, and route-guided vehicles. TMC Regional Traffic Management Coordination between traffic management centers in order to share traffic information between centers as well as control of traffic management field equipment. This may be used during incidents and special events and during day-to-day operations. TMC Signal Control Remotely controls traffic signal controllers to implement traffic management strategies at signalized intersections based on traffic conditions, incidents, emergency vehicle preemptions, pedestrian crossings, etc. TMC Traffic Information Dissemination Controls dissemination of traffic-related data to other centers, the media, and travelers via the driver information systems (DMS, HAR) that it operates. Traffic Equipment Maintenance Monitoring and remote diagnostics of field equipment - detect failures, issue problem reports, and track the repair or replacement of the failed equipment. Transit Center Fixed-Route Operations Management of fixed route transit operations. Planning, scheduling, and dispatch associated with fixed and flexible route transit services. Updates customer service operator systems, and provides current vehicle schedule adherence and optimum scenarios for schedule adjustment. Transit Center Information Services Provide interactive traveler information to travelers (on-board transit vehicles, at stops/stations, using personal devices), traveler information service providers, media, and other transit organizations. Includes routes, schedules, transfer options, fares, real-time schedule adherence, current incidents, weather conditions, yellow pages, and special events. Transit Center Multi-Modal Coordination Coordinate schedules with other agencies and modes, including transit transfer cluster and transfer point information. Transit Center Security Monitor transit vehicle operator or traveler activated alarms; authenticate transit vehicle operators; remotely disable a transit vehicle; alert operators, travelers, and police to potential incidents identified by these security features. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 166 Equipment Package Description Transit Center Vehicle Tracking Monitoring transit vehicle locations via interactions with on-board systems. Furnish users with real-time transit schedule information and maintain interface with digital map providers. Transit Data Collection Collection and storage of transit management data. For use by operations personnel or data archives in the region. ---PAGE BREAK--- Farmington Regional ITS Architecture Update Page 167 Appendix C: Maintenance Request Form Farmington Regional ITS Architecture Maintenance Change Request (MCR) Form To Be Completed By Stakeholder(s) Requesting Changes Originator Name: Date Submitted Originator Telephone: Originator Fax: Originator E-Mail: Originator Agency: Functional Area: Agency Authorized Signature: Signature Date: Description of Proposed Change: Rationale for Proposed Change: Affected Agency: Authorized Signature: Signature Date: Affected Agency: Authorized Signature: Signature Date: List Attachments: Baseline Documents Affected: Website ______Turbo Architecture ______Customized MPs ______Arch Document ______Other (describe) To Be Completed By Maintenance Manager Change Request Number: Date CR Received: Date CR Logged: Date Initially Discussed: Disposition: Accepted Rejected More Info Disposition Comments Date Discussed: Disposition: Accepted Rejected More Info Disposition Comments Date Discussed: Disposition: Accepted Rejected More Info Disposition Comments Date of Maintenance Working Group Approval (If Applicable): Baseline Documents Affected/Version implemented Turbo Architecture Date: Version: Website Date: Version: Customized MPs Date: Version: Date: Version: Architecture Doc Date: Version: Date: Version: