Key Concepts of the ITS Architecture for Canada

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 and User Service Requirements
• Logical Architecture
• Physical Architecture
• Equipment Packages
• Service Packages

User Services and User Service Requirements

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
Traveller Information	Pre-Trip Travel Information En-Route Driver Information Route Guidance and Navigation Ride Matching And Reservation Traveller Services Information
Traffic Management	Traffic Control Incident Management Travel Demand Management Emissions Testing And Mitigation Highway-Rail Intersection 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 Freight Mobility 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 Safety Readiness 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.

1.6.1.1Traffic Flow Optimization shall employ control strategies that seek to maximize traffic-movement efficiency.

1.6.1.2Traffic Flow Optimization shall include a wide area optimization capability, to include several jurisdictions.

1.6.1.2.1 Wide area optimization shall integrate the control of network signal systems with the control of freeways.

1.6.1.2.2 Wide area optimization shall include features that provide preferential treatment for transit vehicles.

1.6.2 TC shall include a Traffic Surveillance function.

Logical Architecture

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.

Physical Architecture

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.

Transportation Layer

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:

• Field devices for traffic surveillance and motorist information dissemination
• Traffic signal and ramp metering controllers
• Transportation management centres
• Emergency management centres

Communications Layer

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.

Institutional Implications

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:

• Area-wide signal coordination
• Arterial network traffic conditions
• A range of adaptive control strategies
• Integration with freeway management, incident and emergency management, transit management, etc.

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:

Freeway Management Systems

• Monitor Freeway Conditions
• Identify Flow Impediments
• Ramp Metering/Lane Controls
• Highway Advisory Radios/Dynamic Message Signs

Incident Management Systems

• Incident Detection/Verification
• Incident Response/Clearance

Railroad Grade Crossing Systems

• Improve and automate Highway-Railroad Intersection warnings and Traffic Signal Control
• Provide advanced warning of closures
• Coordinate traffic signal control with rail movements

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.

Equipment Packages

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:
1.1.2.2	Process Traffic Data
1.1.4.2	Provide Traffic Operations Personnel Traffic Data Interface
1.2.1	Select Strategy
1.2.2.2	Determine Indicator State for Road Management
1.2.4.1	Output Control Data for Roads

Service Packages

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:

• basic functions (such as surveillance, which is represented by the "network surveillance" and "probe surveillance" Service Packages),
• institutional settings (by separating control functions typically performed by different agencies into the "surface street control" and "freeway control" service packages), and
• functional levels of service (by including a "regional traffic management" service package that provides for coordination of control strategies across jurisdictions).

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 Freeway 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 Drawbridge Management Roadway Closure Management Dynamic Roadway Warning Signal Enforcement 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 Security Transit Fleet Management Multi-modal Coordination 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 Dynamic Ridesharing 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 Freight Administration Electronic Clearance CV Administrative Processes International Border Electronic Clearance Weigh-In-Motion 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 Emergency Routing Personal Security and MAYDAY Support Roadway Service Patrols Transportation Infrastructure Protection Wide-Area Alert 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 Winter Maintenance Roadway Maintenance and Construction Work Zone Management Work Zone Safety Monitoring Maintenance & Construction Activity Coordination Environmental Probe Surveillance Infrastructure Monitoring Roadway Micro-Prediction

Summary

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).