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.  Clearly, a different set could have been defined.  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 National ITS Architecture over time.

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

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.

For example, as shown in Figure 1, at the highest level of the National ITS Architecture, the manage traffic process (which includes traffic signal control functions) interacts with eight other processes.

Figure 1. The Nine Major Processes within the Logical Architecture

Figure 2 illustrates how the manage traffic process is then further broken down into six sub-processes; how one of those processes, Provide Traffic Surveillance, is broken down into seven sub-processes; 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 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

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
• Emergency 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:

• 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 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, Transit 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.  The equipment packages are associated closely with market packages (which will be discussed next) and were used as a basis for estimating deployment costs (as part of the evaluation that was performed).  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 National ITS Architecture has defined 208 equipment packages in total.

Table 4 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 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 in two or more subsystems.  Market 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 market packages to allow for explicit consideration of:

• basic functions (such as surveillance, which is represented by the "network surveillance" and "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 another method for entering into the National ITS Architecture 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 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 (when approved standards are available).