Summary

Relationship to Other Components

As shown in the figure below, each interface is connected to the ITS elements, and services, and standards. Inventory elements are needed to create an interface and are fundamental to providing Services. In addition, standards are defined for each interface and the requirements associated with inventory imply interfaces to the inventory elements. Any updates to these components will affect the connections between elements and the information exchanges between them. The relationship between interfaces and requirements is that some of the requirements assigned to inventory elements relate to the interfaces that exist for the element.

Regional ITS Architecture Components – Interfaces

Approach

Whether you are updating an existing architecture or starting a new architecture the definition of interfaces is an important and detailed part of the process. Stakeholder input is key to ensure agreement especially when interfaces extend across agency boundaries.

The next sections describe the different activities involved in each approach:

-         Updating Interfaces

-         Developing Interfaces

Updating Interfaces

The ITS inventory, services (and needs), and operational concept, lay the groundwork for evaluation of which ITS elements should connect to each other to exchange information. In case of a regional ITS architecture that is being updated, after the region's elements has been reviewed and updated, the current regional needs and services are understood, and an operational concept has been updated to reflect the current integration opportunities in the region in a broad sense, the interfaces will be reviewed and updated.

Developing interfaces can be done effectively with a two-step process of determining interconnects and then defining interfaces for the selected interconnects (which is described below in the Developing Interfaces section). In the case of updating an architecture, defining interconnects can be effective for new stakeholders with new elements, but in most cases the update can focus on updates to information flows in the architecture.

Update Information Flows

There are many ways to approach updating flows, but an effective  approach is to  start with evaluating the selected service packages to decide which stakeholders and ITS elements make up the revised or new service packages and then review the actual information that flows between the ITS elements in order to support the region's desired services. The approach continues with small revisions to the regional ITS architecture information flows based on corrections, revised stakeholder needs or updated status of information flows (e.g. from planned to existing). Other approaches to updating the information flows might focus on interfaces to a specific element (replicated over the key elements), or reviewing project interfaces to define a set of updates.

No matter what approach is used, the updated interfaces should include all connected source and destination ITS elements, a descriptive name for the information flowing between them, and a high-level status of that information flow (existing, planned, future, etc.). Adding a brief description or assumptions will be a good reference for future updates. All of these updates should be entered into RAD-IT.

Review Updates with Stakeholders

The next step is to gather stakeholder input on the updated information flows. This can be done by reviewing service package interfaces, element interfaces, or project interfaces, depending on the approach used to create the updates. This review can be facilitated by service package diagrams or other diagrammatic information. Web based information on the interfaces is another way to get stakeholder input.

When most of the stakeholders are present, concentrate primarily on evaluating the information flows between centers, as those are most likely to cross agency or public/private boundaries. Since an agency typically owns its own center and respective roadside or vehicle assets, the information flows on those internal agency interfaces really require only the evaluation of the affected stakeholder, and not the stakeholder group at large. Consider handling these non center-to-center information flows outside the general meeting.

Developing Interfaces

When developing interfaces for the first time, the approach also relies on initial definition of the inventory, needs and services, and operational concept, which lay the groundwork for evaluation of which ITS elements should connect to each other. Based on this information and any documentation that may describe existing communications in the region, a preliminary set of connections can be identified. A common approach to creating the set of interfaces is to first identify the interconnects between ITS elements and once those have been identified to look at the full set of information flows needed for the interconnects.

While this two-step "interconnects and then information flows" process for defining interfaces is not the only approach, experience shows that it is usually faster and easier to define interconnects first before specifying information exchanges. One reason to start with interconnects is that there are many more potential information exchanges than there are interconnects. The difference may be an order of magnitude – for example, 2000 potential interconnects vs. 20,000 potential information flows in a regional ITS architecture. Typically, only 20-30% (or approximately 400 to 600) of the valid interconnects will actually be selected for the region, effectively reducing the number of information flows that must be considered by 70-80%. Clearly, it is an iterative process, but use this Interconnect step to filter out all of the unwanted connections as early in the process as possible.

Identify Connections

Beginning with a preliminary set of interconnects, the stakeholders involved assess whether the interconnects would help support the needs and services of the region. Consider whether the connection exists today, or whether it is planned for the future. Often, a communications or network architecture is already in place between major "centers" in the region. Make sure the network can accommodate the connections identified in this step.

When most of the major stakeholders are present, concentrate primarily on evaluating the potential connections between centers, as those are most likely to cross agency or public/private boundaries. Since an agency typically owns its own center and respective roadside or vehicle assets, the connections to those items really require only the evaluation of the affected stakeholder, and not the stakeholder group at large. Consider handling these interconnections outside of general region-wide meetings.

Consider the existing connections between various stakeholder agencies, companies, or groups as the regional ITS architecture interconnects are defined. Many of these existing connections will be voice communications between people, either by telephone or face-to-face due to co-location of agencies such as public safety and traffic management agencies. The usual approach to architecture development is to focus on technical integration of elements, so they do not include voice interfaces that have no potential for conversion to, or augmentation with, data communications between two elements. In this case, only voice connections between people that may someday be supplanted or supported by data connections between elements are shown in the architecture as planned interconnects.

Define Information Flows

Now that the stakeholders have reached consensus on the interconnectivity of the ITS elements in the inventory, they must define the information that must be exchanged, given the services to be supported.

Each information flow is fully described by a source element (where the information originates), a destination element (where the information is sent) and a descriptive name for the information itself. The high-level status of the information flow (e.g., existing or planned) should also be documented.

Although each region can define their own criteria for flow status assignments, a reasonable approach is to consider whether the regional ITS architecture will have any impact on the information flows that are somewhere between "existing" and "planned" because implementation has started. For example, if the interface design is complete and ITS standards decisions have already been made, then the information flow may be considered to be "existing" with respect to the regional ITS architecture, even if the interface may not yet be operational. Following this criteria, information flows that can be influenced by the regional ITS architecture are designated as planned. Flows for interfaces that have already been designed are identified as existing. This approach has the added benefit of extending the "grace period" after the architecture is completed when the flow status will still be accurate when compared to criteria that only consider whether the interface is operational.

For flows that do not exist, RAD-IT provides the ability to define more than one "planned" status. For example, some regions have used "planned" for those flows expected to be implemented in the next 5 years and "future" for those flows planned for implementation later than that. The majority of regions do not go to this level of detail because it does it does increase the complexity of the update process as you have to make decisions about thousands of flows each update.

It is often helpful to review the operational concept and services established earlier, and envision the possible scenarios in which information is exchanged. This exercise often brings to light any gaps in understanding the operational concept since it reconciles the information sent by the source ITS element with the information expected by the destination ITS element.

When most of the stakeholders are present, concentrate primarily on evaluating the information flows between centers, as those are most likely to cross agency or public/private boundaries. Since an agency typically owns its own center and respective roadside or vehicle assets, the information flows on those internal agency interfaces really require only the evaluation of the affected stakeholder, and not the stakeholder group at large. Consider handling these non center-to-center information flows outside the general meeting.

Many regions use "hubs" to tie centers together that share information. For example, all public safety agencies in a region might be connected to an "incident information and mutual aid" network. All information exchanges between the public safety agency elements would go through this hub, facilitating region-wide sharing of information between agencies.

In some regions, the stakeholders think of the hub as a key component of the regional transportation system and feel it is important to include the hub in the regional ITS architecture. Explicitly including hubs in the regional ITS architecture has an ancillary benefit in that architectures that include hubs normally have fewer connections and information flows to define and maintain than equivalent architectures that depict point to point connections between all elements served by a hub. Other regions may decide that a "hub" is really a part of the communications infrastructure implementation and therefore should not be reflected in the interfaces defined in the architecture. Both views are valid. The region's stakeholders must decide which interpretation is best for their architecture.

There are a couple of factors to consider when deciding whether hubs should be included in the regional ITS architecture. One factor to consider is the functionality that the hub includes; a hub that implements ITS functions (e.g., data fusion) should probably be included in the regional ITS architecture while hubs that only implement communications functions (e.g., routing, protocol conversion, and data security) may be excluded at the stakeholders' discretion. This brings us to the most important factor in making this decision: Meeting stakeholders' expectations for the architecture by making sure that it reflects the stakeholder's "natural" view of the elements in the region. If the hub is largely transparent to the transportation professionals and other stakeholders, then it probably should be transparent in the architecture. If it is viewed as an integral part of the overall regional system, then it should be included as an important part of the architecture.

When hubs are included in a regional ITS architecture, a few key points should be documented. First, clearly define the element as a hub and include the functions that it performs in the definition. Second, document any specific interconnectivity constraints (e.g., a given public safety agency can NOT talk to another public safety agency using the hub in the above example) so that these selective connectivity requirements are not masked by the broad general connectivity that is suggested by a hub.

In some cases the information flows defined in ARC-IT don't cover the interfaces or information content that stakeholders view as important to their understanding of the architecture. In this case RAD-IT allows definition of user-defined information flows that can create interfaces or information not described in ARC-IT. One down side to creating user defined flows is that they will not have a set of standards associated with them like the ARC-IT information flows.

Build Consensus

Once the interfaces are defined in RAD-IT, they should be presented to the stakeholders for review and comment. Stakeholder reviews help build consensus around the interfaces that will be necessary for integration across the region. The information can be presented diagrammatically, in tables, or on a web version of the architecture.

When service package instances are used and ITS elements are associated with the market package instances, RAD-IT can be used to show the interconnects or information flows for one service package instance at a time, which greatly facilitates the "customization" of these service package instances. Service package instances can also be printed graphically one instance at a time, facilitating use of service package instances in regional ITS architecture development and maintenance.

RAD-IT

The key information about the interfaces can be found on the RAD-IT Interfaces tab, where the tool allows the user to define the interfaces between the transportation system elements in the region or project.

There are various views and customization options for this tab. The view below shows the information exchange tab, when the interfaces have been added for the region or project. For the information flows between elements, each information flow is described by a source element (where the information originates), a destination element (where the information is sent) and a descriptive name for the information itself. The high-level status of the information flow (e.g., existing, planned, future, etc.), and whether it is included in the architecture or not, are also shown in this view of the Interfaces tab.

RAD-IT also allows elements to be defined as communication elements (rather than transportation elements) and the communications used can be assigned to information flows as shown in the diagram below.

Interfaces Tab in RAD-IT

Examples

Interfaces are typically shown in several ways on architecture websites. The example below from the Ohio Kentucky Indiana (OKI) Regional ITS Architecture shows a typical Interfaces page which identifies for each element what other elements that it interfaces to. Each of these interfaces is an "Interconnect" in ARC-IT terminology.

Interfaces by Element Example

The websites also contain details about each interface, with an example shown below.

Interface Diagram Output Example