Because of the extensive geographic and functional scope of the ITS Architecture for Canada and the requirements, which drove its development, it is structured somewhat differently and uses different terminology than is typically used today in the transportation community. It was developed to support ITS implementations over a 20-year time period in urban, interurban, and rural environments across the country. Accordingly, general names were given to the physical transportation system components and locations in order to accommodate a variety of local design choices and changes in technology or institutional arrangements over time. This allows the general structure of the ITS Architecture for Canada to remain stable while still allowing flexibility and tailoring at the local implementation level. This difference in language can be easily overcome with a better understanding of how the ITS Architecture for Canada is organized and how it relates to familiar systems of today.
As background, this paper explains the essential terminology and concepts needed to understand, navigate, and use the ITS Architecture for Canada. The following concepts and terms are explained in this section:
User services represent what the system will do from the perspective of the user. A user might be the public or a system operator.
Table 1 presents the 37 user services which formed the basis for the ITS Architecture for Canada development effort, grouped into eight bundles for convenience. The important point is that the concept of user services allows the process of system or project definition to begin by thinking about what high level services will be provided to address identified problems and needs. New or updated user services may be added to the ITS Architecture for Canada over time.
Table 1. User Services for the ITS Architecture for Canada
|User Service Bundle||User Service|
Pre-Trip Travel Information
En-Route Driver Information
Route Guidance and Navigation
Ride Matching And Reservation
Traveller Services Information
Travel Demand Management
Emissions Testing And Mitigation
Automated Dynamic Warning and Enforcement
Non-Vehicular Road User Safety
|Public Transportation Management||
Public Transportation Management|
En-Route Transit Information
Demand Responsive Transit
Public Travel Security
|Electronic Payment||Electronic Payment Services|
|Commercial Vehicle Operations||Commercial Vehicle Electronic Clearance
Automated Roadside Safety Inspection
On-Board Safety and Security Monitoring
Commercial Vehicle Administrative Processes
Hazardous Materials Planning and Incident Response
Intermodal Freight Management
International Border Transportation Management
|Emergency Management||Emergency Notification And Personal Security
Emergency Vehicle Management
Disaster Response and Evacuation
|Advanced Vehicle Safety Systems||Longitudinal Collision Avoidance
Lateral Collision Avoidance
Intersection Collision Avoidance
Vision Enhancement For Crash Avoidance
Pre-Crash Restraint Deployment
Automated Vehicle Operation
|Information Management||Archived Data|
|Maintenance and Construction Management||Maintenance and Construction Operations|
A number of functions are required to accomplish each user service. To reflect this, each of the user services was broken down into successively more detailed functional statements, called user service requirements. For example, the traffic control user service is actually defined by over 40 "functions". In the Logical Architecture documentation, the user service requirements can be reviewed. Many of these user service requirements can be implemented today, although some of them may be more representative of future capabilities and should be deferred for now. These requirements can be used as a departure point for the development of project functional requirements and system specifications.
Table 2 provides an illustration of user service requirements using an excerpt from the traffic control user service.
Table 2. User Service Requirements Example
|1.6.0 ITS shall include a Traffic Control (TC) function. Traffic Control provides the capability to efficiently manage the movement of traffic on streets and highways. Four functions are provided which are (1)Traffic Flow Optimization, (2)Traffic Surveillance, (3)Control, and (4)Provide Information. This will also include control of network signal systems with eventual integration of freeway control.|
|1.6.1 TC shall include a Traffic Flow Optimization function to provide the capability to optimize traffic flow.|
|184.108.40.206Traffic Flow Optimization shall employ control strategies that seek to maximize traffic-movement efficiency.|
|220.127.116.11Traffic Flow Optimization shall include a wide area optimization capability, to include several jurisdictions.|
|18.104.22.168.1 Wide area optimization shall integrate the control of network signal systems with the control of freeways.|
|22.214.171.124.2 Wide area optimization shall include features that provide preferential treatment for transit vehicles.|
|1.6.2 TC shall include a Traffic Surveillance function.|
A logical architecture is best described as a tool that assists in organizing complex entities and relationships. It focuses on the functional processes and information flows of a system. Developing a logical architecture helps identify the system functions and information flows, and guides development of functional requirements for new systems and improvements. A logical architecture should be independent of institutions and technology, i.e., it should not define where or by whom functions are performed in the system, nor should it identify how functions are to be implemented.
The logical architecture of the ITS Architecture for Canada defines a set of functions (or processes) and information flows (or data flows) that respond to the user service requirements discussed above. Processes and data flows are grouped to form particular transportation management functions (e.g., manage traffic) and are represented graphically by data flow diagrams (DFDs), or bubble charts, which decompose into several levels of detail. In these diagrams, processes are represented as bubbles and data flows as arrows.
Processes can be further broken down into sub-processes. At the lowest level of detail in the functional hierarchy are the process specifications (referred to as PSpecs in the documentation). These process specifications can be thought of as the elemental functions to be performed in order to satisfy the user service requirements (i.e., they are not broken out any further). The information exchanges between processes and between PSpecs are called the (logical) data flows.
A physical architecture is the physical (versus functional) view of a system. A physical architecture provides agencies with a physical representation (though not a detailed design) of how the system should provide the required functionality. A physical architecture takes the processes (or PSpecs) identified in the logical architecture and assigns them to physical entities (called subsystems in the ITS Architecture for Canada). In addition, the data flows (from the logical architecture) that originate from one subsystem and end at another are grouped together into (physical) architecture flows. In other words, one architecture flow may contain one or more detailed data flows. These architecture flows and their communication requirements define the interfaces required between subsystems, which form the basis for much of the ongoing standards work in the ITS program. Development of a physical architecture will identify the desired communications and interactions between different transportation management organizations.
Figure 1 depicts the relationship between the logical and physical architecture. The dashed lines in the figure highlight the relationship between functions or processes in the logical architecture to subsystems in the physical architecture and between data flows in the logical architecture to architecture flows in the physical architecture.
Figure 1. Representative Logical and Physical Architecture
In the ITS Architecture for Canada, the physical architecture is described by two layers: the transportation layer and the communications layer. Each of these is briefly described below.
The transportation layer of the physical architecture shows the relationships among the transportation-management-related elements. It is composed of subsystems for travellers, vehicles, transportation management centres, and field devices, as well as external system interfaces at the boundaries (called terminators in the documentation).
The transportation layer may include:
The communications layer of the physical architecture provides the communications services that connect the transportation layer components. This layer depicts all of the communications necessary to transfer information and data among transportation entities, traveller information and emergency service providers, and other service providers such as towing and recovery. The communications layer clearly identifies system interface points where national standards and communications protocols can be used.
While an institutional layer is not actually part of the physical architecture, the physical architecture cannot be fully defined in a region without some decisions being made regarding the jurisdictional structure and working relationships that will provide a framework for ITS planning and implementation. These institutional decisions should lead to a depiction of who should communicate with whom, and what information should be communicated in the transportation and communications layers, and will vary based on the unique needs and characteristics of a region.
Figure 2 from the ITS Architecture for Canada, shows the 26 transportation subsystems (white rectangles) and the 4 general communication links (ovals) used to exchange information between subsystems. This figure represents the highest level view of the transportation and communications layers of the physical architecture. The subsystems roughly correspond to physical elements of transportation management systems and are grouped into 4 classes (larger rectangles): Centres, Field, Vehicles and Travellers.
Figure 2. ITS Architecture for Canada Subsystems and Communications
Basic traffic signal control systems are represented by functions within 2 of the 26 subsystems: the Traffic Management subsystem and the Roadway subsystem. This is illustrated in figure 3, which depicts traffic signal control related elements as an overlay to the diagram just presented.
Figure 3. Basic Traffic Signal Control System Architecture Depiction
These two subsystems, together with the necessary communications (shown by the blue, curved lines) to exchange control and surveillance information, provide the following capabilities typically associated with traffic signal control systems:
The Traffic Management subsystem functions are implemented with central equipment typically found in traffic management centres; e.g., computers, traffic control consoles, and video switching and display systems.
The Roadway subsystem functions are implemented with equipment typically found in the field; e.g. traffic signal controllers and traffic lights, vehicle detectors (e.g., inductive loop, radar, video), and video cameras.
Fixed Point - Fixed Point Communications includes the equipment necessary for the various subsystems of the architecture, including the Traffic Management and Roadway subsystems, to exchange data to perform their transportation functions. These communications services may be provided by agency-owned communications plants (e.g. twisted pair, coaxial, fiber, or spread-spectrum radio), or may be leased from a communications service provider.
The Traffic Management and Roadway subsystems also provide other functions not typically associated with traffic signal control systems. These include the following transportation system functions:
An important concept to understand from the physical architecture is that of support for combining subsystems together (or functionality from multiple subsystems) in an actual implementation. This is particularly important for the "CENTRE" subsystems, which should not be immediately thought of as separate buildings. In simplest terms, the centre subsystems are not " brick and mortar ". Each subsystem is a cohesive set of functional definitions with required interfaces to other subsystems; subsystems are functionally defined, not physically defined. A regional implementation may include a single physical centre that collocates and integrates the capabilities from several of the centre subsystems. For instance, a single Transportation Management Centre may include the capabilities of a Traffic Management Subsystem, Transit Management Subsystem, Emergency Management Subsystem, and Information Service Provider. Conversely, a single subsystem may be replicated in many different physical centres in a complex metropolitan area system. For instance, the traffic management subsystem may be implemented in a traffic management centre for freeway control in addition to several distinct city traffic management centres that cooperatively control the arterials and surface streets.
The logical and physical architectures contain all of the essential architecture elements needed to provide the user services (and their more detailed requirements). Although the formal definition of the ITS Architecture for Canada stops there, other categorizations of the architecture elements were made for the purposes of evaluation and to better understand the deployment implications.
The term "equipment package" is used in the ITS Architecture for Canada to group like functions (PSpecs) of a particular subsystem together into an "implementable" package of hardware and software capabilities. Documented as part of the Physical Architecture, the grouping of functions also took into account the user services and the need to accommodate various levels of functionality within them. The equipment packages are associated closely with Service Packages (which will be discussed next). The specific set of equipment packages defined is merely illustrative and does not represent the only way to combine the functions within a subsystem. The ITS Architecture for Canada has defined 239 equipment packages in total.
Table 3 illustrates an example of an equipment package that is relevant to traffic signal control, e.g., "TMC Signal Control", which is comprised of 5 process specifications: Process Traffic Data, Provide Traffic Operations Personnel Traffic Data Interface, Select Strategy, Determine Indicator State for Road Management, and Output Control Data for Roads
Table 3. Equipment Package Example
|TMC Signal Control Equipment Package (part of the Traffic Management Subsystem):|
This Equipment package provides the capability for traffic managers to monitor and manage the traffic flow at signalized intersections. This capability includes analyzing and reducing the collected data from traffic surveillance equipment and developing and implementing control plans for signalized intersections. Control plans may be developed and implemented that coordinate signals at many intersections under the domain of a single traffic management subsystem and are responsive to traffic conditions and adapt to support incidents, preemption and priority requests, pedestrian crossing calls, etc.
|This equipment package consists of the following PSpecs:|
|126.96.36.199||Process Traffic Data|
|188.8.131.52||Provide Traffic Operations Personnel Traffic Data Interface|
|184.108.40.206||Determine Indicator State for Road Management|
|220.127.116.11||Output Control Data for Roads|
Some of the user services are too broad in scope to be convenient in planning actual deployments. Additionally, they often don’t translate easily into existing institutional environments and don’t distinguish between major levels of functionality. In order to address these concerns (in the context of providing a more meaningful evaluation), a finer grained set of deployment-oriented ITS service building blocks were defined from the original user services. These are called "Service Packages" in the documentation.
Service Packages are defined by sets of equipment packages required to work together (typically across different subsystems) to deliver a given transportation service and the major architecture flows between them and other important external systems. In other words, they identify the pieces of the ITS Architecture for Canada required to implement a service. As such, they are directly grounded in the definition of the Architecture. Most Service Packages are made up of equipment packages in two or more subsystems. Service Packages are designed to address specific transportation problems and needs and can be related back to the user services and their more detailed requirements.
For example, the functionality of the broad user service named "traffic control" was broken up into several Service Packages to allow for explicit consideration of:
In addition, a "Multi-modal Coordination" Service Package was defined that is comprised of functionality for transit vehicle priority treatment at traffic signals. The "Emergency Routing" Service Package includes the functionality for emergency vehicle preemption at traffic signals.
Table 4 provides an example of a Service Package related to traffic signal control, Figure 4 contains the Service Package diagram, and Figure 5 explains the basic elements of the Service Package diagrams.
Table 4. Service Package Example
|Surface Street Control (ATMS03)|
This service package provides the central control and monitoring equipment, communication links, and the signal control equipment that support local surface street control and/or arterial traffic management. A range of traffic signal control systems are represented by this service package ranging from fixed-schedule control systems to fully traffic responsive systems that dynamically adjust control plans and strategies based on current traffic conditions and priority requests. This service package is generally an intra-jurisdictional package that does not rely on real-time communications between separate control systems to achieve area-wide traffic signal coordination. Systems that achieve coordination across jurisdictions by using a common time base or other strategies that do not require real time coordination would be represented by this package. This service package is consistent with typical urban traffic signal control systems.
Figure 4. Surface Street Control Service Package Diagram
Figure 5. Service Package Elements
The ITS Architecture for Canada development effort identified a total of 101 Service Packages that reflect the current definition of ITS and the evolving technology market. Table 5 contains a complete listing of these, grouped according to their respective major application areas. As with equipment packages, the specific set of Service Packages defined is merely illustrative and does not represent the only way to combine the functions and equipment in order to provide ITS services.
A given Service Package may provide only part of the functionality of a user service (supporting multiple service levels), but often serves as a building block by allowing more advanced packages to use its components. Service Packages also allow early deployments to be separated from higher risk services and can specifically address varied regional needs. Because they were evaluated during the development process, supporting benefits and costs analyses were conducted for the Service Packages, which can also be accessed as a resource.
Service Packages are not intended to be tied to specific technologies, but of course depend on the current technology and product market in order to actually be implemented. As transportation needs evolve, technology advances, and new devices are developed, Service Packages may change and new Service Packages may be defined.
In short, Service Packages provide another method for entering into the ITS Architecture for Canada and can be used as an alternative starting point for defining project functional requirements and system specifications. The important point to remember is that they provide a set of manageable, service-oriented views which allow the user to jump right into the physical architecture definition.
Table 5. ITS Service Packages
|Traffic Management||Network Surveillance|
Traffic Probe Surveillance
Surface Street Control
HOV Lane Management
Traffic Information Dissemination
Regional Traffic Management
Traffic Incident Management System
Traffic Forecast and Demand Management
Electronic Toll Collection
Emissions Monitoring and Management
Roadside Lighting System Control
Standard Railroad Grade Crossing
Advanced Railroad Grade Crossing
Multimodal Operations Coordination
Parking Facility Management
Regional Parking Management
Reversible Lane Management
Variable Speed Limit and Enforcement
Roadway Closure Management
Dynamic Roadway Warning
Standard Mixed Use Warning Systems
Advanced Mixed Use Warning Systems
|Public Transportation||Transit Vehicle Tracking|
Transit Fixed-Route Operations
Demand Response Transit Operations
Transit Fare Collection Management
Transit Fleet Management
Transit Traveller Information
Transit Signal Priority
Transit Passenger Counting
Multi-Modal Connection Protection
|Traveller Information||Broadcast Traveller Information|
Interactive Traveller Information
Autonomous Route Guidance
Dynamic Route Guidance
ISP Based Trip Planning and Route Guidance
Transportation Operations Data Sharing
Traveller Services Payment and Reservation
In Vehicle Signing
VII Traveller Information
|Advanced Safety Systems||Vehicle Safety Monitoring|
Driver Safety Monitoring
Longitudinal Safety Warning
Lateral Safety Warning
Intersection Safety Warning
Pre-Collision Restraint Deployment
Driver Visibility Improvement
Advanced Vehicle Longitudinal Control
Advanced Vehicle Lateral Control
Intersection Collision Avoidance
Automated Highway System
Cooperative Vehicle Safety Systems
|Commercial Vehicle Operations||Fleet Administration|
CV Administrative Processes
International Border Electronic Clearance
Roadside CVO Safety
On-Board CVO and Freight Safety and Security
CVO Fleet Maintenance
Hazardous Material Planning and Incident Response
Roadside Hazardous Material Security Detection and Mitigation
CV Driver Security Authentication
Freight Assignment Tracking
Freight Terminal Management
International Border Registration
International Border Pre-Processing
International Border Inspection
|Emergency Management||Emergency Call-Taking and Dispatch|
Personal Security and MAYDAY Support
Roadway Service Patrols
Transportation Infrastructure Protection
Early Warning System
Disaster Response and Recovery
Evacuation and Reentry Management
Disaster Traveller Information
|Archived Data Management||ITS Data Mart|
ITS Data Warehouse
ITS Virtual Data Warehouse
|Maintenance & Construction Operations||Maintenance & Construction Vehicle and Equipment Tracking|
Maintenance & Construction Vehicle Maintenance
Road Weather Data Collection
Weather Information Processing and Distribution
Roadway Automated Treatment
Roadway Maintenance and Construction
Work Zone Management
Work Zone Safety Monitoring
Maintenance & Construction Activity Coordination
Environmental Probe Surveillance
The ITS Architecture for Canada provides a common structure for the design of ITS. It defines the functions that must be performed by components or subsystems, where these functions reside (e.g., field, traffic management centre, or in-vehicle), the interfaces and information flows between subsystems, and the communications requirements for the information flows in order to address the underlying user service requirements. Since the ITS Architecture for Canada is also the foundation for much of the ongoing ITS standards work, consideration of the interface and information exchange requirements established by the Architecture today will likely facilitate or ease the transition to incorporating standards-compliant interfaces in the future (when approved standards are available).