grand region its architecture - michigan

Michigan Department of TransportationRegional ITS Architectures and Deployment Plans

Grand Region

FinalRegional ITS Architecture

Prepared by:

In association with:

January 24, 2008012578004

Copyright © 2008 by Kimley-Horn and Associates, Inc. All rights reserved.

TABLE OF CONTENTSFINAL REGIONAL ITS ARCHITECTURE REPORT – GRAND REGION

1/24/2008 Grand Regioni Final Regional ITS Architecture

1. INTRODUCTION .......................................................................................................................... 11.1 Project Overview .................................................................................................................. 11.2 Document Overview.............................................................................................................. 21.3 Assessment ............................................................................................................................ 21.4 The Grand Region ................................................................................................................ 3

1.4.1 Geographic Overview....................................................................................................... 31.4.2 Transportation Infrastructure ........................................................................................... 41.4.3 Grand Region ITS Plans................................................................................................... 61.4.4 Stakeholders ..................................................................................................................... 6

2. REGIONAL ITS ARCHITECTURE DEVELOPMENT PROCESS ....................................................... 9

3. CUSTOMIZATION OF THE NATIONAL ITS ARCHITECTURE FOR THE GRAND REGION ............ 113.1 Systems Inventory............................................................................................................... 113.2 Regional Needs.................................................................................................................... 123.3 Element Customization....................................................................................................... 12

3.3.1 Subsystems and Terminators........................................................................................... 123.3.2 ITS Inventory by Stakeholder .......................................................................................... 133.3.3 Top Level Regional System Interconnect Diagram .......................................................... 24

3.4 Market Packages................................................................................................................. 263.4.1 Selection and Prioritization of Regional Market Packages .............................................. 263.4.2 Customized Market Packages ......................................................................................... 283.4.3 Regional ITS Needs and Customized Market Packages ................................................... 28

3.5 Architecture Interfaces ....................................................................................................... 303.5.1 Element Connections ...................................................................................................... 303.5.2 Data Flows Between Elements ........................................................................................ 31

4. APPLICATION OF THE REGIONAL ITS ARCHITECTURE........................................................... 354.1 Functional Requirements ................................................................................................... 354.2 Standards ............................................................................................................................ 354.3 Operational Concepts ......................................................................................................... 384.4 Potential Agreements .......................................................................................................... 454.5 Phases of Implementation................................................................................................... 47

5. USE AND MAINTENANCE PLAN FOR THE REGIONAL ITS ARCHITECTURE.............................. 485.1 Process for Determining Architecture Conformity............................................................ 485.2 Maintenance Process .......................................................................................................... 495.3 Procedure for Submitting ITS Architecture Changes Between Scheduled Updates ........ 50

APPENDIX A – NATIONAL ITS ARCHITECTURE MARKET PACKAGE DEFINITIONS

APPENDIX B – CUSTOMIZED MARKET PACKAGES

APPENDIX C – ELEMENT FUNCTIONAL REQUIREMENTS

APPENDIX D – STAKEHOLDER DATABASE

APPENDIX E – ARCHITECTURE MAINTENANCE DOCUMENTATION FORM

TABLE OF CONTENTSFINAL REGIONAL ITS ARCHITECTURE REPORT – GRAND REGION

1/24/2008 Grand Regionii Final Regional ITS Architecture

LIST OF FIGURES

Figure 1 - Grand Regional Boundaries .................................................................................................. 5Figure 2 - Grand Regional ITS Architecture and Deployment Plan Development Process...................... 9Figure 3 - National ITS Architecture Physical Subsystem Interconnect Diagram ................................. 13Figure 4 - Grand Regional System Interconnect Diagram .................................................................... 25Figure 5 - Example Market Package Diagram: Surface Street Control ................................................ 28Figure 6 - Example Interconnect Diagram: MDOT MI Drive Website ................................................. 30Figure 7 - Example Flow Diagram: ATMS03 – Surface Street Control for MDOT Traffic Signal

System............................................................................................................................... 31Figure 8 - Example Flow Diagram: ATMS06 – Traffic Information Dissemination – MDOT West

Michigan TMC.................................................................................................................. 32Figure 9 - Example Two Element Flow Diagram................................................................................. 33Figure 10 - Example Context Flow Diagram: MDOT Traveler Information Database ......................... 34Figure 11 - Process for Documenting Architecture Performance.......................................................... 52

LIST OF TABLES

Table 1 - Summary of Architecture Assessment Categories ................................................................... 3Table 2 - Grand Stakeholder Agencies and Contacts.............................................................................. 6Table 3 - Comparison of Stakeholder Names with Existing Architecture ............................................. 11Table 4 - Grand Region Stakeholder Descriptions ............................................................................... 14Table 5 - Grand Region Inventory of ITS Elements ............................................................................. 15Table 6 - Grand Region Market Package Prioritization by Functional Area.......................................... 27Table 7 - Regional ITS Needs and Corresponding Market Packages .................................................... 29Table 8 - Grand Region Applicable ITS Standards .............................................................................. 36Table 9 - Grand Region Stakeholder Roles and Responsibilities .......................................................... 39Table 10 - Grand Region Potential Agreements ................................................................................... 46Table 11 - Regional ITS Architecture and Deployment Plan Maintenance Summary ........................... 50

LIST OF ACRONYMS

1/24/2008 Grand Regioniii Final Regional ITS Architecture

AASHTO American Association of State Highway and Transportation Officials

AD Archived Data

AHS Automated Highway System

AMBER America’s Missing: Broadcast Emergency Response

ANSI American National Standards Institute

APTS Advanced Public Transportation Systems

ATIS Advanced Travel Information System

ATMS Advanced Traffic Management System

AVL Automated Vehicle Location

CCTV Closed Circuit Television

CJIC Criminal Justice Information Center

CRC County Road Commission

CVISN Commercial Vehicle Information Systems and Networks

DCM Data Collection and Monitoring

DMS Dynamic Message Sign

DNR Department of Natural Resources

DPW Department of Public Works

EM Emergency Management

EMS Emergency Medical Services

EOC Emergency Operations Center

FHWA Federal Highway Administration

FTA Federal Transit Administration

HAR Highway Advisory Radio

HAZMAT Hazardous Materials

HRI Highway Rail Intersection

IDAS ITS Deployment Analysis Software

IEEE Institute of Electrical and Electronics Engineers

IMMS Incident Management Message Sets

LIST OF ACRONYMS

1/24/2008 Grand Regioniv Final Regional ITS Architecture

ISO International Standards Organization

ISP Information Service Provider

ITE Institute of Transportation Engineers

ITS Intelligent Transportation System

MAC Medium Access Control

MATS Muskegon Area Transit System

MAX Macatawa Area Express

MC Maintenance and Construction

MDOT Michigan Department of Transportation

MDT Mobile Data Terminal

MITSC Michigan Intelligent Transportation Systems Center

MOU Memorandum of Understanding

MSP Michigan State Police

NEMA National Emergency Management Association

NOAA National Oceanic and Atmospheric Administration

NTCIP National Transportation Communications for ITS Protocol

NWS National Weather Service

RWIS Roadway Weather Information System

SAE Society of Automotive Engineers

SAFETEA-LU Safe, Accountable, Flexible, Efficient Transportation Equity Act –A Legacy for Users

SDO Standards Development Organization

STMF Simple Transportation Management Framework

TCP/IP Transmission Control Protocol/Internet Protocol

TEA-21 Transportation Equity Act for the 21st Century

TIP Transportation Improvement Program

TMC Transportation Management Center

TOC Traffic Operations Center

LIST OF ACRONYMS

1/24/2008 Grand Regionv Final Regional ITS Architecture

TSC Transportation Service Centers

UDP/IP User Datagram Protocol/Internet Protocol

USDOT United States Department of Transportation

VIVDS Vehicle Imaging Video Detection Systems

XML Extensible Mark-up Language

1/24/2008 Grand Region1 Final Regional ITS Architecture

1. INTRODUCTION

1.1 Project Overview

Development of a regional intelligent transportation system (ITS) architecture is one of the mostimportant steps in planning for and implementing ITS in a region. ITS architectures provide aframework for implementing ITS projects, encourage interoperability and resource sharingamong agencies, identify applicable standards to apply to projects, and allow for cohesive long-range planning among regional stakeholders. The ITS architecture allows stakeholders to plan forwhat they want their system to look like in the long-term, and then break out the system intosmaller, more modular pieces that can be implemented over time as funding permits.

ITS architectures satisfy the conformity requirements first established in the TransportationEquity Act for the 21st Century (TEA-21) highway bill and continued in the Safe, Accountable,Flexible, Efficient Transportation Equity Act: A Legacy for Users (SAFETEA-LU) bill passed in2005. In response to Section 5206(e) of TEA-21, the Federal Highway Administration (FHWA)issued a final rule and the Federal Transit Administration (FTA) issued a final policy thatrequired regions implementing any ITS projects using federal funds to have an ITS architecture inplace by April 2005. After this date, any ITS projects must show conformance with their regionalITS architecture in order to be eligible for funding from FHWA or FTA. Regions that had not yetdeployed ITS were given four years to develop an ITS architecture after their first ITS projectproceeded to final design.

In November 2006, the Michigan Department of Transportation (MDOT) began development ofthe Grand Regional ITS Architecture. The Regional ITS Architecture has the same geographicboundaries of the MDOT Grand Region Metropolitan Area, but excludes the Grand Rapidsmunicipal area, which completed a Strategic Deployment Plan and Regional Architecture inFebruary 2006. The Grand Regional ITS Architecture references the Grand Rapids MetropolitanArea ITS Strategic Deployment Plan (HNTB and Iteris, February 2006) and the Grand RegionITS Architecture completed in 2002. Key portions of this document will show how the GrandRegion will integrate with the Grand Rapids Metropolitan Area. The Regional Architecturefocuses on a 10-year vision of ITS for the Grand Region and dovetails with the existing GrandRapids Metropolitan Area Regional ITS Architecture. In addition, a separate ITS DeploymentPlan was developed to identify and prioritize specific ITS projects recommended for the Regionin order to implement the ITS architecture. The ITS Deployment Analysis Software (IDAS) wasutilized to evaluate and prioritize the list of ITS projects outlined for the Grand Region.

The ITS Architecture and the ITS Deployment Plan were both developed with significant inputfrom local, state, and federal officials. A series of four workshops were held to solicit input fromstakeholders and ensure that the plans reflected the unique needs of the Region. Copies of thedraft reports were provided to all stakeholders. The Regional ITS Architecture and DeploymentPlan developed reflects an accurate snapshot of existing ITS deployments and future ITS plans inthe Region. Needs and priorities of the Region will change over time and in order to remaineffective this plan should be periodically reviewed and updated.


1.2 Document Overview

The Grand Regional ITS Architecture report is organized into five key sections:

Section 1 – Introduction

This section provides an overview of the National ITS Architecture requirements, the GrandRegional ITS Architecture, and the key features and stakeholders in the Grand Region.

Section 2 – Regional ITS Architecture Development Process

An overview of the key steps involved in developing the ITS Architecture for the Grand Regionis provided in this section. It includes a discussion of stakeholder involvement, architectureworkshops, and the architecture development process.

Section 3 – Customization of the National ITS Architecture for the Grand Region

This section contains a summary of regional needs and details the customization of the NationalITS Architecture to meet the ITS vision for the Grand Region. The market packages that wereselected for the Region are included in this section and interconnects are presented, including the“sausage diagram” showing the relationships of the key subsystems and elements in the Region.

Section 4 – Application of the Regional ITS Architecture

Functional requirements and standards that apply to the Region, as indicated by the Regional ITSArchitecture, are presented in Section 4. Operational concepts identifying stakeholder roles andresponsibilities have been prepared and potential agreements to support the sharing of data andresources have been identified.

Section 5 – Maintaining the Regional ITS Architecture

A use and maintenance plan has been developed for the Grand Regional ITS Architecture and isincluded in this section. The plan outlines the procedure for updating the ITS architecture overtime.

The Grand Regional ITS Architecture also contains five appendices:

Appendix A – National ITS Architecture Market Package Definitions;Appendix B – Customized Market Packages;Appendix C – Element Functional Requirements;Appendix D – Stakeholder Database; andAppendix E – Architecture Conformance and Maintenance Documentation Form.

1.3 Assessment

The Grand Regional ITS Architecture and Deployment Plan has been assessed based on twelveitems derived from both the April 8, 2001 USDOT ITS Architecture and Standards ConformityRule/Policy and from the architecture development process described in the Regional ITSArchitecture Guidance Document. A listing of these items is shown in Table 1.


Table 1 - Summary of Architecture Assessment Categories

Content Criteria

1. Architecture Scope2. Stakeholder Identification3. System Inventory4. Needs and Services5. Operational Concept6. Functional Requirements7. Interfaces/Flows

Architecture Implementation Criteria

8. Implementation Plan (use)9. Maintenance Plan10. Agreements11. Standards Identification12. Project Sequencing

1.4 The Grand Region

1.4.1 Geographic Overview

The Grand Region is defined by the boundary of Lake Michigan to the west, the MDOTNorth Region to the north, the MDOT Bay Region to the east, and the MDOT SouthwestRegion to the south, as shown in Figure 1. The Region encompasses 7 of the 8 counties ofthe MDOT Grand Region of Michigan. The region excludes the Grand RapidsMetropolitan Area, which is comprised of Kent County and portions of Ottawa County.

Since the Grand Rapids Metropolitan Area is excluded from this architecture development,the largest cities within the geographical boundaries of the Grand Region includeMuskegon, Grand Haven, and Holland. When developing the stakeholder group, theproject team coordinated with MDOT to invite the appropriate townships, cities, counties,state and federal agencies, and area transit providers. The Muskegon Area Transit System(MATS), Macatawa Area Express (MAX), and Ionia Transit Authority are the primarytransit providers that operate within the regional boundaries. The Muskegon Area TransitSystem provides fixed route and paratransit service within Muskegon County. TheMacatawa Area Express operates fixed route and paratransit coverage for the City ofHolland, Holland Charter Township, and the City of Zeeland. The Ionia Transit Authorityprovides demand-response and advance reservation service to the City of Ionia and thetownships of Berlin, Easton, and Ionia. Table 2 in Section 1.3.4 identifies the stakeholdersthat participated in the process.

When developing the architecture, a 20-year vision for ITS in the Region was documented.In the ITS Deployment Plan, the 20-year time frame was broken down into smaller timeperiods to prioritize and sequence the projects. The naming convention used for elements inthe Grand Regional ITS Architecture is consistent with the naming convention that is usedin the North, Bay, Superior, and Southwest Regions and the Statewide ITS Architecture.Naming conventions inconsistent with the existing Grand Rapids Metropolitan AreaRegional ITS Architecture are also clarified within this architecture. This consistencyprovides seamless connections to those other architectures without requiring that they bespecifically called out. Statewide initiatives - such as statewide commercial vehicleoperations and 511 traveler information service - are referenced in the regional ITSarchitecture, but will be addressed in further detail in the Statewide ITS Architecture.


1.4.2 Transportation Infrastructure

As illustrated in Figure 1, the Region is connected by several State and Federal highways.The primary roadway facilities in the study area include US 131, US 31, I-96, I-196, and M46.

US 131 is one of the major north-south roadways that connects Grand Rapids withKalamazoo in the Southwest Region and Cadillac in the North Region. M 46 runsconcurrently with US 131 for a short span, but primarily runs east-west beginning in theMuskegon area and traversing east across the Region towards Saginaw in the Bay Region.US 31 is a major north-south route that runs along the Lake Michigan coast connecting theHolland – Macatawa area with the Muskegon area. I-96 runs east-west across the southernedge of the region connecting traffic traveling westbound from Lansing to the Muskegonarea. I-196 breaks off of I-96 in Grand Rapids and runs southwest to the Holland –Macatawa area on Lake Michigan.

1/24/2008

Figure 1 - Grand Regional Boundaries


1.4.3 Grand Region ITS Plans

The Grand Region began the development of a Regional ITS Architecture in 2006 whenMDOT contracted with a consultant to develop several regional ITS architectures anddeployment plans in the State of Michigan. Version 5.1 of the National ITS Architecturewas used in the Architecture development.

It is important to recognize the initial deployment of ITS infrastructure in a region becauseas of April 2005, in order for a region to be eligible for funding for ITS projects from theHighway Trust Fund the United States Department of Transportation (USDOT) requiresthat the region have an ITS architecture developed. This requirement only applies toregions with existing ITS infrastructure deployed. For regions that do not have any ITSinfrastructure deployed, the USDOT requires that they have an ITS architecture within fouryears of their first ITS project entering final design.

The Grand Region excludes the Grand Rapids Metropolitan Area from the RegionalBoundaries since this region already has an ITS Regional Architecture completed in 2002and a Strategic Deployment Plan updated in February 2006. The Grand RapidsMetropolitan Area consists of several significant deployments, but those ITS componentsare also excluded from this architecture. The Grand Region has several ITS componentsdeployed outside of the Grand Rapids Metropolitan area. Examples of implementations inthe Region include closed loop signal systems, portable dynamic message signs (DMS), andweigh-in-motion sensors. As the Grand Region pursues funding opportunities for proposedprojects, it will be necessary to show that a project fits within the ITS architecturedeveloped for the Region.

1.4.4 Stakeholders

Due to the fact that ITS often transcends traditional transportation infrastructure, it isimportant to involve non-traditional stakeholders in the architecture development andvisioning process. Input from these stakeholders, both public and private, is a critical partof defining the interfaces, integration needs, and overall vision for ITS in a region.

Table 2 contains a listing of stakeholders in the Grand Region who have participated in theproject workshops or provided input to the study team as to the needs and issues that shouldbe considered as part of the Regional ITS Architecture. Other stakeholders that wereinvited to participate but were not able to attend were provided minutes of workshops andcopies of reports to encourage their participation as much as possible. Appendix Dcontains a copy of the stakeholder database and workshop attendance records.

Table 2 - Grand Stakeholder Agencies and Contacts

Stakeholder Agency Address Contact

City of Belding, Dial-A-Ride 100 Depot StreetBelding, Michigan 48809

Suzanne Christensen

City of Big Rapids Public Works 226 North Michigan AvenueBig Rapids, Michigan 49307

Tim Vogel

City of Grand Haven, HarborTransit

519 Washington AvenueGrand Haven, Michigan 49417

Julie Bildner

City of Newaygo 28 State RoadNewaygo, Michigan 49337

Ron Wight

FHWA - HDA-MT 400 Seventh Street, SWWashington DC 20590

Tim Crothers




FHWA - Michigan 315 West Allegan, Suite 201Lansing, Michigan 48933

Morrie Hoevel

Grand Haven Public Safety 525 Washington AvenueGrand Haven, Michigan 49471

Mark Reiss

Grand Haven Streets & Utilities 519 Washington AvenueGrand Haven, Michigan 49471

William Hunter

Macatawa Area CoordinatingCouncil

400 136th Avenue, Suite 416Holland, Michigan 49424

Steve Bulthuis

MDOT 425 West Ottawa StreetMail Code B235Lansing, Michigan 48933

Mike Walimaki

MDOT - Grand Rapids TSC 2660 Leonard Street, NEGrand Rapids, Michigan 49525

Paul Arends

MDOT - Grand Region 1420 Front Avenue, N.W.Grand Rapids, Michigan 49504

Joseph Finch


Suzette Peplinski


Steven Redmond

MDOT - Howard City TSC 19153 West Howard City-EdmoreRoadHoward City, Michigan 49329

Karl Koivisto

MDOT - Howard City TSC 19153 West Howard City-EdmoreRoadHoward City, Michigan 49329

Sarah Huffman

MDOT - ITS Program Office 18101 West Nine Mile RoadSouthfield, Michigan 48075

Collin Castle

MDOT - ITS Program Office 425 West Ottawa StreetMail Code B235Lansing, Michigan 48933

Greg Krueger

MDOT - Muskegon TSC 2225 Olthoff DriveMuskegon, Michigan 49444

David Brinks

MDOT - Muskegon TSC 2225 Olthoff DriveMuskegon, Michigan 49444

Tim Judge

MDOT - Southwest Region 1501 Kilgore RoadKalamazoo, Michigan 49001

David VanStensel

Mecosta County RoadCommission

120 North DeKraft AvenueBig Rapids, Michigan 49307

Nick Petersen

MSP - 6th District 588 Three Mile RoadGrand Rapids, Michigan 49544

Doug Roesler

MSP - 6th District Motor CarrierDivision

588 Three Mile RoadGrand Rapids, Michigan 49544

Alfred Newell

Muskegon Area Transit System 2624 Sixth StreetMuskegon Heights, Michigan 49444

James Koens

Ottawa County RoadCommission

PO Box 739Ottawa, Michigan 49417

Jerry Diekema

Ottawa County RoadCommission

PO Box 739Ottawa, Michigan 49417

Fred Keena




Total Traffic Network 77 Monroe Center, Suite 1000Grand Rapids, Michigan 49505

Robb Westaby

URS 3950 Sparks Drive, SEGrand Rapids, Michigan 49546

Marcus Byker

URS 3950 Sparks Drive, SEGrand Rapids, Michigan 49546

Marc Start


2. REGIONAL ITS ARCHITECTURE DEVELOPMENT PROCESSDevelopment of the Regional ITS Architecture and Deployment Plan for the Grand Region reliedheavily on stakeholder input to ensure that the architecture reflected local needs. A series of fourworkshops was held with stakeholders to gather input, and draft documents were made available tostakeholders for review and comment.

The process followed for the Grand Region was designed to ensure that stakeholders could provideinput and review for the development of the Region’s ITS Architecture and Deployment Plan. Figure 2illustrates the process followed.

Figure 2 - Grand Regional ITS Architecture and Deployment Plan DevelopmentProcess

A total of four workshops with stakeholders over a period of eleven months were used to develop theGrand Regional ITS Architecture and Deployment Plan. These workshops included:

Kick-Off Workshop, December 5, 2006;Regional ITS Architecture Development Workshop, January 17, 2007;ITS Deployment Plan Workshop, August 2, 2007; andComment Resolution Workshop, December 4, 2007.

Key components of the process are described below:

Task 1 – Kick-Off Workshop and ITS Needs: A stakeholder group was identified that includedrepresentatives from regional transportation, transit, and emergency management/public safety agencies.The group was invited to the project Kick-Off Workshop where ITS needs for the Region wereidentified.

Task 2 – System Inventory: Collecting information for the system inventory began at the Kick-OffWorkshop through discussions with the stakeholders to determine existing and planned ITS elements inthe Region. After the Kick-Off Workshop, follow-up calls were conducted with several localstakeholders to gather additional input.

Task 3 – ITS Architecture Workshop and ITS Architecture Development: The purpose of theRegional ITS Architecture Workshop was to review the system inventory with stakeholders and developthe Grand Regional ITS Architecture. Training on the National ITS Architecture was integrated into the

Kick-offWorkshopand ITSNeeds

ITS DeploymentPlan Workshop and

ITS DeploymentPlan Development

CommentResolutionWorkshopand FinalReport

System Inventory

ITSArchitectureWorkshop

andITS

ArchitectureDevelopment


workshop so that key elements of the architecture, such as market packages, could be explained prior tothe selection and editing of these elements. The result of the Regional ITS Architecture Workshop wasan ITS Architecture for the Grand Region that included a system inventory, interconnect diagram,customized market packages, and relevant ITS standards. Following the workshop, a Revised DraftRegional ITS Architecture document was prepared and sent to stakeholders for review and comment.

Task 4 – ITS Deployment Plan Workshop and ITS Deployment Plan Development: A draft projectlisting for the Region was presented to stakeholders at the Regional ITS Deployment Plan Workshop.Stakeholders were asked to provide input on the recommended projects, responsible agencies,associated costs, and deployment timeframe. Following the workshop, a Draft Regional ITSDeployment Plan document was prepared and sent to stakeholders for review and comment.

Task 5 – Comment Resolution Workshop and Final Report: A Comment Resolution Workshop washeld with stakeholders to review the Draft Regional ITS Architecture and the Draft Regional ITSDeployment Plan. Next steps for the Region were also discussed. Comments were incorporated and afinal Regional ITS Architecture and Regional ITS Deployment Plan were developed.


3. CUSTOMIZATION OF THE NATIONAL ITS ARCHITECTURE FORTHE GRAND REGION

Coordination with the existing Grand Rapids Metropolitan Area Strategic Deployment Plan and ITSRegional Architecture warrants that stakeholders and stakeholder agencies included in botharchitectures be clearly identified. There were five agencies identified in the Grand RapidsMetropolitan Area Architecture that were also included in the Grand Region ITS Regional Architecture.These stakeholders and their corresponding names are listed in Table 3.

Table 3 - Comparison of Stakeholder Names with Existing Architecture

Grand Regional ITS Architecture Grand Rapids Metropolitan Area StrategicDeployment Plan

West Michigan TMC Grand Rapids Metro ITS Operations CenterMDOT Grand Region Office MDOT Grand Region OfficeMSP District 6 Dispatch – Rockford Michigan State Police PostLocal Agency Ottawa County Road CommissionLocal Agency Ottawa County 911 Dispatch

Since the existing Grand Rapids Plan is being utilized for several deployments, it was not updated aspart of this project. As ITS grows in the Grand Region, both plans will warrant updates and continuedmaintenance. It is recommended that the next update of the Grand Rapids Metropolitan Area include allof the Grand Region and merge these two documents. It also is recommended that a single architecturedatabase and a single deployment plan be created at the time of the update.

3.1 Systems Inventory

An important initial step in the architecture development process is to establish an inventory ofexisting ITS elements. At the Kick-Off Workshop and through subsequent discussions withagency representatives, Grand Region stakeholders provided the team with information aboutexisting and planned systems that would play a role in the Region’s ITS architecture.

The National ITS Architecture has eight groups of ITS service areas. Existing, planned, andfuture systems in the Region were identified in the following service areas:

Traffic Management – includes the West Michigan Transportation Management Centerlocated in Grand Rapids as well as other existing and future TMCs and traffic operationscenters (TOCs), detection systems, closed circuit television (CCTV) cameras, fixed andportable dynamic message signs, and other related technologies.Emergency Management – includes emergency operations/management centers, improvedinformation sharing among traffic and emergency services, automated vehicle location (AVL)on emergency vehicles, traffic signal preemption for emergency vehicles, and wide-areaalerts.Maintenance and Construction Management – includes work zone management, roadwaymaintenance and construction information, winter maintenance, and road weather detectionsystems.Public Transportation Management – includes transit and paratransit AVL, dispatchsystems, transit travel information systems, electronic fare collection, and transit security.


Commercial Vehicle Operations – includes coordination with Commercial VehicleInformation Systems and Networks (CVISN) efforts, and hazardous material (HAZMAT)management.Traveler Information – includes broadcast traveler information such as 511, travelerinformation kiosks, and highway advisory radio (HAR).Archived Data Management – includes electronic data management and archiving systems.Vehicle Safety – includes collision avoidance and automated highway systems.

3.2 Regional Needs

Needs from the Region were identified by Stakeholders at the Kick-Off Workshop held inDecember of 2006. The needs identified provided guidance for determining which marketpackages should be included in the architecture. Stakeholders identified ITS needs for the GrandRegion in the following areas:

Traffic management;Emergency management;Maintenance and construction management;Public transportation management;Commercial vehicle operations;Traveler information; andArchived data management.

Section 3.4.3 contains additional information about the specific needs identified and relates thoseneeds to the market packages that document the corresponding ITS service.

3.3 Element Customization

The inventory and needs documented at the Kick-Off Workshop are the starting point fordeveloping an ITS architecture for the Grand Region. These ITS systems and components areused to customize the National ITS Architecture and create the Architecture for the GrandRegion.

When developing customized elements, the stakeholder group agreed not to create individualtraffic, maintenance, and emergency management elements for individual cities within the GrandRegion. The smaller communities in the Region were documented as part of the local agencyelements. This documentation allows the communities to be included in the Regional ITSArchitecture, and therefore eligible to use federal monies on potential future ITS deployments.

3.3.1 Subsystems and Terminators

Each identified system or component in the Grand Region ITS inventory was mapped to asubsystem or terminator in the National ITS Architecture. Subsystems and terminators arethe entities that represent systems in ITS.

Subsystems are the highest level building blocks of the physical architecture, and theNational ITS Architecture groups them into four major classes: Centers, Field, Vehicles,and Travelers. Each of these major classes includes various components that represent a setof transportation functions (or processes). Each set of functions is grouped under oneagency, jurisdiction, or location, and correspond to physical elements such as: trafficoperations centers, traffic signals, or vehicles. Figure 3 shows the National ITSArchitecture subsystems. This figure, also known as the “sausage diagram,” is a standardinterconnect diagram, showing the relationships of the various subsystems within the


architecture. A customized interconnect diagram for the Grand Region is shown in Figure .Communication functions between the subsystems are represented in the ovals. Fixed-pointto fixed-point communications include not only twisted pair and fiber optic technologies,but also wireless technologies such as microwave and spread spectrum.

Terminators are the people, systems, other facilities, and environmental conditions outsideof ITS that need to communicate or interface with ITS subsystems. Terminators help definethe boundaries of the National ITS Architecture as well as a regional system. Examples ofterminators include: drivers, weather information providers, and information serviceproviders.

Travelers

Vehicles Field

CentersMaintenance &ConstructionManagement

Archived DataManagement

PersonalInformation

Access

CommercialVehicle

Administration

TollAdministration

EmergencyManagement

Fleet andFreight

Management

TransitManagement

EmissionsManagement

RemoteTravelerSupport

Wide Area Wireless (Mobile) Communications

InformationServiceProvider

TrafficManagement

CommercialVehicle

EmergencyVehicle

Vehicle

TransitVehicle

Vehi

cle

to V

ehic

le C

omm

unic

atio

ns

Maint & ConstVehicle

Ded

icat

ed S

hort

Ran

geC

omm

unic

atio

ns

TollCollection

CommercialVehicleCheck

Roadway

ParkingManagement

SecurityMonitoring

Term

inat

ors

Fixed-Point to Fixed-Point Communications

Figure 3 - National ITS Architecture Physical Subsystem Interconnect Diagram

3.3.2 ITS Inventory by Stakeholder

Each stakeholder is associated with one or more systems or elements (subsystems andterminators) that make up the transportation system in the Grand Region. A listing ofstakeholders as identified in the Architecture can be found in Table 4 along with adescription of the stakeholder. For example, rather than individually documenting each ofthe smaller local agencies in the Region, a single stakeholder was created for local agencieswhich represents the cities and towns not specifically called out in the architecture. Table 5sorts the inventory by stakeholder so that each stakeholder can easily identify and review allof the architecture elements associated with their agency. The table includes the status ofthe element. In many cases, an element classified as existing might still need to beenhanced to attain the service level desired by the Region.


Table 4 - Grand Region Stakeholder Descriptions

Stakeholder Stakeholder DescriptionDepartment of HomelandSecurity

The Department of Homeland Security is responsible for coordinating with multipleagencies to secure the nation's borders and protect the infrastructure and citizens.

DNR Michigan Department of Natural Resources is responsible for the operations andmaintenance of all Parks and Recreation facilities including infrastructurecomponents on those properties. DNR utilizes some technologies to provideinformation to visitors at Parks and Recreation facilities.

Financial Institution Financial Institutions involved in the transfer of funds for fare collection as well asfor other fee based transportation services. Can handle the exchange of money fortransit electronic fare collection or toll collection.

Ionia Transit Authority Transit provider that operates paratransit service within Ionia County.

Local Agency Local government includes municipalities, counties, and townships and covers alldepartments within those agencies that deal with traffic, public safety, emergencymanagement, public works and school transportation agencies. Local Agenciesinclude: City of Holland, Ottawa CRC, City of Greenville, City of Ionia, City ofMuskegon, Muskegon CRC, City of Norton Shores, City of Muskegon Heights, Cityof Zeeland, City of Portland, Chippewa Hills and Mecosta CRC.

MAX Macatawa Area Express (MAX) is the transit authority for the Greater Holland area;it operates fixed route and demand responsive routes.

MDOT The Michigan Department of Transportation is responsible for the planning, design,construction, maintenance and operation for all aspects of a comprehensiveintegrated transportation system in the State of Michigan. Some of these roles areachieved through contract services with local agencies and private entities.

Media Local media outlets. This can include television stations, newspapers, radiostations and their associated websites.

MSP Michigan State Police is the state law enforcement agency that enforces trafficsafety laws as well as commercial vehicle regulations.

Muskegon Area Transit System Transit provider that operates both fixed route and paratransit service withinMuskegon County.

NOAA National Oceanic and Atmospheric Administration gathers weather information andissues severe weather warnings.

Other Agencies This stakeholder represents a wide variety of agencies. The associated elementsare groups of agencies or providers that do not have a primary stakeholderagency.

Other Elements Other elements include potential obstacles, roadway environment and othervehicles

Private Information ServiceProvider

Private sector business responsible for the gathering and distribution of travelerinformation. This service is typically provided on a subscription basis.

Private Operators Private Operators manage privately owned resources that interconnect with publicsector elements and sub-systems of the Regional Architecture.

Private Transportation Providers Private transportation service providers such as taxis and shuttle services.

Rail Operators Companies that operate trains and/or are responsible for the maintenance andoperations of railroad tracks.

Regional Demand ResponseTransit Providers

Transit providers in the Grand region aside from Ionia Transit Authority, MuskegonArea Transit System and Macatawa Area Express that operate paratransit servicein the region. The agencies include Big Rapids, Belding and Grand Haven (HarborTransit)

System Users All of the users of the transportation system.


Table 5 - Grand Region Inventory of ITS ElementsStakeholder Element Name Element Description Status

Department ofHomeland Security

Department of Homeland Security Responsible for coordinating with multiple agencies tosecure the nation's borders and protect the infrastructureand citizens.

Existing

DNR DNR Weather Stations Department of Natural Resources field equipment thatcollects weather data such as temperature and visibility.

Existing

Financial Service Provider Handles exchange of money for transit electronic paymentcollection.

ExistingFinancial Institution

Service Agency Agency responsible for payment of transit fares for medicaltransportation as part of government subsidized medicalcare. This includes Medicare, and VA programs.

Existing

Ionia Transit Authority Data Archive The transit data archive for the Ionia Transit Authority. Usedby FTA and MDOT Office of Public Transportation.

Planned

Ionia Transit Authority Dispatch Center Transit dispatch center responsible for the tracking,scheduling and dispatching of demand response vehiclesoperated by Ionia Area Transit Authority.

Planned

Ionia Transit Authority Electronic Fare PaymentCard

Medium for collection of transit fares electronically. Planned

Ionia Transit Authority Transit Center CCTVSurveillance

CCTV surveillance at the Ionia Transit Authority TransitCenter.

Planned

Ionia Transit Authority Vehicles Transit Vehicles owned by Ionia Area Transit Authority. Existing

Ionia Transit Authority

Ionia Transit Authority Website Website with information about fares and schedules. At thistime the website is static.

Planned

County 911 Dispatch Central Dispatch is responsible for the dispatch of all publicsafety vehicles (police and fire). After hours CentralDispatch will also dispatch the Street Department on-callemergency responder. Counties included are Muskegon,Newaygo, Montcalm, Ottawa and Ionia.

Existing

County Road Commission Contract agency managed by a county that oversees roadmaintenance and snow removal on local and MDOTfacilities.

Existing

Local Agency

County Road Commission Vehicles County Road Commission vehicles used in maintenanceoperations.

Existing



Gerald R Ford International Airport Airport located in Grand Rapids, Michigan. The KentCounty Department of Aeronautics is responsible for themanagement and operation of the airfield and airportfacilities.

Planned

Ionia County Airport Airport owned by Ionia County serving mostly single engineairplanes.

Planned

Local Agency Anti-Icing Field Equipment Roadside equipment located along routes maintained bylocal agencies that collects weather data such astemperature and visibility.

Planned

Local Agency CCTV Roadside equipment on local routes used for trafficcondition monitoring and management of incidents.

Existing

Local Agency DPW Contract agency managed by a local municipality thatoversees road maintenance and snow removal on local andMDOT facilities.

Existing

Local Agency DPW Vehicles Local Government vehicles used in maintenance operations. ExistingLocal Agency ESS Environmental sensor stations operated by local agencies

that collect information about the roadways such astemperature and moisture levels.

Planned

Local Agency Field Sensors Roadway equipment on local routes used to detect vehiclevolumes and/or speeds. This information is used in theoperation of the traffic signal system and collected by theTOC.

Planned

Local Agency Fog Detection Roadside equipment operated by local agencies that collectinformation about fog visibility levels in fog prone areas.

Planned

Local Agency High Water Detection Roadside equipment operated by local agencies that collectinformation about the water level on flood prone roadways.

Planned

Local Agency Parking Management System System operated by a local agency that monitors availablevehicle parking at key parking facilities.

Planned

Local Agency Public Safety Vehicles Local law enforcement, fire and EMS vehicles. Includes theITS equipment installed on the cruisers (AVL, MDTs, etc.).

Existing

Local Agency Ridesharing Program System used for matching riders with similar origins anddestinations to promote carpooling.

Planned

Local Agency(continued)

Local Agency Roadway Barrier System Roadside equipment operated by local agencies that closeroadway segments automatically due to unsafe conditionssuch as flooding.

Planned



Local Agency TOC Local Traffic Operations Center responsible for municipalsignal system operations.

Planned

Local Agency Traffic Signals Multiple traffic signals interconnected and operated by aLocal Agency.

Existing

Local Agency Website Website for the Local Agencies. ExistingLocal Emergency Operations Center Central command and control facility responsible for

carrying out the principles of emergency preparedness andemergency management, or disaster management functionsat a strategic level in an emergency situation.

Planned

Mason/Oceana 911 911 Dispatch for Mason and Oceana Counties. CentralDispatch is responsible for the dispatch of all Mason andOceana County public safety vehicles (police and fire). Afterhours Central Dispatch will also dispatch the StreetDepartment on-call emergency responder.

Existing

Mecosta/Osceola Central Dispatch 911 Dispatch for Mecosta and Osceola Counties. CentralDispatch is responsible for the dispatch of all Mecosta andOsceola County public safety vehicles (police and fire).After hours Central Dispatch will also dispatch the StreetDepartment on-call emergency responder.

Existing

Roben - Hood Airport Owned and operated by the City of Big Rapids. Planned


School Transportation Agencies Agencies responsible for operating school bus fleets. ExistingMacatawa Area Express Data Archive The transit data archive for the MAX. Used by FTA and

MDOT Office of Public Transportation.Planned

Macatawa Area Express Dispatch Center Transit dispatch center responsible for the tracking,scheduling and dispatching of fixed route and paratransitvehicles operated by MAX.

Existing

MAX Electronic Fare Payment Card Medium for collection of transit fares electronically. PlannedMAX Kiosks Kiosks for dissemination of transit traveler information.

Kiosks can also be used for the purchase and recharging ofelectronic fare payment cards.

Planned

MAX Transit Center CCTV Surveillance CCTV surveillance at MAX transit center. PlannedMAX Vehicles Transit Vehicles owned by Macatawa Area Express Existing

MAX

MAX Website Website with information about fares and schedules. At thistime the website is static.

Existing



MDOT Anti-Icing Field Equipment Roadside equipment located along MDOT routes thatcollects weather data such as temperature and visibility.

Planned

MDOT Bay Region TMC Transportation management center for Bay Region that willinclude the freeway management system in the Bay Regionas well as rural ITS deployments.

Planned

MDOT CCTV Cameras Roadside equipment located on local roadways used fortraffic condition monitoring and management of incidents.

Planned

MDOT Commercial Vehicle Permitting System MDOT system for tracking and monitoring oversize andoverweight permits for commercial vehicles.

Planned

MDOT DMS Roadside equipment on MDOT routes used to share travelerinformation with motorists through dynamic messaging.

Planned

MDOT Drawbridge Control Equipment Roadside equipment located on MDOT drawbridges thatclose approaching roadways or stop traffic prior to thedrawbridge opening to waterway traffic.

Existing

MDOT Drawbridge Management Center Management of the waterways used by boats and ferriesand the roadways used by vehicles.

Existing

MDOT Drawbridge Notification Equipment Roadside equipment located on MDOT drawbridges thatsend notifications when the drawbridge is open for waterwaytraffic.

Existing

MDOT ESS Environmental sensor stations located on MDOT routes thatcollect information about the roadways such as temperatureand moisture levels.

Planned

MDOT Field Sensors Roadway equipment located on MDOT roadways used todetect vehicle volumes and/or speeds. This information isused in the operation of the traffic signal system andcollected by the TOC. MDOT field sensors include VIVDSand any other vehicle detection.

Planned

MDOT Frost Tube Sensors Roadside equipment located along MDOT routes that collectdata from frost tube sensors.

Planned

MDOT

MDOT Grand Region Commercial VehicleParking Management System

System operated on MDOT routes that monitors availablecommercial vehicle parking at rest areas and other keylocations.

Planned



MDOT Grand Region Office The Grand Region Office serves as a data collection anddissemination point for traffic information in the GrandRegion. This includes coordination with other agenciessuch as public safety, emergency management, and transit.

Existing

MDOT Grand Region TSCs MDOT field office that oversees road construction andmaintenance on MDOT facilities. Most maintenance andsnow removal in this region is achieved through contractagencies.

Existing

MDOT Grand Traverse County TMC Co-located traffic operations center in Traverse City.Responsible for the operation of the ITS equipment locatedin Traverse City and the surrounding areas in the NorthRegion.

Planned

MDOT Maintenance and Construction FieldPersonnel

MDOT field forces that operate and maintain MDOTfacilities.

Existing

MDOT Maintenance Vehicles Michigan Department of Transportation vehicles used inmaintenance operations.

Existing

MDOT MI Drive Website Website for Michigan Department of Transportation. ExistingMDOT MITSC MDOT traffic management center located in the Metro

Region.Existing

MDOT North Region TMC MDOT traffic management center located in the NorthRegion.

Planned

MDOT Office of Communications Michigan Department of Transportation responsible for thedissemination of traffic information to the media and public.

Existing

MDOT Planning Division Data Warehouse Archive that contains historical traffic data such as volumeand speed information.

Existing

MDOT Roadside Equipment for AHS Equipment located along MDOT routes that allowscommunication between roadside devices and vehicles.

Planned

MDOT Roadside Intersection CollisionAvoidance Equipment

Equipment located along MDOT routes that communicatesbetween multiple roadside devices and vehicles to alert ofunsafe travel conditions or conditions conducive to crashes.

Planned

MDOT (continued)

MDOT Roadside Signing Equipment Equipment located along MDOT routes that provide datathrough dynamic messaging or in-vehicle messaging.

Planned



MDOT Security Monitoring Field Equipment Roadside equipment located on MDOT routes that is usedfor monitoring key infrastructure elements from damage orattacks. These elements include structures such as bridgesor dams.

Planned

MDOT Service Patrol Dispatch Provides efficient use of resources to assist motorists inneed on MDOT facilities.

Planned

MDOT Service Patrol Vehicles Fully equipped vehicles that provide motorist assistance tovehicles in need on MDOT facilities.

Planned

MDOT Statewide TMC - Lansing MDOT traffic management center located in Lansing. PlannedMDOT Superior Region TMC MDOT traffic management center located in the Superior

Region.Planned

MDOT Traffic Signals Multiple traffic signals interconnected and operated byMDOT.

Existing

MDOT Traveler Information Database MDOT maintained database for collecting and disseminatingroad condition data about construction and maintenanceactivities, incidents, and special events.

Planned

MDOT Traveler Information Kiosks Interactive kiosks that provides users the ability to requestand received transportation information.

Planned

MDOT Weigh-in-Motion In-road equipment that monitors vehicle weights. ExistingMDOT West Michigan TMC MDOT traffic management center located in Grand Rapids. ExistingMDOT Work Zone Safety Monitoring Equipment Portable ITS equipment that can be used in work zones to

more efficiently manage traffic and provide travelerinformation. Includes CCTV, vehicle detection, and/or DMS.

Planned

Michigan 511 System 511 Traveler information system central server. PlannedMichigan 511 Voice Response System Michigan 511 Interactive Voice Response system. This is

the customer interface component of the 511 system.Planned

MDOT (continued)

Other MDOT Region TSCs Local MDOT offices outside of the Grand Region thatoversee the operations and maintenance on MDOTfacilities.

Existing

Media Local Print and Broadcast Media Local media that provide traffic or incident information to thepublic.

Existing



CJIC Database Criminal Justice Information Center Database storescriminal justice data and can be accessed by multipleagencies.

Existing

MIOC Michigan Intelligence Operations Center. Provides 24-hourstatewide information sharing among local, state, andfederal public safety agencies and private sectororganizations in order to facilitate the collection, analysis,and dissemination of intelligence relevant to terrorism andpublic safety.

Existing

MSP District 6 Dispatch - Rockford Michigan State Police dispatch for the Grand Region.Provides call-taking and dispatch for public safety agencies.

Existing

MSP Headquarters - East Lansing Michigan State Police headquarters that overseesoperations of MSP.

Existing

MSP Motor Carrier Division Responsible for monitoring commercial vehicle regulationson MDOT routes.

Existing

MSP Motor Carrier Division Enforcement Responsible for enforcing commercial vehicle regulations onMDOT routes.

Existing

MSP Office of Highway Safety Planning Manages crash data for MDOT routes. ExistingMSP Toll Free Winter Road Conditions PhoneNumber

Winter weather information operated from Novemberthrough March to share winter weather conditions asreceived.

Existing

MSP Vehicles Public Safety vehicles owned and operated by MichiganState Police. Includes the ITS equipment installed on thecruisers (AVL, MDTs, etc.).

Existing

MSP

MSP Winter Travel Advisory Website Traveler Information website operated by Michigan StatePolice for dissemination of winter weather advisories

Existing

Muskegon Area Transit System CCTVSurveillance

CCTV surveillance at the Muskegon Area Transit SystemTransit Center.

Planned

Muskegon Area Transit System Data Archive The transit data archive for the Muskegon Area TransitSystem. Used by FTA and MDOT Office of PublicTransportation.

Planned

Muskegon Area TransitSystem

Muskegon Area Transit System DispatchCenter

Transit dispatch center responsible for the tracking,scheduling and dispatching of fixed route and paratransitvehicles operated by Muskegon Area Transit System.

Existing



Muskegon Area Transit System Electronic FarePayment Card


Muskegon Area Transit System Kiosks Kiosks for dissemination of transit traveler information.Kiosks can also be used for the purchase and recharging ofelectronic fare payment cards.

Planned

Muskegon Area Transit System Vehicles Transit Vehicles owned by Muskegon Area Transit Existing

Muskegon Area TransitSystem (continued)

Muskegon Area Transit System Website Website with information about fares and schedules. At thistime the website is static.

Existing

National Weather Service Provides official US weather, marine, fire and aviationforecasts, warnings, meteorological products, climateforecasts, and information about meteorology.

ExistingNOAA

NWS Weather Stations National Weather Service Field equipment that collectsweather data such as temperature and visibility

Existing

Multimodal Service Provider Agency that offers services across multiple transportationmodes.

PlannedOther Agencies

Private Concierge Provider Private entities that provides customized services to thetraveler. This service is usually subscription based.

Existing

Potential Obstacles Obstacles that could interfere with the safe operation ofvehicles.

ExistingOther Elements

Roadway Environment All objects and conditions in the vicinity of the traveler thatcan affect the operations of the traveler.

Existing

Private Sector ISP Private entities that collect and disseminate trafficinformation.

ExistingPrivate InformationService Provider

Private Sector Traveler Information Services Website sponsored by a private entity. Often thisinformation is provided through a subscription.

Existing

Contractor Smart Zone Equipment Smart Work Zone Equipment owned by private contractor.Portable ITS equipment that can be used in work zones tomore efficiently manage traffic and provide travelerinformation. Includes CCTV, vehicle detection, and/or DMS.

Existing

Private Fleet Operators Private companies that proactively manage and operatetheir fleet routing. Includes reactions to incidents andpossible delays.

Existing

Private Operators

Private Parking Operator System operated on private property that monitors availablecommercial vehicle parking.

Existing



Private TransportationProviders

Private Transportation Providers Private providers of transportation services in the Regionsuch as taxis and intercity bus services.

Existing

Rail Operators Rail Operator Wayside Equipment Equipment located along the tracks including railroadcrossing gates, bells, and lights as well as the interface tothe traffic signal controller indicating the presence of a train.

Planned

Regional Demand Response Electronic FarePayment Card


Regional Demand Response Transit ProviderData Archive

The transit data archive for the Regional DemandResponsive Transit Providers Data Archive. Used by FTAand MDOT Office of Public Transportation.

Planned

Regional Demand Response Transit ProviderDispatch Center

Transit dispatch center responsible for the tracking,scheduling and dispatching of fixed route and paratransitvehicles operated by Regional Demand Responsive TransitAuthorities.

Planned

Regional Demand Response Transit ProviderTransit Center CCTV Surveillance

CCTV surveillance at the Regional Demand ResponseTransit Providers Center

Planned

Regional Demand Response Transit ProviderVehicles

Transit Vehicles owned by the regional demand responsivetransit providers.

Existing

Regional DemandResponse TransitProviders

Regional Demand Response Transit ProviderWebsite

Website with information about fares and schedules. At thistime the website is static.

Planned

Archived Data Users Those who request information from the data archivesystems

Existing

Commercial Vehicle Privately owned commercial vehicles that travel throughoutthe Region. Included in the architecture to cover HAZMATincident reporting.

Existing

Driver Individual operating a vehicle on roadways within the region ExistingOther Vehicle Vehicles outside of the control of the driver. ExistingPrivate Travelers Personal Computing Devices Computing devices that travelers use to access public

information.Existing

Private Vehicles Vehicles operated by the public. Existing

System Users

Traveler Individual operating a vehicle on roadways within the Region Existing


3.3.3 Top Level Regional System Interconnect Diagram

A system interconnect diagram, or “sausage diagram” (shown previously in Table 4),shows the systems and primary interconnects in the Region. The National ITS Architectureinterconnect diagram has been customized for the Grand Region based on the systeminventory and information gathered from the stakeholders. Table 5 summarizes the existingand planned ITS elements for the Grand Region in the context of a physical interconnect.Subsystems and elements specific to the Region are called out in the boxes surrounding themain interconnect diagram, and these are color-coded to the subsystem with which they areassociated.


Security Monitoring SubsystemIonia Transit Authority Transit Center CTTVSurveillance

MAX Transit Center CCTV Surveillance

MDOT Security Monitoring Field Equipment

Muskegon Area Transit System CCTV Surveillance

Regional Demand Responsive Transit ProvidersTransit Center CCTV Surveillance

Traffic ManagementLocal Agency TOC

MDOT Bay Region TMC

MDOT Drawbridge Management Center

MDOT Grand Region Office

MDOT-Grand Traverse County TMC

MDOT MITSC

MDOT North Region TMC

MDOT Statewide TMC - Lansing

MDOT Superior Region TMC

MDOT West Michigan TMC

Emergency ManagementCounty 911 Dispatch

Local Agency Emergency Operations Center

Mason/Oceana 911

MDOT Service Patrol Dispatch

Mecosta/Osceola Central Dispatch

MIOC

MSP District 6 Dispatch - Rockford

MSP Headquarters - East Lansing

MSP Office of Highway Safety Planning

Private Concierge Provider

Transit ManagementGrand Haven (Harbor Transit)

Ionia Transit Authority Dispatch Center

Local Agency

Macatawa Area Express (MAX) Dispatch Center

Muskegon Area Transit System Center

Private Transportation Providers

Regional Demand Responsive Transit ProvidersDispatch Center

School Transportation Agencies

Maintenance & Construction MgmtCounty Road Commission

Local Agency DPW

MDOT Grand Region TSCs

MDOT Maintenance

Other MDOT Region TSCs

Information Service ProviderIonia Transit Authority Website

Local Agency Ridsharing Program

Local Agency Website

MAX Website

MDOT MI Drive Website

MDOT Office of Communications

MDOT Traveler Information Database

Michigan 511 System

MSP Toll Free Winter Road Conditions PhoneNumber

MSP Winter Travel Advisory Website

Muskegon Area Transit System Website

Private Sector ISP

Private Sector Traveler Information Services

Regional Demand Responsive Transit ProviderWebsite

Archived Data ManagementCJIC Database

Ionia Transit Authority Data Archive

Macatawa Area Express Data Archive

MDOT Planning Division Data Warehouse

Muskegon Area Transit System Data Archive

Regional Demand Responsive Transit Providers DataArchive

Roadway Subsystem (cont.)MDOT Drawbridge Control Equipment

MDOT Drawbridge Notification Equipment

MDOT ESS

MDOT Field Sensors

MDOT Frost Tube Sensors

MDOT Roadside Equipment for AHS

MDOT Roadside Intersection Collision AvoidanceEquipment

MDOT Roadside Signing Equipment

MDOT Traffic Signals

MDOT Work Zone Safety Monitoring Equipment

NWS Weather Stations

Transit Vehicle SubsystemIonia Transit Authority Vehicles

MAX Vehicles

Muskegon Area Transit System Vehicles

Regional Demand Responsive Transit ProviderVehicles

Maintenance and ConstructionVehicleCounty Road Commission Vehicles

Local Agency DPW Vehicles

MDOT Maintenance Vehicles

Remote Traveler SupportMAX Kiosks

MDOT Traveler Information Kiosks

Muskegon Area Transit System Kiosks

Regional Demand Responsive Transit ProvidersKiosks

Personal Information AccessPrivate Travelers Personal Computing Devices

Travelers

Vehicles Field

CentersMaintenance &ConstructionManagement


PersonalInformation

Access

CommercialVehicle

Administration

TollAdministration

EmergencyManagement

Fleet andFreight

Management

TransitManagement

EmissionsManagement

RemoteTravelerSupport

Wide Area Wireless (Mobile) Communications

InformationServiceProvider

TrafficManagement

CommercialVehicle

EmergencyVehicle

Vehicle

TransitVehicle

Vehi

cle

to V

ehic

le C

omm

unic

atio

ns

Maint & ConstVehicle

Ded

icat

ed S

hort

Ran

geC

omm

unic

atio

ns

TollCollection

CommercialVehicleCheck

Roadway

ParkingManagement

SecurityMonitoring

Term

inat

ors

Fixed-Point to Fixed-Point Communications

Archived Data User SystemsArchived Data Users

TravelerTraveler

MediaLocal Print and Broadcast Media

Traveler CardIonia Transit Authority Electronic Fare Payment Card

MAX Electronic Fare Payment Card

Muskegon Area Transit System Electronic FarePayment Card

Regional Demand Responsive Electronic FarePayment Card

Subsystem

Subsystem

RegionalArchitectureElements MapTo National ITSArchitecture

No RegionalArchitectureElements MapTo National ITSArchitecture

Legend

Emergency Vehicle SubsystemLocal Agency Public Safety Vehicles

MDOT Service Patrol Vehicles

MSP Vehicles

Weather ServiceNational Weather Service

Parking OperatorPrivate Parking Operator

Other VehicleOther Vehicle

Commercial Vehicle DriverDriver

Fleet and Freight ManagementPrivate Fleet Operations

Parking ManagementLocal Agency Parking Management System

MDOT Grand Region Commercial Vehicle ParkingManagement System

Potential ObstaclesPotential Obstacles

Roadway SubsystemContractor Smart Zone Equipment

DNR Weather Stations

Local Agency Anti-Icing Field Equipment

Local Agency CCTV

Local Agency ESS

Local Agency Field Sensors

Local Agency Fog Detection

Local Agency High Water Detection

Local Agency Roadway Barrier System

Local Agency Traffic Signals

MDOT Anti-Icing Field Equipment

MDOT CCTV Cameras

MDOT DMS

Vehicle SubsystemPrivate Vehicle

Wayside EquipmentRail Operator Wayside Equipment

Commercial Vehicle CheckMDOT Weigh-in-Motion

Commercial Vehicle AdministrationMDOT Commercial Vehicle Permitting System

MSP Motor Carrier Division

MSP Motor Carrier Division Enforcement

Maintenance and ConstructionField PersonnelMDOT Maintenance and Construction Field Personnel

Other Emergency ManagementDepartment of Homeland Security

Multimodal CrossingsMDOT Multimodal Crossing

Telecommunications System forTraveler InformationMichigan 511 Voice Response System

Roadway EnvironmentRoadway Environment

CVO InspectorMSP Motor Carrier Division Enforcement

Basic Commercial VehicleCommercial Vehicle

Financial InstitutionFinancial Service Provider

Service Agency

Multimodal Transportation ServiceProviderMultimodal Service Provider

Surface Transportation WeatherServiceGerald R Ford International Airport

Ionia County Airport

Roben-Hood Airport

Figure 4 - Grand Regional System Interconnect Diagram


3.4 Market Packages

Upon completion of the system inventory, the next step in the development of the architecturewas to identify the transportation services that are important to the Grand Region. In the NationalITS Architecture, services are referred to as market packages. Market packages can includeseveral stakeholders and elements that work together to provide a service in the Region.Examples of market packages from the National ITS Architecture include Network Surveillance,Traffic Information Dissemination, and Transit Vehicle Tracking. There are currently a total of85 market packages identified in the National ITS Architecture Version 5.1. Appendix Aprovides definitions for each of the National ITS Architecture market packages.

The market packages are grouped together into eight ITS service areas: Traffic Management,Emergency Management, Maintenance and Construction Management, Public TransportationManagement, Commercial Vehicle Operations, Traveler Information, Archived DataManagement, and Vehicle Safety.

3.4.1 Selection and Prioritization of Regional Market Packages

In the Grand Region, the National ITS Architecture market packages were reviewed by thestakeholders and selected based on the relevance of the service that the market packagecould provide to the Region. Forty-eight market packages were selected for implementationin the Region. They are identified in Table 6. Stakeholders prioritized the selected marketpackages during the workshop, and the table organizes the market packages into serviceareas and priority groupings. These priorities are based on the stakeholders’ opinion ofneed and do not necessarily represent the timeframe for funding of the deployments. Thesepriorities can also be affected by several other factors such as existing infrastructure,dependency on other systems, and the maturity of the technology associated with the marketpackage.

After selecting the market packages that were applicable for the Region, stakeholdersreviewed each market package and the elements that could be included to customize it forthe Region. This customization is discussed further in the following section.


Table 6 - Grand Region Market Package Prioritization by Functional Area

High PriorityMarket Packages

Medium PriorityMarket Packages

Low PriorityMarket Packages

Travel and Traffic ManagementATMS01 Network SurveillanceATMS03 Surface Street ControlATMS06 Traffic Information

DisseminationATMS07 Regional Traffic ControlATMS08 Traffic Incident

Management SystemATMS20 Drawbridge Management

ATMS13 Standard Railroad GradeCrossing

ATMS21 Roadway ClosureManagement

ATMS02 Probe SurveillanceATMS16 Parking Facility

ManagementATMS17 Regional Parking

Management

Emergency ManagementEM01 Emergency Call-Taking and

DispatchEM02 Emergency RoutingEM06 Wide-Area Alert

EM03 Mayday Support EM04 Roadway Service PatrolsEM05 Transportation Infrastructure

ProtectionEM07 Early Warning SystemEM09 Evacuation and Reentry

ManagementEM10 Disaster Traveler Information

Maintenance and Construction ManagementMC01 Maintenance and

Construction Vehicle andEquipment Tracking

MC03 Road Weather DataCollection

MC04 Weather InformationProcessing and Distribution

MC06 Winter MaintenanceMC08 Work Zone Management

MC05 Roadway AutomatedTreatment

MC09 Work Zone SafetyMonitoring

MC10 Maintenance andConstruction ActivityCoordination

Public Transportation ManagementAPTS1 Transit Vehicle TrackingAPTS5 Transit Security

APTS2 Transit Fixed-RouteOperations

APTS3 Demand Response TransitOperations

APTS4 Transit Passenger andFare Management

APTS6 Transit MaintenanceAPTS8 Transit Traveler Information

APTS7 Multi-modal Coordination

Commercial Vehicle OperationsCVO06 Weigh-in-Motion CVO04 CV Administration ProcessTraveler InformationATIS1 Broadcast Traveler

InformationATIS2 Interactive Traveler

Information

ATIS4 Dynamic Route GuidanceATIS5 ISP Based Route GuidanceATIS9 In Vehicle Signing

ATIS8 Dynamic Ridesharing

Archived Data ManagementAD1 ITS Data MartAD3 ITS Virtual Data Warehouse


Table 6 - Grand Region Market Package Prioritization by Functional Area

Advanced Vehicle Safety SystemAVSS10 Intersection Collision

AvoidanceAVSS11 Automated Highway

System

3.4.2 Customized Market Packages

The market packages in the National ITS Architecture were customized to reflect the uniquesystems, subsystems, and terminators in the Grand Region. Each market package is showngraphically with the market package name, local agencies involved and desired data flowsincluded. Market packages represent a service that will be deployed as an integratedcapability.

Figure 5 is an example of an ATMS market package for Surface Street Control that hasbeen customized for the Region. This market package shows the two subsystems, TrafficManagement and Roadway, and the associated entities (Local Agency TOC and LocalAgency Traffic Signals) for surface street control in the Region. Data flows between thesubsystems indicate what information is being shared. The remainder of the marketpackages that were customized for the Grand Region is shown in Appendix B.

Figure 5 - Example Market Package Diagram: Surface Street Control

3.4.3 Regional ITS Needs and Customized Market Packages

Input received from stakeholders at the Architecture Workshop provided valuable input forthe market package customization process. The specific needs identified are included inTable 7. The table also identifies which market package documents the particular ITSneed.


Table 7 - Regional ITS Needs and Corresponding Market Packages

ITS Need MarketPackage

Traffic Management and Traveler InformationNeed remote access to closed loop systems so MDOT can adjust timing plans ATMS03Need system for managing recurring congestion in Grand Haven ATMS01

ATMS03ATMS08

Need incident management system that helps communicate with Media ATMS06ATMS08

Need to integrate Traffic Management Center with EMS CAD ATMS06ATMS08

Need plans for traffic management during special events (Coast Guard Festival,Grand Haven)

ATMS01ATMS06ATMS08

Need CCTV surveillance in specific locations ATMS01Need animal avoidance solutions on local roads, not necessarily on MDOTroutes

ATMS01

Need assistance building communications between agencies ATMS06ATMS07

Public Transportation ManagementNeed AVL technology for transit vehicles APTS1Need improved traveler information solutions for transit agencies APTS8Emergency ManagementNeed RWIS devices and warning signs controlled by RWIS MC03

MC04Need to link RWIS to Maintenance Personnel MC04

MC06Need improved coordination between multiple central dispatch ATMS03

EM01Public safety needs access to CCTV camera images ATMS06Maintenance and Construction ManagementNeed system to manage contracted snow removal (GPS, central database,communication)

MC01MC06

Need anti-icing systems in key locations MC05Commercial Vehicle OperationsNeed permanent Weigh-In-Motion stations outside of Kent County CVO06Need system for monitoring frost tube measurements that drive seasonal weightrestrictions

MC03

Need improved access to remote WIM sites CVO06Traveler InformationNeed DMS in key incident management locations ATMS06Archived Data ManagementNeed improved method for sharing crash data AD1

AD3Need method for sharing historical data AD1

AD3


3.5 Architecture Interfaces

While it is important to identify the various systems and stakeholders that are part of a regionalITS, a primary purpose of the architecture is to identify the connectivity between transportationsystems in the Grand Region. The system interconnect diagram shown previously in Figure 4showed the high-level relationships of the subsystems and terminators in the Grand Region andthe associated local projects and systems. The customized market packages represent servicesthat can be deployed as an integrated capability and the market package diagrams show theinformation flows between the subsystems and terminators that are most important to theoperation of the market packages. How these systems interface with each other is an integral partof the overall ITS architecture.

3.5.1 Element Connections

There are a large number of different elements identified as part of the Grand Regional ITSArchitecture. These elements include traffic management centers, transit vehicles, dispatchsystems, emergency management agencies, media outlets, and others—essentially, all of theexisting and planned physical components that contribute to the regional ITS. Interfaceshave been identified for each element in the Grand Region ITS Architecture and eachelement has been mapped to those other elements with which it must interface. The TurboArchitecture software can generate interconnect diagrams for each element in the Regionthat show which elements are connected to one another. Figure 6 is an example of acontext style interconnect diagram from the Turbo database output. This particularinterconnect diagram is for the MDOT MI Drive Website and is called a context diagrambecause it shows every element in the architecture that the website connects to.

Figure 6 - Example Interconnect Diagram: MDOT MI Drive Website

MDOTMDOT MI Drive Website

NOAANational Weather Service

System UsersPrivate Travelers Personal Computing

Devices

MDOTMDOT Grand Region Commercial

Vehicle Parking Management System

Private Transportation ProvidersPrivate Transportation Providers

Regional Demand Response Transit ...Regional Demand Response Transit

Provider Dispatch Center

Ionia Transit AuthorityIonia Transit Authority Dispatch Center

MAXMacatawa Area Express Dispatch

Center

Muskegon Area Transit SystemMuskegon Area Transit System

Dispatch Center

MDOTMDOT Traveler Information Database

MDOTMDOT West Michigan TMC

Planned


3.5.2 Data Flows Between Elements

In the market package diagrams, flows between the subsystems and terminators define thespecific information (data) that is exchanged between the elements and the direction of theexchange. The data flows could be requests for information, alerts and messages, statusrequests, broadcast advisories, event messages, confirmations, electronic credentials, andother key information requirements. Turbo Architecture can be used to output flowdiagrams and can be filtered by market package for ease of interpretation; however, it isimportant to remember that custom data flows will not show up in diagrams that are filteredby market package. An example of a flow diagram for the MDOT Traffic Signals that hasbeen filtered for ATMS03 – Surface Street Control for MDOT Traffic Signal System isshown in Figure 7.

The flow diagrams can vary greatly in complexity and, in turn, legibility. Figure 8 shows amore complex flow diagram for ATMS06 – Traffic Information Dissemination – MDOTWest Michigan TMC.

Figure 7 - Example Flow Diagram: ATMS03 – Surface Street Control for MDOT TrafficSignal System

MDOTMDOT Traffic Signals


MDOTMDOT Grand Region Office

request for right-of-waysignal control status

signal control data

signal control statussignal control data

ExistingPlanned



MDOTMDOT DMS

MDOTMDOT Grand Region TSCs

Local AgencySchool Transportation Agencies






Center


Dispatch Center

Local AgencyCounty 911 Dispatch

MediaLocal Print and Broadcast Media

Local AgencyMecosta/Osceola Central Dispatch

Local AgencyMason/Oceana 911

MSPMSP District 6 Dispatch - Rockford


roadway information system dataroadway information system status

current asset restrictionsroad network conditions

road network conditions

road network conditionsroad network conditions






Planned

Figure 8 - Example Flow Diagram: ATMS06 – Traffic Information Dissemination – MDOT West Michigan TMC


In addition to market package style flow diagrams, Turbo Architecture has the ability tocreate flow diagrams that show only the connections between two or three specific elementsor context diagrams that sow all of the flows that involve an element. Filtering thediagrams to generate specific scenarios can be very useful during the projectimplementation process. For example, Figure 9 shows the flows between MDOT TravelerInformation Database and MDOT Traveler Information Kiosks. While this is a portion ofthe planned interactions, it could also be useful to use a context diagram for the element, asshown in Figure 10 to view all of the other interactions so that the project can be designedwith the future in mind. Context style flow diagrams can get very large and complicated forelements with lots of connections such as a TMC.

Figure 9 - Example Two Element Flow Diagram

MDOTMDOT Traveler Information Kiosks


traveler requesttraveler information

Planned


Figure 10 - Example Context Flow Diagram: MDOT Traveler Information Database


MDOTMDOT Grand Region TSCs

Local AgencyCounty 911 Dispatch

MSPMSP District 6 Dispatch - Rockford

Local AgencyMason/Oceana 911

MDOTMDOT MI Drive Website

Local AgencyMecosta/Osceola Central Dispatch

MSPMIOC





Center


MDOTMDOT Traveler Information Kiosks


Dispatch Center

MDOTMDOT Office of Communications


MDOTMDOT Commercial Vehicle Permitting

System

MDOTMichigan 511 System

Local AgencyLocal Agency DPW

Local AgencyCounty Road Commission

Private Information Service ProviderPrivate Sector ISP

Local AgencyLocal Agency TOC

current asset restrictionsmaint and constr work plans

road weather informationroadway maintenance status

work zone information

evacuation informationincident information

transportation system statusevacuation information

incident informationtransportation system status


transportation system statusISP coordination


transportation system statusevacuation information

incident informationtransportation system status

transit information requesttransit and fare schedules




traveler informationtraveler request


ISP coordinationroad network conditions

route restrictions

ISP coordination

current asset restrictionscurrent asset restrictions

ISP coordinationroad network conditions

Planned


4. APPLICATION OF THE REGIONAL ITS ARCHITECTUREOnce a region has identified the desired components of ITS for their area and established whichagencies and systems need to be connected, the structure of the National ITS Architecture assists withthe region’s planning and implementation. This section addresses the application of the Regional ITSArchitecture in the Grand Region. The National ITS Architecture provides recommendations forstandards and functional requirements that should be considered when implementing ITS elements. Inaddition, an operational concept has been developed for the Region and documents the roles andresponsibilities of stakeholders in the operation of the regional ITS. The implementation of ITS in theGrand Region will likely require interagency agreements. Potential agreements have been identifiedbased on the desired data flows identified in the Grand Region. The ITS Architecture and ITSDeployment Plan developed as part of this process will be incorporated into the existing planningprocess for the Region to ensure that the maximum benefit is realized from the development effort.

4.1 Functional Requirements

Functions are a description of what the system has to do. In the National ITS Architecture,functions are defined at several different levels, ranging from general subsystem descriptionsthrough somewhat more specific equipment package descriptions to Process Specifications thatinclude substantial detail. Guidance from the USDOT on developing a Regional ITS Architecturerecommends that each Region determine the level of detail of the functional requirements fortheir Region. In the Grand Region, it is recommended that the development of detailed functionalrequirements such as the “shall” statements included in Process Specifications for a system bedeveloped at the project level. These detailed “shall” statements identify all functions that aproject or system needs to perform.

For the Grand Regional ITS Architecture, functional requirements have been identified at twolevels. The customized market packages, discussed previously in Section 3.4.2, describe theservices that ITS needs to provide in the Region and the architecture flows between the elements.These market packages and data flows describe what the systems in the Grand Region have to doand the data that needs to be shared among elements.

At a more detailed level, functional requirements for the Grand Region are described in terms offunctions that each element in the architecture performs or will perform in the future. AppendixC contains a table that summarizes the functions by element.

4.2 Standards

Standards are an important tool that will allow efficient implementation of the elements in theGrand Regional ITS Architecture over time. Standards facilitate deployment of interoperablesystems at local, regional, and national levels without impeding innovation as technologyadvances, vendors change, and as new approaches evolve. The USDOT’s ITS Joint ProgramOffice is supporting Standards Development Organizations (SDOs) with an extensive, multi-yearprogram of accelerated, consensus-based standards development to facilitate successful ITSdeployment in the United States. Table 8 identifies each of the ITS standards that could apply tothe Grand Regional ITS Architecture. These standards are based on the physical subsystemarchitecture flows previously identified in Section 3.5.2.


Table 8 - Grand Region Applicable ITS Standards

SDO Document ID TitleANSI ANSI TS286 Commercial Vehicle Credentials

NTCIP 1101 Simple Transportation Management Framework (STMF)NTCIP 1102 Octet Encoding Rules Base ProtocolNTCIP 1103 Transportation Management ProtocolsNTCIP 1104 Center-to-Center Naming Convention SpecificationNTCIP 1105 CORBA Security Service SpecificationNTCIP 1106 CORBA Near-Real Time Data Service SpecificationNTCIP 1201 Global Object DefinitionsNTCIP 1202 Object Definitions for Actuated Traffic Signal Controller UnitsNTCIP 1203 Object Definitions for DMSNTCIP 1204 Environmental Sensor Station Interface StandardNTCIP 1205 Object Definitions for CCTV Camera ControlNTCIP 1206 Object Definitions for Data Collection and Monitoring (DCM)

DevicesNTCIP 1208 Object Definitions for CCTV SwitchingNTCIP 1209 Data Element Definitions for Transportation Sensor SystemsNTCIP 1210 Field Management Stations – Part 1: Object Definitions for Signal

System MastersNTCIP 1211 Object Definitions for Signal Control and PrioritizationNTCIP 1401 TCIP Common Public Transportation ObjectsNTCIP 1402 TCIP Incident Management ObjectsNTCIP 1403 TCIP Passenger Information ObjectsNTCIP 1404 TCIP Scheduling/Runcutting ObjectsNTCIP 1405 TCIP Spatial Representation ObjectsNTCIP 1406 TCIP On-Board ObjectsNTCIP 1407 TCIP Control Center ObjectsNTCIP 1408 TCIP Fare Collection Business Area ObjectsNTCIP 2101 Point to Multi-Point Protocol Using RS-232 Subnetwork ProfileNTCIP 2102 Point to Multi-Point Protocol Using Frequency Shift Keying

Modem Subnetwork ProfileNTCIP 2103 Point-to-Point Protocol Over RS-232 Subnetwork ProfileNTCIP 2104 Ethernet Subnetwork ProfileNTCIP 2201 Transportation Transport ProfileNTCIP 2202 Internet (TCP/IP and UDP/IP) Transport ProfileNTCIP 2301 STMF Application ProfileNTCIP 2302 Trivial File Transfer Protocol Application ProfileNTCIP 2303 File Transfer Protocol Application ProfileNTCIP 2304 Application Profile for DATEX-ASN (AP-DATEX)NTCIP 2305 Application Profile for CORBA (AP-CORBA)NTCIP 2306 Application Profile for XML Message Encoding and Transport in

ITS Center-to-Center CommunicationsNTCIP 2501 Information Profile for DATEX

AASHTO/ITE/NEMA

NTCIP 2502 Information Profile for CORBA


Table 8 - Grand Region Applicable ITS Standards

SDO Document ID TitleASTM E2158-01 Standard Specification for Dedicated Short Range

Communication (DSRC) Physical Layer using Microwave in the902-928 MHz Band

ASTM E2259-xx Standard Specification for Metadata to Support Archived DataManagement Systems

ASTM

ASTM PS 105-99 Standard Provisional Specification for DSRC Data Link LayerIEEE Std 1455-1999 Standard for Message Sets for Vehicle/Roadside

CommunicationsIEEE 1512.1-2003 Standard for Traffic Incident Management Message Sets for Use

by EOCsIEEE 1512.2-2004 Standard for Public Safety Incident Management Message Sets

(IMMS) for use by EOCsIEEE 1512.3-2002 Standard for Hazardous Material IMMSIEEE 1512-2000 Standard for Common IMMS for use by EOCsIEEE 1570-2002 Standard for Interface Between the Rail Subsystem and the

Highway Subsystem at a Highway Rail IntersectionIEEE 1609.1 Resource Manager for DSRC 5.9 GHzIEEE 1609.2 Application Services (Layers 6,7) for DSRC 5.9 GHzIEEE 1609.3 Communications Services (Layers 4,5) for DSRC 5.9 GHz (Future

Standard)IEEE 1609.4 Medium Access Control (MAC) Extension and the MAC Extension

Management Entity for DSRC 5.9 GHzIEEE 802.11 Standard Specification for Telecommunications and Information

Exchange Between Roadside and Vehicle Systems – 5 GHz BandDSRC MAC and Physical Layer Specifications

IEEE 802.2 Logical Link (Layer 2) for DSRC 5.9 GHz

IEEE

IEEE P1512.4 Standard for Common Traffic Incident Management MessageSets for Use in Entities External to Centers

ISO ISO 21210 Networking Services (Layer 3) for DSRC 5.9 GHzITE TM 1.03 Standard for Functional Level Traffic Management Data

DictionaryITE TM 2.01 Message Sets for External TMC CommunicationSAE J2266 Location Referencing Message SpecificationSAE J2313 On-Board Land Vehicle Mayday Reporting InterfaceSAE J2354 Message Set for Advanced Traveler Information System (ATIS)SAE J2369 Standard for ATIS Message sets Delivered Over Reduced

Bandwidth MediaSAE J2540 Messages for Handling Strings and Look-Up Tables in ATIS

StandardsSAE J2540-1 Radio Data System Phrase ListsSAE J2540-2 International Traveler Information Systems Phrase Lists

SAE

SAE J2540-3 National Names Phrase List


4.3 Operational ConceptsAn operational concept documents each stakeholder’s current and future roles and responsibilitiesacross a range of transportation services, as grouped in the Operational Concepts section of TurboArchitecture, in the operation of the regional ITS. The services covered are:

Arterial Management – The development of signal systems that react to changing trafficconditions and provide coordinated intersection timing over a corridor, an area, or multiplejurisdictions.Highway Management – The development of systems to monitor freeway (or tollway) trafficflow and roadway conditions, and provide strategies such as ramp metering or lane accesscontrol to improve the flow of traffic on the freeway. Includes systems to provideinformation to travelers on the roadway.Incident Management – The development of systems to provide rapid and effective responseto incidents. Includes systems to detect and verify incidents, along with coordinated agencyresponse to the incidents.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 themaintenance of roadways in the Region, including winter snow and ice clearance. Includesthe managing of construction operations.Transit Management – The development of systems to more efficiently manage fleets oftransit vehicles or transit rail. Includes systems to provide transit traveler information bothpre-trip and during the trip.Electronic Payment – The development of electronic fare payment systems for use by transitand other agencies (e.g., parking).Commercial Vehicle Operations – The development of systems to facilitate the managementof commercial vehicles (e.g., electronic clearance).Traveler Information – The development of systems to provide static and real timetransportation information to travelers.Archived Data Management – The development of systems to collect transportation data foruse in non-operational purposes (e.g., planning and research).Advanced Vehicle Safety – The development of systems to support private sector vehiclesafety initiatives (e.g., intersection collision avoidance).

Table 9 identifies the roles and responsibilities of key stakeholders for a range of transportationservices.


Table 9 - Grand Region Stakeholder Roles and Responsibilities

TransportationService Stakeholder Roles/Responsibilities

Operate and maintain traffic signal systems on MDOT routesnot managed by local agencies.Operate network surveillance equipment (CCTV Cameras,field sensors, etc.) on MDOT routes not managed by localagencies.Provide traffic information reports to regional informationservice providers.

MDOT

Coordinate traffic information and control with Local AgencyTOCs and other MDOT TMCs.Operate traffic signal systems on local routes.Operate network surveillance equipment including CCTVcameras and field sensors on local routes to facilitate trafficsignal operations.Provide traffic information reports to regional informationservice providers.Provide traffic information to regional agencies includingtransit, emergency management, maintenance andconstruction, and the media.Coordinate traffic information and control with MDOT WestMichigan TMC.Coordinate traffic information with other local agencies.Coordinate HRI signal adjustments with private rail operators.

ArterialManagement

Local Agency

Provide traffic signal preemption for emergency vehicles.Operate network surveillance equipment including CCTVCameras and field sensors as well as DMS to convey trafficinformation to travelers on MDOT highway routes.Provide traffic information to regional information serviceproviders.Provide traffic information to regional transportation agenciesand the general public through traffic information devicesprimarily DMS.

HighwayManagement

MDOT

Coordinate traffic information and control with other MDOTTMCs.Coordinate maintenance resources for incident response withMDOT TSC construction and maintenance operations.Perform network surveillance for detection and verification ofincidents on MDOT routes.Provide incident information to travelers via traffic informationdevices on highways (eg. DMS).Provide incident information to regional emergencyresponders, including the MSP and local agencies.Responsible for the development, coordination, andexecution of special traffic management strategies during anevacuation.

MDOT

Responsible for the coordination with other traffic operationscenters and emergency management agencies forcoordinated incident management.

IncidentManagement(Traffic)

Local Agency Perform network surveillance for detection and verification ofincidents on local routes.




Provide incident information to regional emergencyresponders, including the MSP and MDOT.

Coordinate maintenance resources for incident response withMDOT Grand Region TSCs and Local Agencies.

IncidentManagement(Traffic)(continued)


Responsible for the coordination with other traffic operationscenters and emergency management agencies forcoordinated incident management.Dispatch MSP vehicles for incidents on highways.Coordinate incident response with other public safetyagencies such as local police, fire, EMS, sheriff as well asMDOT.

MSP

Perform incident detection and verification for the highwayswithin the region and provide this information to traffic andother public safety agencies.Dispatch the local agency emergency vehicles to incidents,including the local agency police, fire, and EMS/rescue.Coordinate public safety resources for incident response onlocal routes.Coordinate incident response with other public safetyagencies (fire, EMS, ambulance, etc.).Receive emergency calls for incidents on local routes.Coordinate public safety resources for incident response onlocal routes.

IncidentManagement(Emergency)

Local Agency

Perform incident detection and verification on local routesand provide this information to the local agency TOC.Dispatch MSP vehicles to incidents within their jurisdiction.Receive AMBER Alert and other wide area alert informationfrom MSP.Receive early warning information and threat informationfrom the NWS and local agencies.Coordinate with regional emergency management providers,maintenance and construction providers, and regional trafficmanagement providers for emergency plans and evacuationand reentry plans.

MSP

Provide regional traffic, transit, emergency management, andmaintenance operations with disaster information todisseminate to the traveling public.Participate in incident response, coordination, and reporting.Dispatch local agency fire/EMS/police vehicles.Perform incident detection and verification on local roadways.Receive AMBER Alert and other wide area alert informationfrom MSP.

Local Agency

Respond to transit emergencies/alarms on-board transitvehicles or at the transit facilities of local transit agencies.

EmergencyManagement

MIOC Participate in the incident response, coordination, andreporting.




Receive requests for maintenance resources for incidentresponse from regional emergency management agencies.Support coordinated response to incidents.Responsible for the tracking and dispatch MDOTmaintenance vehicles.Receive vehicle maintenance conditions from MDOTmaintenance and construction vehicle and coordinate fleetmanagement the with MDOT equipment repair facility.Collect road weather information with MDOT equipment anddistribute it to regional traffic, maintenance, and transitagencies.Provide maintenance of state highways within the region,including pavement maintenance, winter maintenance, andconstruction activities.Manage work zones on all MDOT maintenance andconstruction activities, as well as monitor work zone safetywith MDOT field devices and vehicles.Coordinate maintenance and construction activities with otherregional maintenance and construction agencies.Distribute maintenance and construction plans and work zoneinformation to regional information service providers, regionaltraffic operations, transit operations, emergency operations,rail operations, and the media.

MDOT

Perform maintenance of ITS field equipment owned byMDOT.Receive a request for maintenance resources for incidentresponse from regional emergency management agencies.Coordinate maintenance resources for incidents with otherregional maintenance providers.Receive vehicle location information from local agency DPWvehicles.Dispatch local agency maintenance vehicles.

Local Agency

Provide maintenance of local routes and MDOT facilities (percontract), including pavement maintenance and constructionactivities.

Maintenance andConstructionManagement

Private Operators Provide maintenance of local routes and MDOT facilities (percontract), including pavement maintenance and constructionactivities.Provide fixed route bus service for Muskegon Area TransitSystem.Provide paratransit bus service for the Muskegon AreaTransit System.Track and evaluate schedule performance on all MuskegonArea Transit System fixed route and demand responsevehicles.Provide transit schedule and fare information to theMuskegon Area Transit System website and private sectortraveler information service providers.

TransitManagement

Muskegon AreaTransit System

Provide a paratransit transit plan from the agency website.




Provide transit passenger electronic fare payment on allMuskegon Area Transit System fixed route and demandresponse transit vehicles.Provide transit security on all transit vehicles and at transitterminals through silent alarms and surveillance systems.Provide automated transit maintenance scheduling throughautomated vehicle conditions reports on all Muskegon AreaTransit System fixed route and demand response vehicles.Provide transit traveler information to the agency website,local private sector traveler information services, and thelocal public safety agency in addition to making it available ontransit information kiosks.Coordinate emergency plans with the local public safetyagency and provide emergency transit services forevacuations, fires, and disasters (including re-entry).

Muskegon AreaTransit System(continued)

Collect and archive transit data from Muskegon Area TransitSystem transit operations.Provide fixed route bus service for MAX.Provide paratransit bus service for MAX.Provide transit schedule and fare information to the MAXwebsite and private sector traveler information serviceproviders.Track and evaluate schedule performance on all MAX fixedroute and demand response vehicles.Provide a paratransit transit plan from the agency website.Provide transit passenger electronic fare payment on all MAXfixed route and demand response transit vehicles.Provide transit security on all transit vehicles and at transitterminals through silent alarms and surveillance systems.Provide automated transit maintenance scheduling throughautomated vehicle conditions reports on all MAX fixed routeand demand response vehicles.Coordinate transit service with other regional transit providersas well as regional intermodal terminals and the regionalairport.Provide transit traveler information to the agency website,local private sector traveler information services, and thelocal public safety agency in addition to making it available ontransit information kiosks.Coordinate emergency plans with the local public safetyagency and provide emergency transit services forevacuations, fires, and disasters (including re-entry).

MAX

Collect and archive transit data from MAX transit operations.Provide demand response bus service for the Ionia TransitAuthority.Provide transit schedule and fare information to the IoniaTransit Authority website and private sector travelerinformation service providers.

TransitManagement(continued)

Ionia Transit Authority

Track and evaluate schedule performance on all Ionia TransitAuthority fixed route and demand response vehicles.




Provide a demand response transit plan from the agencywebsite.Provide transit passenger electronic fare payment on all IoniaTransit Authority fixed route and demand response transitvehicles.Provide transit security on all transit vehicles and at transitterminals through silent alarms and surveillance systems.Provide automated transit maintenance scheduling throughautomated vehicle conditions reports on all Ionia TransitAuthority fixed route and demand response vehicles.Coordinate transit service with other regional transit providersas well as regional intermodal terminals and the regionalairport.Provide transit traveler information to the agency website,local private sector traveler information services, and theLocal Public Safety Agency in addition to making it availableon transit information kiosks.Coordinate emergency plans with the local public safetyagency and provide emergency transit services forevacuations, fires, and disasters (including re-entry).

Ionia Transit Authority(continued)

Collect and archive transit data from Ionia Transit Authoritytransit operations.Provide demand response bus service for the RegionalDemand Responsive Transit Providers.Provide transit schedule and fare information to the RegionalDemand Responsive Transit Providers website and privatesector traveler information service providers.Track and evaluate schedule performance on all RegionalDemand Responsive Transit Providers demand responsevehicles.Provide a demand response transit plan from the agencywebsite.Provide transit passenger electronic fare payment on allRegional Demand Responsive Transit Providers demandresponse transit vehicles.Provide transit security on all transit vehicles and at transitterminals through silent alarms and surveillance systems.Provide automated transit maintenance scheduling throughautomated vehicle conditions reports on all Regional DemandResponsive Transit Providers demand response vehicles.Coordinate transit service with other regional transit providersas well as regional intermodal terminals and the regionalairport.Coordinate emergency plans with the local public safetyagency and provide emergency transit services forevacuations, fires, and disasters (including re-entry).

TransitManagement(continued)

Regional DemandResponsive TransitProviders

Collect and archive transit data from Regional DemandResponsive Transit Providers transit operations.




Provide enforcement of regional permits foroverheight/overweight or HAZMAT commercial vehicles.

MSP

Provide first response to commercial vehicle incidents andcoordinate for HAZMAT conditions/clean-up.Provide regional permits (overheight/overweight andHAZMAT) to private fleet systems.Provide automated weigh-in-motion inspections for privatefleet operations.Provide route restriction information to private fleet systems.

CommercialVehicleOperations

MDOT

Provide permit information to regional emergencymanagement providers and regional enforcement agencies.Collection, processing, storage, and broadcast disseminationof traffic, transit, maintenance and construction and weatherinformation to travelers via the 511 Traveler InformationSystem.Provide traveler information to private travelers through invehicle, personal computing devices or kiosks upon request.

MDOT

Provide traveler information to the media.MSP Collect traffic information (road network conditions), work

zone information, travel times, and weather information.Collect traffic information (road network conditions), workzone information, travel times, and weather information.

TravelerInformation

Local Agency

Coordinate and share traveler information with all othertraveler information providers within the region.Collect and archive traffic information from regional trafficmanagement providers and centers, emergency informationfrom MSP and local agency police, and transit informationfrom regional transit agencies for planning purposes.

MDOT

Coordinate with MDOT Transportation Planning Division.


MSP Collect and archive emergency and incident information fromMSP and the region’s emergency responders.


4.4 Potential Agreements

The Regional ITS Architecture for the Grand Region has identified many agency interfaces,information exchanges, and integration strategies that would be needed to provide the ITSservices and systems identified by the stakeholders in the Region. Interfaces and data flowsamong public and private entities in the Region will require agreements among agencies thatestablish parameters for sharing agency information to support traffic management, incidentmanagement, provide traveler information, and perform other functions identified in the RegionalITS Architecture.

With the implementation of ITS technologies, integrating systems from one or more agencies,and the anticipated level of information exchange identified in the architecture, it is likely thatformal agreements between agencies will be needed in the future. These agreements, whileperhaps not requiring a financial commitment from agencies in the Region, should outlinespecific roles, responsibilities, data exchanges, levels of authority, and other facets of regionaloperations. Some agreements will also outline specific funding responsibilities, whereappropriate and applicable.

Agreements should avoid being specific with regards to technology when possible. Technologyis likely to change rapidly and changes to technology could require an update of the agreement ifthe agreement was not technology neutral. Focus of the agreement should be on theresponsibilities of the agencies and the high level information that needs to be exchanged.Depending on the type of agreement being used, agencies should be prepared for the process tocomplete an agreement to take several months to years. Agencies must first reach consensus onwhat should be in an agreement and then proceed through the approval process. The approvalprocess for formal agreements varies by agency and can often be quite lengthy, so it isrecommended that agencies plan ahead to ensure that the agreement does not delay the project.

When implementing an agreement for ITS, it is recommended that as a first step any existingagreements are reviewed to determine whether they can be amended or modified to include theadditional requirements that will come with deploying a system. If there are no existingagreements that can be modified or used for ITS implementation, then a new agreement will needto be developed. The formality and type of agreement used is a key consideration. If thearrangement will be in affect for an extended duration or involve any sort of long termmaintenance, then written agreements should be used. Often during long term operations, staffmay change and a verbal agreement between agency representatives may be forgotten by newstaff.

Common agreement types and potential applications include:

Handshake Agreement: Handshake agreements are often used in the early stage of aproject. This type of informal agreement depends very much on relationships betweenagencies and may not be appropriate for long term operations where staff is likely to change.Memorandum of Understanding (MOU): A MOU demonstrates general consensus orwillingness to participate as part of a particular project but is not typically very detailed.Interagency and Intergovernmental Agreements: These agreements between publicagencies can be used for operation, maintenance, or funding of its projects and systems. Theycan include documentation on the responsibility of each agency, functions they will provide,and liability.Funding Agreements: Funding agreements document the funding arrangements for ITSprojects. At a minimum, funding agreements include a detailed scope, services to beperformed, and a detailed project budget.


Master Agreements: Master agreements include standard contract language for an agencyand serve as the main agreement between two entities which guides all business transactions.Use of a master agreement can allow an agency to do business with another agency or privateentity without having to go through the often lengthy development of a formal agreementeach time.

Table 10 provides a list of existing and potential agreements for the Grand Region based on theinterfaces identified in the Regional ITS Architecture. It is important to note that as ITS servicesand systems are implemented in the Region, part of the planning and review process for thoseprojects should include a review of potential agreements that would be needed forimplementation or operations.

Table 10 - Grand Region Potential Agreements

Status Agreement andAgencies Agreement Description

Future Joint Operations/SharedControl Agreements(Public-Public or Public-Private) – MDOT, LocalAgencies, MSP

These agreements would allow joint operations or controlof certain systems and equipment. The agreement shoulddefine such items as hours of operation and time ofday/day of week when shared control would take effect,circumstances, or incidents when shared control wouldtake effect, notification procedures between the agenciesagreeing to shared control arrangements, overridingcapabilities of owning agency, etc. Private agencies, suchas information service providers that provide traffic reports,could also be part of this agreement.

Future Data Sharing and Usage(Public-Public) – MDOT,Local Agencies, MSP

These agreements would define the parameters,guidelines, and policies for inter- and intra-agency ITS datasharing. This data sharing would support regional activitiesrelated to traffic management, incident management,traveler information, and other functions. The terms of thisagreement should generally address such items as typesof data and information to be shared, how the informationwill be used (traffic incident information to be shared,displayed on web site for travel information, distributed toprivate media, etc.), and parameters for data format,quality, security.

Future Data Sharing and Usage(Public-Private) – MDOT,Local Agencies, media

These agreements would define the parameters,guidelines, and policies for private sector (such as themedia or other information service providers) use of ITSdata. This type of agreement is recommended to defineterms of use for broadcasting public-agency informationregarding traffic conditions, closures, restrictions, as wellas video images. Agreements can also includerequirements for the media to ‘source’ the information (i.e.,using the providing agency’s logo on all video imagesbroadcast.


4.5 Phases of Implementation

The Regional ITS Architecture will be implemented over time through a series of projects led byboth public sector and private sector agencies. Key foundation systems will need to beimplemented in order to support other systems that have been identified in the Regional ITSArchitecture. The deployment of all of the systems required to achieve the final Regional ITSArchitecture build out will occur over many years.

A sequence of projects and their respective time frames have been identified in the GrandRegional ITS Deployment Plan. These projects have been sequenced over a 20-year period, withprojects identified for deployment in 5-, 10- and 20-year timeframes.

Some of the key market packages that will provide the functions for the foundation systems in theGrand Region are listed below. Projects associated with these and other market packagesidentified for the Region have been included in the Grand Regional ITS Deployment Plan.

Network Surveillance;Maintenance and Construction Vehicle Tracking;Weather Information Processing and Distribution;Surface Street Control;Traffic Information Dissemination; andTransit Vehicle Tracking.


5. USE AND MAINTENANCE PLAN FOR THE REGIONAL ITSARCHITECTURE

The ITS Architecture developed for the Grand Region addresses the Region’s vision for ITSimplementation at the time the plan was developed. Stakeholders invested a considerable amount ofeffort in the development of the Regional ITS Architecture and Regional ITS Deployment Plan. As theRegion grows, needs will change, and, as technology progresses, new ITS opportunities will arise.Shifts in regional needs and focus as well as changes in the National ITS Architecture will necessitatethat the Grand Region ITS Architecture be updated to remain a useful resource for the Region.

The following section outlines how the Region and its stakeholders can work with the MDOT ITSProgram Office to ensure projects are in conformity and also provide updates as ITS evolves in theregion.

5.1 Process for Determining Architecture Conformity

The Grand Regional ITS Architecture and Deployment Plan documents the customized marketpackages that were developed as part of the ITS architecture process. To satisfy federalrequirements and remain eligibility to use federal funds, a project must be accuratelydocumented. To document the conformity of an ITS project with the regional architecture,MDOT's ITS Program Office will oversee the development of a regional architectureconformance form to guide project managers through the process. The project managers will beable to coordinate with the ITS Program Office and regional contact for additional assistance andguidance. The steps of the process are as follows:

Identify the ITS components in the project;Identify the corresponding market packages(s) from the Regional ITS Architecture;Locate the component within the market package;Compare the connections to other agencies or elements documented in the ITS architecture aswell as the information flows between them to the connections that will be part of the project;Assess the use of relevant standards; andDocument any changes necessary to the ITS Architecture or the project to ensure there isconformance.

Identifying the ITS Components

ITS components can be fairly apparent in an ITS focused project such as CCTV or DMSdeployments, but could also be included in other types of projects. For example, an arterialwidening project could include the installation of signal system interconnect, signal upgrades, andthe incorporation of the signals in the project limits into the MDOT’s signal system. These are allITS deployments and should be part of the ITS architecture.

Identifying the Corresponding Market Packages

If a project was included in Table 10 of the Deployment Plan, then the applicable marketpackage(s) for that project are identified in a column. ITS projects are not required to be includedin the ITS Deployment Plan in order to be eligible for federal funding; therefore, market packagesmight need to be identified without the assistance of an ITS Deployment Plan. In that case, themarket packages selected and customized for the Grand Region are identified in Table 5 of thisdocument, detailed market package definitions are located in Appendix A, and customizedmarket packages for the Grand Region are included in Appendix B.


Identifying the Component within the Market Package

The customized market packages for the Grand Region are located in Appendix B. Once theelement is located on the market package, the evaluator may determine that the element nameshould be modified. For example, an element called the Local Agency TOC was included in thearchitecture, but at the time of deployment, Muskegon will more than likely decide to call thecenter by a specific name. This name change should be documented using the process outlined inSection 1.3.

Evaluating the Connections and Flows

The connections and architecture flows documented in the market package diagrams wereselected based on the information available at the time the plan was developed. As the projectsare designed, decisions will be made on the system layout that might differ from what is shown inthe market package. These changes in the project should be documented in the ITS marketpackages using the process outlined in Section 1.3.

Relevant Standards

ITS Standards are documented guidelines or rules specifying the interconnections amongelements and the characteristics of technologies and products to be used in ITS installations.Standards describe in detail what types of interfaces should exist between ITS components andhow the components will exchange information and work together to deliver certain user services.The Grand Regional ITS Architecture highlights the relevant standards based on the region’sneeds. These standards should be reviewed as part of this conformity exercise. Where standardscan be utilized, they should be noted. Where standards are not or could not be utilized, anexplanation of why, also should be noted.

Documenting Required Changes

If any changes are needed to accommodate the project under review, Section 1.3 describes howthose changes should be documented. Any changes will be incorporated during the nextarchitecture update. Conformance will be accomplished by documenting how the marketpackage(s) should be modified so that the connections and data flows are consistent with theproject.

5.2 Maintenance Process

MDOT’s ITS Program Office will be responsible for leading the maintenance of the GrandRegional ITS Architecture and Deployment Plan in coordination with the regional contact.Maintenance includes modifications to the plan as well as complete updates. Table 10summarizes the maintenance process agreed upon by stakeholders in the Region.


Table 11 - Regional ITS Architecture and Deployment Plan Maintenance Summary

Regional ITS Architecture Regional ITS Deployment PlanMaintenance

Details Modification CompleteUpdate Modification Complete

UpdateTimeframe forUpdates As needed Every 5-7 years As needed Every 5-7 years

Scope ofUpdate

Update marketpackages to

satisfyarchitectureconformance

requirements ofprojects or to

document otherchanges that

impact the ITSArchitecture

Entire ITSArchitecture

Update projectstatus and add orremove projects

as needed

Entire ITSDeployment Plan

Lead Agency MDOT ITS Program Office* MDOT ITS Program Office*

ParticipantsStakeholdersimpacted by

market packagemodifications

Entire stakeholdergroup Entire stakeholder group

Results

Market package orother change(s)documented fornext complete

update

Updated GrandRegional ITSArchitecturedocument,

Appendices, andTurbo Architecture

database

Updated projecttables

Updated GrandRegional ITS

Deployment Plandocument

* Transit related projects will be supported by MDOT’s Bureau of Passenger Transportation

Modifications to the Regional ITS Architecture and Deployment Plan will often be necessitatedby ITS projects that are receiving federal funding but do not conform to the Regional ITSArchitecture. MDOT’s ITS Program Office will take the lead in working with agencies thatreceive federal funding for ITS projects and will keep a record of any changes that are needed tothe Regional ITS Architecture. Complete updates to the Regional ITS Architecture will occurapproximately every five to seven years and will be led by the MDOT’s ITS Program Office withsupport from the MDOT Grand Region and other key stakeholders. The entire stakeholder groupthat was engaged to develop this first Regional ITS Architecture will be reconvened for thecomplete updates.

5.3 Procedure for Submitting ITS Architecture Changes Between ScheduledUpdates

Updates to the Grand Regional ITS Architecture will occur on a regular basis as described inSection 1.2 to maintain the architecture as a useful planning tool. Between complete planupdates, smaller modifications will likely be required to accommodate ITS projects in the Region.Section 1.1 contains step by step guidance for determining whether or not a project requiresarchitecture modifications.

For situations where a change is required, an ITS Architecture Maintenance Documentation Formwas developed and is included in Appendix E. This form should be completed and submitted tothe MDOT ITS Program Office whenever a change to the Regional ITS Architecture or


Deployment Plan is proposed. Please note that MDOT’s Bureau of Passenger Transportation alsoshould be copied if the project has a transit related component.

The Maintenance Documentation form identifies three levels of modifications. They include:

Level 1 – Basic changes that do not affect the structure of the architecture.Examples include: Changes to stakeholder or element name, element status, or data flowstatus.Level 2 – Structural changes that impact only one agency.Examples include: Addition of a new market package or modifications to an existing marketpackage that affects only one agency.Level 3 – Structural changes that have the potential to impact multiple agencies.Examples include: Addition of a new market package or modifications to an existing marketpackage that involves multiple agencies or incorporation of a new stakeholder into thearchitecture.

While documenting the proposed change, the project manager completing the change form shouldcoordinate with any of the other agencies that may be impacted by the modification. Thiscommunication between agencies will simplify the process of performing a complete plan update.MDOT’s ITS Program Office will review and accept the proposed changes. When a completeupdate is performed by MDOT’s ITS Program Office, all of the documented changes will beincorporated into the regional ITS architecture. Figure 11 graphically illustrates this process.


Figure 11 - Process for Documenting Architecture Performance

grand region its architecture - michigan

Documents