Key Concepts of the
National ITS Architecture

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 33 user services which formed the basis for the National ITS Architecture development effort, grouped into eight bundles for convenience.  These user services were jointly defined by a collaborative process involving USDOT and ITS America, with significant stakeholder input. 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. Over time new services have been added to the National ITS Architecture and some of the existing ones have been updated to address additional user needs.

Table 1. User Services for the National ITS Architecture

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, which formed the fundamental requirements for the National ITS Architecture development effort.  For example, the traffic control user service is actually defined by over 40 "functions"). The user service requirements can be found under the User Services Tab on the hyperlinked version of the architecture, or in the Logical Architecture document. At one time these user service requirements were a useful departure point for the development of project functional requirements and system specifications, but over time this role has diminished with the identification of functional requirements assigned to each Equipment Package (see later discussion). Their primary role today is as the defining requirements for the National ITS Architecture itself.

Table 2 provides an illustration of user service requirements using an excerpt from the traffic control user service.

Table 2. User Service Requirements Example

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 National ITS Architecture 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.  Figures 1 and 2 depict simplified data flow diagrams from the National ITS Architecture documents.  Note that each bubble in the logical architecture is a process that describes some logical function to be performed. As shown in figure 1, there are nine high level processes that make up the highest level of the Logical Architecture.

Figure 1 does not show all the connections between processes, but focuses on the Manage Traffic process (which includes traffic signal control functions), identifying how it interacts with the eight other high level processes that form the Logical Architecture.

Figure 1. Interaction of Manage Traffic with other High Level Processes

Figure 2 illustrates how the manage traffic process is then further broken down into six sub-processes (at the right portion of the figure); how one of those processes, Provide Traffic Surveillance, is broken down into seven sub-processes (the middle part of the figure); and so on. Each of these processes are then broken down even further so that a complete functional view of a system emerges. 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. Example overview descriptions of some of the process specifications relevant to traffic signal control systems are given in Table 3.

Figure 2. Example of Logical Architecture Functional Decomposition

Table 3. Process Specifications Example

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 National ITS Architecture).  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 3 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 3. Representative Logical and Physical Architecture

In the National ITS Architecture, the physical architecture is described by two layers: the transportation layer and the communications layer.  Each of these is briefly described below.

Transportation Layer

From a traffic management viewpoint, the transportation layer of the physical architecture shows the relationships among the transportation-management-related elements.  It is composed of subsystems for travelers, vehicles, transportation management centers, 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 centers

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, traveler 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 4 from the National ITS Architecture, shows the 22 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): Centers, Field, Vehicles and Travelers.

Figure 4. National ITS Architecture Subsystems and Communications

Basic traffic signal control systems are represented by functions within 2 of the 22 subsystems: the Traffic Management subsystem and the Roadway subsystem.  This is illustrated in figure 5, which depicts traffic signal control related elements as an overlay to the diagram just presented.

Figure 5. 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:

• Surveillance of an arterial system to collect network traffic conditions
• Control of intersections using a variety of strategies
• Central monitoring of locally controlled signals
• Closed loop systems
• Adaptive control strategies
• Area-wide signal coordination

The Traffic Management subsystem functions are implemented with central equipment typically found in traffic management centers; 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 to 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 "CENTER" subsystems, which should not be immediately thought of as separate buildings.  In simplest terms, the center 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 center that collocates and integrates the capabilities from several of the center subsystems.  For instance, a single Transportation Management Center may include the capabilities of a Traffic Management Subsystem, Emergency Management Subsystem, and Information Service Provider.  Conversely, a single subsystem may be replicated in many different physical centers in a complex metropolitan area system.  For instance, the traffic management subsystem may be implemented in a traffic management center for freeway control in addition to several distinct city traffic management centers that cooperatively control the arterials and surface streets.  Figure 6 provides an indication of the range of ways that center subsystems may be implemented in physical centers.

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 National ITS Architecture 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" was used in the National ITS Architecture development effort 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. Functional requirements have been defined for each equipment package that define more precisely what each equipment package does. These functional requirements provide a starting point for ITS project specification.

Table 4 illustrates an example of an equipment package that is relevant to traffic signal control, e.g., "TMC Signal Control". The table includes the functional requirements and process specifications associated with this equipment package.

Table 4. Equipment Package Example

Market 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 "market packages" in the documentation.

Market 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 National ITS Architecture required to implement a service.  As such, they are directly grounded in the definition of the Architecture.  Most market packages are made up of equipment packages from two or more subsystems.  Market packages are designed to address specific transportation problems and needs and can be related back to the user services.

For example, the functionality of the broad user service named "traffic control" was broken up into several market packages to allow for explicit consideration of:

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

In addition, a "Multi-modal Coordination" market package was defined that is comprised of functionality for transit vehicle priority treatment at traffic signals.  The "Emergency Routing" market package includes the functionality for emergency vehicle preemption at traffic signals.

Table 5 provides an example of a market package related to traffic signal control, Figure 7 contains the market package diagram, and Figure 8 explains the basic elements of the market package diagrams.

Table 5. Market Package Example

Figure 7. Surface Street Control Market Package Diagram

Figure 8. Market Package Elements

The National ITS Architecture development effort identified a total of 91 market packages that reflect the current definition of ITS and the evolving technology market.  Table 6 contains a complete listing of these, grouped according to their respective major application areas.  As with equipment packages, the specific set of market 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 market 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.  Market 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 market packages, which can also be accessed as a resource.

Market 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, market packages may change and new market packages may be defined.

In short, market packages provide a key method for entering into the National ITS Architecture and can be used as a starting point for defining project systems and interfaces.  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 6. ITS Market Packages

Summary

The National ITS Architecture 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 center, 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 National ITS Architecture 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.