CDOT ITS Architecture Plan


Per 23 Code of Federal Regulations (CFR) 940, CDOT is required to create a CDOT specific ITS Architecture Plan. At a national level, The United States Department of Transportation maintains a National ITS Architecture Plan. The National ITS Architecture Plan is broken out into service packages. A service package is documenting a particular application of a technology or identifies a specific problem that technology will be used to solve. CDOT is required per 23 CFR 940 to select the applicable service packages from the National ITS Architecture Plan that will fulfill our technology vision and make them CDOT specific.  

Current Status of the CDOT ITS Architecture Plan

CDOT is drafting a Charter and building a multi-disciplinary team to create a robust CDOT specific ITS Architecture Plan.  The current CDOT ITS Architecture Plan is out of date and should not be used. As service packages are developed, they will be published on this page. Check back frequently to see the status. In the mean time, project managers are required to use the National ITS Architecture Plan while completing the System Engineering Analysis (SEA) documents.  Projects are to be built to the applicable service package(s). Should the service package not reflect the desired proposed system, the project manager will use the SEA process to determine if the modification is allowed. 

National ITS Architecture Plan - To Be Used Until Told Otherwise

Content of a Service Package

High Level Summary of ITS Architecture Plan - Page 1.jpeg

Each service package that has been made CDOT specific will contain the following high level information to help promote consistency across CDOT: 

  • Description: A CDOT customized description using the National ITS Architecture as a foundation. 
  • Stakeholders/End Users: Defines the roles and responsibilities of stakeholders and end users who will always need to be involved on projects related to the service package. 
  • Elements: The different components that are required and make up the system. These are the minimum elements. Should a project want to add or remove an element, the SEA Process will document the change and prompt discussions to determine if the change is possible. 
  • Interfaces: The defined communications that must occur between the elements for the system to operate as intended.  
  • Functional objects: The different categories that make up an element and are broken out into functional requirements. Some elements occur in multiple service packages with different uses. Only the applicable functional objects (and therefore functional requirements) of an element need to be noted for a service package. This is helpful because it reduces the functional requirements a project would have to fulfill by removing the function objects and requirements that fall outside of the service package description. 
  • Functional requirements: The minimum requirements each element must meet in order for the system to operate as intended.

The service package is to promote consistency. A project will use a service package as a foundation when navigating through the Systems Engineering Analysis (SEA) Process. Should a project need to deviate from the applicable service package, the SEA will also be used to vet this change. 

Benefits of the CDOT ITS Architecture Plan 

Having a well defined and established CDOT ITS Architecture Plan will provide the following benefits to CDOT: 

  • Fulfill the requirements of 23 CFR 940
  • Creates consistency across CDOT through documenting how systems must work 
  • Saves time by having the foundation of a system documented and pre-determined prior to a project occurring
  • Documents the stakeholders who should always be involved
  • Used as a resources for project managers, especially those new to technology 
  • Reduces bottle necks of information requests by providing information upfront 
  • Increases the ITS & Network Service Branch's transparency