A framework within which a system can be built. Requirements dictate what functionality the architecture must satisfy. An architecture functionally defines what the pieces of the system are and the information that is exchanged between them. An architecture is functionally oriented and not technology-specific which allows the architecture to remain effective over time. It defines "what must be done," not "how it will be done."
Information that is exchanged between subsystems and terminators in the physical architecture view of the ITS Architecture for Canada. Architecture flows are the primary tool that is used to define the Regional ITS Architecture interfaces. These architecture flows and their communication requirements define the interfaces which form the basis for much of the ongoing standards work in the U.S. National ITS program. The terms "information flow" and "architecture flow" are used interchangeably.
Communications paths that carry information between subsystems and terminators in the physical architecture view of the ITS Architecture for Canada. Several different types of interconnects are defined in the ITS Architecture for Canada to reflect the range of interface requirements in ITS. The majority of the interconnects are various types of communications links that are defined in the communications layer. Four different types of communications links are defined: Fixed Point - Fixed Point Communications, Wide Area Wireless (Mobile) Communications, Field - Vehicle Communications, and Vehicle - Vehicle Communications. In addition to these types, several specialized interconnects are also defined to reflect other interface requirements. These include human interface (e.g., what the system user sees and hears) and physical/environmental (e.g., what the ITS sensors sense).
Subsystems that provide management, administrative, and support functions for the transportation system. The centre subsystems each communicate with other centers to enable coordination between modes and across jurisdictions. Some examples of centre subsystems are Traffic Management, Transit Management, Commercial Vehicle Administration, Archived Data Management, Emissions Management, Toll Administration, Emergency Management, Information Service Provider, and Fleet and Freight Management. One of four general subsystem classes defined in the ITS Architecture for Canada.
A network for sharing and exchanging surface weather data and relevant surface transportation conditions.
One of three layers (along with the transportation and institutional layers) defined by the ITS Architecture for Canada. The communications layer includes all of the communications equipment (e.g., wireline and wireless transmitters and receivers) and the information management and transport capabilities necessary to transfer information among entities in the transportation layer. The application data content and the transportation application requirements are generally transparent to the communications layer. The communication layer's view of ITS is that of many distributed users, some of them mobile, which require communication services.
Every data flow included in the logical architecture view of the ITS Architecture for Canada is defined in a data dictionary entry. Each data dictionary entry contains a textual description of the data flow and identifies any lower level data elements that make up the data flow.
Data flows represent a pipeline along which information of known composition is passed. Data flows are modeled in the logical architecture view of the ITS Architecture for Canada. Data flows represent data flowing between processes or between a process and a terminator. A data flow is shown as an arrow on a data flow diagram and is defined in a data dictionary entry in the logical architecture. Data flows are aggregated together to form high-level architecture flows in the physical architecture view of the ITS Architecture for Canada.
The diagrams in the logical architecture view of the ITS Architecture for Canada that show the functions that are required for ITS and the information that moves between these functions. Only four different symbols are used on the diagrams. Circles represent theprocesses or functions that do the work. Arrows represent the data flows that show how data moves through the system. Parallel lines represent data stores that represent "data at rest" in the system. Finally, rectangles represent the terminators that define the architecture boundary. A hierarchy of these diagrams depict the ITS functionality and data flow requirements in successively greater detail until "primitive" processes are defined.
A data store represents a reservoir in which data can be held for an indefinite period. Data stores are shown on the data flow diagrams where data repositories are required to support data aggregation or archival services.
Equipment packages are the building blocks of the physical architecture subsystems. Equipment Packages group similar processes of a particular subsystem together into an “implementable” package. The grouping also takes into account the user services and the need to accommodate various levels of functionality. The equipment packages were used as a basis for estimating deployment costs (as part of the evaluation that was performed). Since equipment packages are both the most detailed elements of the physical architecture view of the ITS Architecture for Canada and tied to specific service packages, they provide the common link between the interface-oriented architecture definition and the deployment-oriented service packages.
A wireless communications channel used for close-proximity communications between vehicles and the immediate infrastructure. It supports location-specific communications for ITS capabilities such as toll collection, transit vehicle management, driver information, and automated commercial vehicle operations. One of the types of architecture interconnects defined in the ITS Architecture for Canada.
Intelligent infrastructure distributed along the transportation network which perform surveillance, information provision, and plan execution control functions and whose operation is governed by centre subsystems. Field subsystems also directly interface to vehicle subsystems. One of the four general subsystem classes defined in the ITS Architecture for Canada.
A communication link serving stationary entities. It may be implemented using a variety of public or private communication networks and technologies. It can include, but is not limited to, twisted pair, coaxial cable, fiber optic, microwave relay networks, spread spectrum, etc. In Fixed Point - Fixed Point (FP2FP) communication the important issue is that it serves stationary entities. Both dedicated and shared communication resources may be used. One of the types of architecture interconnects defined in the ITS Architecture for Canada.
A statement that specifies WHAT a system must do. The statement should use formal “shall” language and specify a function in terms that the stakeholders, particularly the system implementers, will understand. In the ITS Architecture for Canada, Functional Requirements have been defined for each Equipment Package that focus on the high-level requirements that support regional integration.
Information that is exchanged between subsystems and terminators in the physical architecture view of the ITS Architecture for Canada. These information flows are normally identical to the architecture flows in the ITS Architecture for Canada. The terms "information flow" and "architecture flow" are used interchangeably.
An integral component of the ITS Architecture for Canada analysis, the institutional layer represents the existing and emerging institutional constraints and arrangements that are the context for all ITS deployments. The transportation layer and communications layer together provide the technical framework within which interoperable systems may be implemented. The institutional layer introduces the policies, funding incentives, working arrangements, and jurisdictional structure that support the technical layers of the architecture. This institutional layer provides the basis for understanding who the stakeholders will be and the roles these implementers could take in implementing architecture-based ITS systems.
The system defined as the electronics, communications or information processing used singly or integrated to improve the efficiency or safety of surface transportation.
Defines an architecture of interrelated systems that work together to deliver transportation services. An ITS architecture defines how systems functionally operate and the interconnection of information exchanges that must take place between these systems to accomplish transportation services.
A common, established framework for developing integrated transportation systems. The ITS Architecture for Canada is comprised of the logical architecture and the physical architecture, which satisfy a defined set of user service requirements. The ITS Architecture for Canada is maintained by Transport Canada.
Areas of ITS which can be used to enhance surface transportation security. The ITS Architecture for Canada provides entities (subsystems and terminators), functions, and interfaces that cover aspects of the eight ITS security areas.
Existing transportation systems, communications systems, and institutional processes.
The logical architecture view of the ITS Architecture for Canada defines what has to be done to support the ITS user services. It defines the processes that perform ITS functions and the information or data flows that are shared between these processes. The logical architecture was developed using Structured Analysis techniques and consists of data flow diagrams, process specifications, and data dictionary entries. The logical architecture has also been called an "Essential Model" because it is not technology specific, nor does it dictate a particular implementation. This implementation independence makes the logical architecture accommodating to innovation, scalable from small scale implementations to large regional systems, and supportive of widely varied system designs.
The Logical Architecture document contains three volumes: Description (Volume 1), Process Specifications (Volume 2), and Data Dictionary (Volume 3). These documents present a functional view of the ITS user services, contain diagrams that show processes and data flows among them, and define data elements, respectively.
The physical architecture is the part of the ITS Architecture for Canada that provides agencies with a physical representation (though not a detailed design) of the important ITS interfaces and major system components. It provides a high-level structure around the processes and data flows defined in the logical architecture. The principal elements in the physical architecture are the subsystems and architecture flows that connect these subsystems and terminators into an overall structure. The physical architecture takes the processes identified in the logical architecture and assigns them to subsystems. In addition, the data flows (also from the logical architecture) are grouped together into architecture 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.
The Physical Architecture document describes the transportation and communications layers resulting from the partitioning of the processes within the logical architecture, presents architecture flow diagrams that show data passing among physical subsystems, and provides characteristics and constraints on the data flows.
Entities are the persons, places, and things that make up an intelligent transportation system. In the physical architecture, an entity represents a ITS Architecture for Canada subsystem or terminator.
A function or activity identified in the logical architecture view of the ITS Architecture for Canada that is required to support the ITS user service requirements. The logical architecture presents processes in a top-down fashion beginning with general processes (e.g., "Manage Traffic") that are then decomposed into more detailed processes (e.g., "Provide Traffic Surveillance", "Monitor HOV Lane Use"). General processes are defined in terms of more detailed processes using data flow diagrams. The most detailed processes (sometimes called primitives) are defined in Process Specifications (PSpecs).
The textual definition of the most detailed processes identified in the logical architecture view of the ITS Architecture for Canada. The process specification includes an overview, a set of functional requirements, and a complete set of inputs and outputs.
A framework that identifies the institutional agreement and technical integration necessary to interface a major ITS project with other ITS projects and systems.
The geographical area that identifies the boundaries of the Regional ITS Architecture and is defined by and based on the needs of the participating agencies and other stakeholders. In metropolitan areas, a region should be no less than the boundaries of the metropolitan planning area.
A specific, tailored framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects in a particular region. It functionally defines what pieces of the system are linked to others and what information is exchanged between them.
The service packages provide an accessible, service-oriented perspective to the ITS Architecture for Canada. They are tailored to fit, separately or in combination, real world transportation problems and needs. Service packages collect together one or more equipment packages that 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.
The Service Packages document provides a comprehensive review of each of the service packages describing how service packages can be used to plan and implement integrated transportation systems customized to local needs. This document includes a number of examples that illustrate ways service packages can be applied in Regional ITS Architecture and Project ITS Architecture development activities. Through these definitions, analyses, and examples, the Service Packages document provides a comprehensive review of the service packages and how they can be used to plan and implement integrated transportation systems customized to local needs.
A widely used term that notates a public agency, private organization or the travelling public with a vested interest, or a "stake" in one or more transportation elements within a Regional ITS Architecture.
Documented technical specifications sponsored by a Standards Development Organization (SDO) to be used consistently as rules, guidelines, or definitions of characteristics for the interchange of data. A broad array of ITS standards is currently under development that will specifically define the interfaces identified in the ITS Architecture for Canada.
The principle structural element of the physical architecture view of the ITS Architecture for Canada. Subsystems are individual pieces of the Intelligent Transportation System defined by the ITS Architecture for Canada. Subsystems are grouped into four classes: Centres, Field, Vehicles, and Travellers. Example subsystems are the Traffic Management Subsystem, the Vehicle Subsystem, and the Roadway Subsystem. These correspond to the physical world: respectively traffic operations centers, automobiles, and roadside signal controllers. Due to this close correspondence between the physical world and the subsystems, the subsystem interfaces are prime candidates for standardization.
A diagram which depicts all subsystems in the ITS Architecture for Canada and the basic communication channels between these subsystems. The subsystem diagram is a top-level architecture interconnect diagram. Variations of the subsystem diagram are sometimes used to depict Regional ITS Architectures at a high level.
A collection of hardware, software, data, processes, and people that work together to achieve a common goal. Note the scope of a "system" depends on one's viewpoint. To a sign manufacturer, a dynamic message sign is a "system". To a provincial ministry, the same sign is only a component of a larger Freeway Management "System". In a Regional ITS Architecture, a Freeway Management System is a part of the overall surface transportation "system" for the region.
Terminators define the boundary of an architecture. The ITS Architecture for Canadaterminators represent the people, systems, and general environment that interface to ITS. The interfaces between terminators and the subsystems and processes within the ITS Architecture for Canada are defined, but no functional requirements are allocated to terminators. The logical architecture and physical architecture views of the ITS Architecture for Canada both have exactly the same set of terminators. The only difference is that logical architecture processes communicate with terminators using data flows, while physical architecture subsystems use architecture flows.
A cornerstone of the ITS Architecture for Canada is the traceability between its components. Microsoft Access databases are used to maintain these connections. The hyperlinked ITS Architecture for Canada relies on this traceability to build the links that allows traversal between user services, logical architecture, and physical architecture.
One of three layers (along with the communications layer and the institutional layer) defined by the physical architecture. The transportation layer shows the relationships among the transportation related elements. It is composed of subsystems for travellers, vehicles, transportation management centres, and field devices, as well as external system interfaces (terminators) at the boundaries.
Equipment used by travellers to access ITS services pre-trip and en-route. This includes services that are owned and operated by the traveller as well as services that are owned by transportation and information providers. One of four general subsystem classes defined in the ITS Architecture for Canada.
An automated software tool used to input and manage system inventory, service packages, architecture flows and interconnects with regard to a Regional ITS Architecture and/or multiple Project ITS Architectures.
A specific functional requirement statement of what must be done to support the ITS user services. The user service requirements were developed specifically to serve as a requirements baseline to drive ITS Architecture for Canada development. The user service requirements are not to be construed as mandates to system/architecture implementers. As a requirements baseline, the user service requirements include little narrative or background material.
User services document what ITS should do from the user's perspective. A broad range of users are considered, including the travelling public as well as many different types of system operators. User services, including the corresponding user service requirements, form the basis for the ITS Architecture for Canada development effort. The concept of user services allows system or project definition to begin by establishing the high level services that will be provided to address identified problems and needs. New or updated user services have been and will continue to be satisfied by the ITS Architecture for Canada over time.
A logical grouping of user services that provides a convenient way to discuss the range of requirements in a broad stakeholder area. User services are grouped into nine bundles: Traveller Information, Traffic Management, Public Transportation Management, Electronic Payment, Commercial Vehicle Operations, Emergency Management, Advanced Vehicle Safety Systems, Information Management, and Maintenance and Construction Operations.
Dedicated wireless system handling high data rate, low probability of error, line of sight communications between vehicles. Advanced vehicle services may use this link in the future to support advanced collision avoidance implementations, road condition information sharing, and active coordination to advanced control systems. One of the types of architecture interconnects defined in the ITS Architecture for Canada.
Covers 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 and Maintenance and Construction Vehicles) add ITS capabilities unique to these special vehicle types. One of four general subsystem classes defined in the ITS Architecture for Canada.
A communications link that provides communications via a wireless device between a user and an infrastructure-based system. Both broadcast (one-way) and interactive (two-way) communications services are grouped into wide-area wireless communications in the ITS Architecture for Canada. These links support a range of services in the ITS Architecture for Canada including real-time traveller information and various forms of fleet communications. One of the types of architecture interconnects defined in the ITS Architecture for Canada.