910.4 ITS Architecture - Revision history

Hoskir: updated links

2025-04-01T20:48:54Z

updated links

← Older revision		Revision as of 15:48, 1 April 2025
Line 8:		Line 8:
	\|[http://www.marc2.org/Assets/ITS/index.htm Kansas City Regional ITS Architecture]		\|[http://www.marc2.org/Assets/ITS/index.htm Kansas City Regional ITS Architecture]
	\|-		\|-
	\|[https://www.ozarkstransportation.org/our-resources/~~plans~~ Springfield/Branson Regional ITS Architecture]		\|[https://www.ozarkstransportation.org/our-resources/reports-and-studies Springfield/Branson Regional ITS Architecture]
	\|-		\|-
	\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]		\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]
Line 230:		Line 230:
	====910.4.1.5.3 Springfield Area====		====910.4.1.5.3 Springfield Area====

	The City of Springfield, in close cooperation with MoDOT, leads the development of [https://www.ozarkstransportation.org/our-resources/~~plans~~ the Regional ITS Architecture].		The City of Springfield, in close cooperation with MoDOT, leads the development of [https://www.ozarkstransportation.org/our-resources/reports-and-studies the Regional ITS Architecture].

	====910.4.1.5.4 State Business Plan for CVISN ====		====910.4.1.5.4 State Business Plan for CVISN ====

Smithk: Smithk moved page 910.4 ITS Achitecture to 910.4 ITS Architecture: typo

2020-09-24T18:21:36Z

Smithk moved page 910.4 ITS Achitecture to 910.4 ITS Architecture: typo

← Older revision	Revision as of 13:21, 24 September 2020
(No difference)

Smithk at 20:22, 18 August 2020

2020-08-18T20:22:02Z

← Older revision		Revision as of 15:22, 18 August 2020
Line 360:		Line 360:
	\|[http://library.modot.mo.gov/RDT/reports/Rd09004/or10013.pdf Evaluation of Arterial Service Patrol Programs]		\|[http://library.modot.mo.gov/RDT/reports/Rd09004/or10013.pdf Evaluation of Arterial Service Patrol Programs]
	\|-		\|-
	\|'''See also:''' [~~http~~://www.modot.~~gov~~/~~services/OR/byDate.htm Innovation Library~~]		\|'''See also:''' [https://www.modot.org/research-publications Research Publications]\|}
	\|}

	The Incident Management ITS Program is composed of the following four market packages and associated deployment areas/settings:		The Incident Management ITS Program is composed of the following four market packages and associated deployment areas/settings:

Smithk: Per TS, updated links

2019-10-25T15:25:15Z

Per TS, updated links

← Older revision		Revision as of 10:25, 25 October 2019
Line 8:		Line 8:
	\|[http://www.marc2.org/Assets/ITS/index.htm Kansas City Regional ITS Architecture]		\|[http://www.marc2.org/Assets/ITS/index.htm Kansas City Regional ITS Architecture]
	\|-		\|-
	\|[~~http~~://www.ozarkstransportation.org/~~Plans%20&%20Publications~~/~~MPPIndex.html~~ Springfield/Branson Regional ITS Architecture]		\|[https://www.ozarkstransportation.org/our-resources/plans Springfield/Branson Regional ITS Architecture]
	\|-		\|-
	\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]		\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]
Line 230:		Line 230:
	====910.4.1.5.3 Springfield Area====		====910.4.1.5.3 Springfield Area====

	The City of Springfield, in close cooperation with MoDOT, leads the development of [~~http~~://www.ozarkstransportation.org/~~Plans%20&%20Publications~~/~~MPPIndex.html~~ the Regional ITS Architecture].		The City of Springfield, in close cooperation with MoDOT, leads the development of [https://www.ozarkstransportation.org/our-resources/plans the Regional ITS Architecture].

	====910.4.1.5.4 State Business Plan for CVISN ====		====910.4.1.5.4 State Business Plan for CVISN ====

Smithk: Per TS, replaced archaic “Motorist Assist” with "Emergency Response"

2019-04-29T17:39:21Z

Per TS, replaced archaic “Motorist Assist” with "Emergency Response"

Smithk at 14:37, 3 January 2019

2019-01-03T14:37:50Z

← Older revision		Revision as of 09:37, 3 January 2019
Line 12:		Line 12:
	\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]		\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]
	\|-		\|-
	\|[[media:910.4.1.2 SEA format\|Systems Engineering Analysis standard format]]		\|[[media:910.4.1.2 SEA format.docx\|Systems Engineering Analysis standard format]]
	\|-		\|-
	\|[[media:System Interface Diagrams.pdf\|System Interface Diagrams]]		\|[[media:System Interface Diagrams.pdf\|System Interface Diagrams]]
Line 92:		Line 92:
	:* Procedures and resources necessary for Operations and Maintenance of the system.		:* Procedures and resources necessary for Operations and Maintenance of the system.

	A [[media:910.4.1.2 SEA format\|standard format]] has been provided for use when creating a SEA. The SEA should be stored in the project files and kept according to MoDOT document retention policy.		A [[media:910.4.1.2 SEA format.docx\|standard format]] has been provided for use when creating a SEA. The SEA should be stored in the project files and kept according to MoDOT document retention policy.

	The project shall also work with the regional ITS architecture. Specifically, it shall “accommodate the interface requirements and information exchanges” that are within the regional architecture. If the regional ITS architecture is not completed and an ITS project enters final design then it will have project level architecture. The project level architecture is based off the SEA and will include the following information:		The project shall also work with the regional ITS architecture. Specifically, it shall “accommodate the interface requirements and information exchanges” that are within the regional architecture. If the regional ITS architecture is not completed and an ITS project enters final design then it will have project level architecture. The project level architecture is based off the SEA and will include the following information:

Smithk: Per TS, new guidance on completing the SEA on all ITS projects according to 23 CFR 940.11. The need was identified by a TMC audit.

2019-01-03T14:36:37Z

Per TS, new guidance on completing the SEA on all ITS projects according to 23 CFR 940.11. The need was identified by a TMC audit.

← Older revision		Revision as of 09:36, 3 January 2019
Line 11:		Line 11:
	\|-		\|-
	\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]		\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]
			\|-
			\|[[media:910.4.1.2 SEA format\|Systems Engineering Analysis standard format]]
	\|-		\|-
	\|[[media:System Interface Diagrams.pdf\|System Interface Diagrams]]		\|[[media:System Interface Diagrams.pdf\|System Interface Diagrams]]
Line 78:		Line 80:
	The Regional ITS architecture requires 4 years to develop, starting on the date of the region’s first ITS project or from the date of the final rule where there are existing systems.		The Regional ITS architecture requires 4 years to develop, starting on the date of the region’s first ITS project or from the date of the final rule where there are existing systems.
	The Regional ITS architecture develops and implements procedures and responsibilities for maintaining architecture databases, as needs evolve within the region.		The Regional ITS architecture develops and implements procedures and responsibilities for maintaining architecture databases, as needs evolve within the region.
			<div id="Project ITS Architecture Documentations Requirements"></div>
			'''Project ITS Architecture Documentations Requirements '''

			If an ITS project uses federal funds or “highway trust funds” then a systems engineering analysis (SEA) must be completed. The SEA must include the following information:

			:* Identify portions of the regional ITS architecture being implemented
			:* Identify participating agencies’ roles and responsibilities
			:* Analyze alternative system configuration and technology options to meet requirements of the project and the system
			:* Procurement Options
			:* Identify applicable ITS standards and test procedures ([[#Table 910.4.5.3 Program Area Standards\|Table 910.4.5.3]] for applicable standards)
			:* Procedures and resources necessary for Operations and Maintenance of the system.

	~~'''Project ITS Architecture Documentations Requirements '''~~		A [[media:910.4.1.2 SEA format\|standard format]] has been provided for use when creating a SEA. The SEA should be stored in the project files and kept according to MoDOT document retention policy.
	~~Using a system engineering approach, identify:~~
	*Portions of the regional ITS architecture ~~being implemented~~		The project shall also work with the regional ITS architecture. Specifically, it shall “accommodate the interface requirements and information exchanges” that are within the regional architecture. If the regional ITS architecture is not completed and an ITS project enters final design then it will have project level architecture. The project level architecture is based off the SEA and will include the following information:
	* Participating agencies roles and ~~responsibilities~~
	* Requirements definitions
	* Analysis of alternative system configurations and ~~technology options~~
	* Procurement options
	* Identification of applicable ITS ~~standards~~ and ~~testing procedures~~
	* Procedures and resources necessary for operations and management of the ~~system~~
	~~Projects should be consistent with the Regional Architecture or the Regional Architecture should be updated.~~

	There is little direction provided on the requirements for a statewide ITS Architecture. In an attempt to meet yet-to-be-defined requirements for a state that has multiple regional architectures, the Missouri Statewide ITS Architecture has been developed in ~~close relation to~~ the requirements of ~~a regional ITS architecture with~~ the ~~exception that specific interface~~ requirements ~~have not been defined (i.e., architecture flow diagrams)~~.		:* Description of project scope
			:* Roles and responsibilities of participating agencies/stakeholders in operation/implementation of the project
			:* Functional requirements of the project
			:* Interface/information exchange requirements between other planned/existing systems/subsystems
			:* Applicable ITS standards.

	===910.4.1.3 Impact of Rules on Missouri===		===910.4.1.3 Impact of Rules on Missouri===

EPGsysop: Updated link to Bi-State St. Louis Regional ITS Architecture

2017-12-19T13:34:01Z

Updated link to Bi-State St. Louis Regional ITS Architecture

← Older revision		Revision as of 08:34, 19 December 2017
Line 10:		Line 10:
	\|[http://www.ozarkstransportation.org/Plans%20&%20Publications/MPPIndex.html Springfield/Branson Regional ITS Architecture]		\|[http://www.ozarkstransportation.org/Plans%20&%20Publications/MPPIndex.html Springfield/Branson Regional ITS Architecture]
	\|-		\|-
	\|[http://www.ewgateway.org/~~trans~~/~~ITS~~/~~its.htm~~ Bi-State St. Louis Regional ITS Architecture]		\|[http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ Bi-State St. Louis Regional ITS Architecture]
	\|-		\|-
	\|[[media:System Interface Diagrams.pdf\|System Interface Diagrams]]		\|[[media:System Interface Diagrams.pdf\|System Interface Diagrams]]
Line 214:		Line 214:
	====910.4.1.5.2 St. Louis Area ====		====910.4.1.5.2 St. Louis Area ====

	The St. Louis Metropolitan Region is developing a [http://www.ewgateway.org/~~trans~~/~~ITS~~/~~its.htm~~ regional ITS architecture] through the use of a Tier 2 Workshop lead by the National ITS Architecture Team in St. Louis. MoDOT District 6 personnel maintain the current database.		The St. Louis Metropolitan Region is developing a [http://www.ewgateway.org/transportation-planning/transportation-systems-management-operations/intelligent-transportation-system/ regional ITS architecture] through the use of a Tier 2 Workshop lead by the National ITS Architecture Team in St. Louis. MoDOT District 6 personnel maintain the current database.

	A project architecture to support the I-270/255 Corridor Project was also developed. The scope of the deployment project includes installation of five systems: Traffic Management System, Local Traffic Operations System, Local Emergency Response System, Transit Management System and Information Service Providers. The five systems are interrelated and contain subsystems that can also be interconnected within each system.		A project architecture to support the I-270/255 Corridor Project was also developed. The scope of the deployment project includes installation of five systems: Traffic Management System, Local Traffic Operations System, Local Emergency Response System, Transit Management System and Information Service Providers. The five systems are interrelated and contain subsystems that can also be interconnected within each system.

Smithk: Per TS, updated ITS links and removed "Equipment Packages of St. Louis Regional ITS Architecture"

2015-12-18T13:51:23Z

Per TS, updated ITS links and removed "Equipment Packages of St. Louis Regional ITS Architecture"

Smithk at 14:16, 19 June 2013

2013-06-19T14:16:19Z

← Older revision		Revision as of 09:16, 19 June 2013
Line 2:		Line 2:

	MoDOT is developing a statewide approach to Intelligent Transportation Systems (ITS) implementation. This article, an ITS Architecture Package, documents a framework that will assist in coordinating future ITS planning, deployment and operations activities for Missouri. Currently, freeway management, arterial management, commercial vehicle, and other systems are being deployed in the state. As part of the statewide plan, market packages were prioritized and presented in the Market Package Report. The ITS Architecture Package captures the status of ITS development in Missouri at a given time (2002) and should be viewed as a dynamic tool. It is recommended that MoDOT revisit the architecture on an annual basis updating and tracking the development of ITS in Missouri through an active architecture revision process.		MoDOT is developing a statewide approach to Intelligent Transportation Systems (ITS) implementation. This article, an ITS Architecture Package, documents a framework that will assist in coordinating future ITS planning, deployment and operations activities for Missouri. Currently, freeway management, arterial management, commercial vehicle, and other systems are being deployed in the state. As part of the statewide plan, market packages were prioritized and presented in the Market Package Report. The ITS Architecture Package captures the status of ITS development in Missouri at a given time (2002) and should be viewed as a dynamic tool. It is recommended that MoDOT revisit the architecture on an annual basis updating and tracking the development of ITS in Missouri through an active architecture revision process.
	{\|style="padding: 0.3em; margin-left:~~1px~~; border:2px solid #a9a9a9; text-align:center; font-size: 95%; background:#f5f5f5" width="240px" align="right"		{\|style="padding: 0.3em; margin-left:8px; border:2px solid #a9a9a9; text-align:center; font-size: 95%; background:#f5f5f5" width="240px" align="right"
	\|-		\|-
	\|'''Additional Information'''		\|'''Additional Information'''

← Older revision		Revision as of 12:39, 29 April 2019
Line 130:		Line 130:
	Roadside Subsystems. Intelligent infrastructure distributed along the transportation network which perform surveillance, information provision and plan execution control functions and whose operation is governed by center subsystems. Direct interface to vehicle subsystems exist.<sup>2</sup> An example of a roadside subsystem could be a variable message sign on the interstate.		Roadside Subsystems. Intelligent infrastructure distributed along the transportation network which perform surveillance, information provision and plan execution control functions and whose operation is governed by center subsystems. Direct interface to vehicle subsystems exist.<sup>2</sup> An example of a roadside subsystem could be a variable message sign on the interstate.

	Vehicle Subsystems cover ITS related elements on vehicle platforms. Vehicle subsystems include general driver information and safety systems applicable to all vehicle types. Four fleet vehicle subsystems (Transit, Emergency, Commercial Vehicles and the newly added Maintenance and Construction) add ITS capabilities unique to these special vehicle types.<sup>3</sup> Examples of vehicle subsystems include automatic vehicle location systems on transit vehicles or the ~~motorist assist~~ vehicles.		Vehicle Subsystems cover ITS related elements on vehicle platforms. Vehicle subsystems include general driver information and safety systems applicable to all vehicle types. Four fleet vehicle subsystems (Transit, Emergency, Commercial Vehicles and the newly added Maintenance and Construction) add ITS capabilities unique to these special vehicle types.<sup>3</sup> Examples of vehicle subsystems include automatic vehicle location systems on transit vehicles or the Emergency Response vehicles.

	Traveler Subsystems are equipment used by travelers to access ITS services pre-trip and en route. This includes elements that are owned and operated by the traveler as well as elements that are owned by transportation and information providers.<sup>4</sup> An example of a traveler subsystem could be an information kiosk at an [[:Category:122 Aviation\|airport]].		Traveler Subsystems are equipment used by travelers to access ITS services pre-trip and en route. This includes elements that are owned and operated by the traveler as well as elements that are owned by transportation and information providers.<sup>4</sup> An example of a traveler subsystem could be an information kiosk at an [[:Category:122 Aviation\|airport]].
Line 173:		Line 173:
	=====910.4.1.4.1.7 Market Packages =====		=====910.4.1.4.1.7 Market Packages =====

	A market package provides an accessible, service-oriented perspective to the National ITS Architecture. They are tailored to fit, separately or in combination, real world transportation problems and needs. Examples of market packages include: network surveillance, emergency response, and maintenance and construction vehicle tracking. Market packages are a collection of one or more groupings of implementable processes. These processes must work together to deliver a given transportation service and the architecture flows that connect them and other important external systems. In other words, they identify the pieces of the physical architecture that are required to implement a particular transportation service. There are currently 75 Market Packages included in the most recent version of the National ITS Architecture (Version 4.0) that was planned for mass public release in April 2002. The most significant impact to Missouri is the additional 10 market packages oriented to support Rural ITS services. Since Kansas City and St. Louis have existing ~~Motorist Assist~~ Programs, the addition of the Roadway Service Patrol Market Package will have an impact on existing regional architectures. Additional discussion on Market Packages and their use in prioritizing core ITS Program Areas in Missouri is provided in [[910.4 ITS Achitecture#910.4.3 Missouri ITS Program Areas\|EPG 910.4.3 Missouri ITS Program Areas]].		A market package provides an accessible, service-oriented perspective to the National ITS Architecture. They are tailored to fit, separately or in combination, real world transportation problems and needs. Examples of market packages include: network surveillance, emergency response, and maintenance and construction vehicle tracking. Market packages are a collection of one or more groupings of implementable processes. These processes must work together to deliver a given transportation service and the architecture flows that connect them and other important external systems. In other words, they identify the pieces of the physical architecture that are required to implement a particular transportation service. There are currently 75 Market Packages included in the most recent version of the National ITS Architecture (Version 4.0) that was planned for mass public release in April 2002. The most significant impact to Missouri is the additional 10 market packages oriented to support Rural ITS services. Since Kansas City and St. Louis have existing Emergency Response Programs, the addition of the Roadway Service Patrol Market Package will have an impact on existing regional architectures. Additional discussion on Market Packages and their use in prioritizing core ITS Program Areas in Missouri is provided in [[910.4 ITS Achitecture#910.4.3 Missouri ITS Program Areas\|EPG 910.4.3 Missouri ITS Program Areas]].

	====910.4.1.4.2 Overview of Logical Architecture ====		====910.4.1.4.2 Overview of Logical Architecture ====
Line 257:		Line 257:
	: '''Improved Rural User Needs Coverage.''' Changes and additions have been made to the architecture to satisfy the "Rural User Needs" requirements in the industry. Areas of the architecture affected include the creation of a new terminator called the "Care Facility" and enhancing remote area surveillance to include rest areas, park and ride lots, emergency pull-off areas, etc.		: '''Improved Rural User Needs Coverage.''' Changes and additions have been made to the architecture to satisfy the "Rural User Needs" requirements in the industry. Areas of the architecture affected include the creation of a new terminator called the "Care Facility" and enhancing remote area surveillance to include rest areas, park and ride lots, emergency pull-off areas, etc.

	: '''Roadway Service Patrols Coverage.''' Additions have been made to the architecture to accommodate an increased use of roadway service patrols throughout the country. The new market package accurately encompasses the existing functions of the ~~Motorist Assist~~ Patrol in Kansas City and St. Louis.		: '''Roadway Service Patrols Coverage.''' Additions have been made to the architecture to accommodate an increased use of roadway service patrols throughout the country. The new market package accurately encompasses the existing functions of the Emergency Response Patrol in Kansas City and St. Louis.

	==910.4.2 Missouri High Level Physical Architecture ==		==910.4.2 Missouri High Level Physical Architecture ==
Line 281:		Line 281:
	\|Branson TMC and TRIP\|\|KDOT Metro Operations Area		\|Branson TMC and TRIP\|\|KDOT Metro Operations Area
	\|-		\|-
	\|IDOT St. Louis Area Traveler Information Center\|\|MoDOT ~~Motorist Assist~~		\|IDOT St. Louis Area Traveler Information Center\|\|MoDOT Emergency Response
	\|-		\|-
	\|Missouri State Highway Patrol\|\|Metro Traffic Networks		\|Missouri State Highway Patrol\|\|Metro Traffic Networks
Line 370:		Line 370:
	::* Roadway Service Patrols, Urban		::* Roadway Service Patrols, Urban

	The Roadway Service Patrol Market Package was not part of the initial Market Package Assessment since it has only recently been released as part of Version 4.0 of the National ITS Architecture. However, since existing, and very successful, ~~Motorist Assist~~ Patrols operate in the Kansas City and St. Louis areas, the new market package has been added to the Incident Management Program Area. During the next iteration of using the Prioritization Tool, it is extremely likely the Roadway Service Patrol market package will score very high.		The Roadway Service Patrol Market Package was not part of the initial Market Package Assessment since it has only recently been released as part of Version 4.0 of the National ITS Architecture. However, since existing, and very successful, Emergency Response Patrols operate in the Kansas City and St. Louis areas, the new market package has been added to the Incident Management Program Area. During the next iteration of using the Prioritization Tool, it is extremely likely the Roadway Service Patrol market package will score very high.
	For reference purposes, definitions of each market package are provided below:		For reference purposes, definitions of each market package are provided below:

← Older revision		Revision as of 08:51, 18 December 2015
Line 6:		Line 6:
	\|'''Additional Information'''		\|'''Additional Information'''
	\|-		\|-
	\|[~~[media~~:~~Kansas City Regional~~ ITS ~~Architecture~~.~~pdf\|~~Kansas City Regional ITS Architecture]]		\|[http://www.marc2.org/Assets/ITS/index.htm Kansas City Regional ITS Architecture]
	\|-		\|-
	\|[~~[media~~:~~Springfield Branson Regional Architecture~~.~~pdf\|~~Springfield/Branson Regional ITS Architecture]]		\|[http://www.ozarkstransportation.org/Plans%20&%20Publications/MPPIndex.html Springfield/Branson Regional ITS Architecture]
	\|-		\|-
	\|[~~[media~~:~~Bi-State St~~. ~~Louis Regional~~ ITS ~~Architecture~~.~~pdf\|~~Bi-State St. Louis Regional ITS Architecture]]		\|[http://www.ewgateway.org/trans/ITS/its.htm Bi-State St. Louis Regional ITS Architecture]
	\|-
	~~\|[[media:Equipment Packages of St. Louis Regional ITS Architecture.pdf\|Equipment Packages of St. Louis Regional ITS Architecture]~~]
	\|-		\|-
	\|[[media:System Interface Diagrams.pdf\|System Interface Diagrams]]		\|[[media:System Interface Diagrams.pdf\|System Interface Diagrams]]
Line 212:		Line 210:
	====910.4.1.5.1 Kansas City Area ====		====910.4.1.5.1 Kansas City Area ====

	The Kansas City Metropolitan Region is developing a [~~[media~~:~~Kansas City Regional~~ ITS ~~Architecture~~.~~pdf\|~~regional ITS architecture]] through the use of a Tier 2 Workshop lead by the National ITS Architecture Team in Kansas City. The [http://www.marc.org/ Mid America Regional Council (MARC)], the regional metropolitan planning organization, maintains the current database.		The Kansas City Metropolitan Region is developing a [http://www.marc2.org/Assets/ITS/index.htm regional ITS architecture] through the use of a Tier 2 Workshop lead by the National ITS Architecture Team in Kansas City. The [http://www.marc.org/ Mid America Regional Council (MARC)], the regional metropolitan planning organization, maintains the current database.

	====910.4.1.5.2 St. Louis Area ====		====910.4.1.5.2 St. Louis Area ====

	The St. Louis Metropolitan Region is developing a [~~[media~~:~~Bi-State St~~. ~~Louis Regional~~ ITS ~~Architecture~~.~~pdf\|~~regional ITS architecture]] through the use of a Tier 2 Workshop lead by the National ITS Architecture Team in St. Louis. MoDOT District 6 personnel maintain the current database.		The St. Louis Metropolitan Region is developing a [http://www.ewgateway.org/trans/ITS/its.htm regional ITS architecture] through the use of a Tier 2 Workshop lead by the National ITS Architecture Team in St. Louis. MoDOT District 6 personnel maintain the current database.

	A project architecture to support the I-270/255 Corridor Project was also developed. The scope of the deployment project includes installation of five systems: Traffic Management System, Local Traffic Operations System, Local Emergency Response System, Transit Management System and Information Service Providers. The five systems are interrelated and contain subsystems that can also be interconnected within each system.		A project architecture to support the I-270/255 Corridor Project was also developed. The scope of the deployment project includes installation of five systems: Traffic Management System, Local Traffic Operations System, Local Emergency Response System, Transit Management System and Information Service Providers. The five systems are interrelated and contain subsystems that can also be interconnected within each system.
Line 222:		Line 220:
	====910.4.1.5.3 Springfield Area====		====910.4.1.5.3 Springfield Area====

	The City of Springfield, in close cooperation with MoDOT, leads the development of [~~[media~~:~~Springfield Branson Regional Architecture~~.~~pdf\|~~the Regional ITS Architecture]].		The City of Springfield, in close cooperation with MoDOT, leads the development of [http://www.ozarkstransportation.org/Plans%20&%20Publications/MPPIndex.html the Regional ITS Architecture].

	====910.4.1.5.4 State Business Plan for CVISN ====		====910.4.1.5.4 State Business Plan for CVISN ====

	The State Business Plan for Commercial Vehicle Information Systems and Networks (CVISN) was completed in late 2000. The report includes the definition of several projects associated with Level 1 CVISN deployment in Missouri including a high level physical architecture. However, the physical architecture does not directly map to the National ITS Architecture and did not use the USDOT endorsed database-mapping tool (i.e., TurboArchitecture). CVISN activities are lead by [http://~~wwwi~~/~~intranet~~/tr/ Traffic].		The State Business Plan for Commercial Vehicle Information Systems and Networks (CVISN) was completed in late 2000. The report includes the definition of several projects associated with Level 1 CVISN deployment in Missouri including a high level physical architecture. However, the physical architecture does not directly map to the National ITS Architecture and did not use the USDOT endorsed database-mapping tool (i.e., TurboArchitecture). CVISN activities are lead by [http://sharepoint/systemdelivery/tr/Pages/default.aspx Traffic].

	===910.4.1.6 Emerging National ITS Architecture Developments ===		===910.4.1.6 Emerging National ITS Architecture Developments ===