Summary

Relationship to Other Components

Service packages are made up of several other components of the regional ITS architecture. Every ITS service package selected for the region is associated with one or more inventory elements that support that service, functional objects, which relate to the functional requirements, for these elements, and information flows, which are defined for the interfaces. A set of user needs is defined for each service package in ARC-IT, which may be used to jumpstart the user needs that are included in the regional ITS architecture. The service packages in which a stakeholder participates support their Roles and Responsibilities. The Service Packages are also the way that Planning Objectives/ Strategies are addressed in a region.

Regional ITS Architecture Components - Services

Approach

Whether this is an update to an existing architecture or the development of a completely new architecture the approach for the architecture's services involves discussions with stakeholders regarding their current and future needs for transportation, identifying the appropriate ITS service that will meet those needs (sometimes expressed in the region's planning goals or objectives), and identifying the elements that will need to participate in each of those services.

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

-         Updating ITS Services

-         Defining ITS Services

Updating ITS Services

The approach to updating ITS services for a regional ITS architecture is, in essence, the approach taken to update the services packages as described in RAD-IT or in any diagrammatic material contained in the architecture. This is because, as noted above, service packages identify the pieces of the architecture that are required to implement a particular service. The key steps in almost any approach taken to updating service packages would include:

-         Identify the changes to service packages from the previous update

-         Put those changes into RAD-IT and update the outputs

-         Review the changes with the stakeholders for concurrence

Identify Service Package Changes

The first source of changes to Service Packages will likely come from the definition of Goals, Objectives, and Strategies for the region. These planning concepts are an expression of the stakeholders' needs regarding transportation in the region. A subset of these planning needs can be addressed by ITS services.

Although RAD-IT (formerly Turbo Architecture) has supported making the connection between planning concepts and ITS services for over 5 years, it is only in the past couple years that regions have started defining this connection within the regional ITS architecture. If the previous version of the architecture contains this mapping, then the approach to updating this component is to review the current regional set of planning concepts (e.g. goals, objectives, and strategies) to identify service packages that can support them. Identify any gaps between the revised planning concepts and the set of service packages from the previous version. These gaps should be considered for each stakeholder. For example, a previous version of an architecture might have a service package implemented by a single stakeholder in the region, but this remains a potential "gap" for other stakeholders in the region.

Long range transportation plans typically discuss economic and social trends and how the infrastructure should be built to meet the region's needs. Many of these long-term policies and goals are directly related to the needs and services that guide a regional ITS architecture. For example, if major new facilities are planned for the region, then it is appropriate to plan to add ITS services into those new facilities. If the region is making major investments in enhancing transit service, these enhanced services should be reflected in the regional ITS architecture.

Some regional ITS architectures may have a mapping from Regional Needs (or some other formulation not directly tied to the planning documents) to ITS services. A recommendation is to change this mapping to a more explicit connection to the transportation planning concepts in order to facilitate use by transportation planners. Some of the regional needs used in these previous versions are related to the current User Needs component and can be used to help in the update of that component.

The second major source of Service Package update information is through interaction with the stakeholders. As mentioned in the overall approach to updating a regional ITS architecture, a key early step in the update is to talk to key stakeholders to understand what updates they envision to their ITS deployments. This usually takes the form of interviews with key stakeholders regarding the service packages which the architecture currently identifies they participate in and identifying any additions/ subtractions/ or modifications of services implemented or planned by the stakeholder.

A significant source of possible new service packages to consider can be found in the current version of ARC-IT. See www.arc-it.net.

One of the best sources for potential service package changes is the conversion table outputs that identify all service packages that have been added, removed, or modified since the architecture was last updated.

Update Service Packages

Updating service package information is the key next step after collecting changes from the stakeholders. Because any regional ITS architecture is too large to fit onto a small number of diagrams, the service packages represent a key way to break up architecture information in a way that is easily understood and used by the stakeholders.

A service package is composed of elements, functional objects (within the elements) and information flows between the elements. Every ITS service selected for the region should be associated with one or more inventory elements that supports or will support that service. As part of the update you may want to run a report in RAD-IT called the Inventory to Service Package Comparison report that will identify potential inventory or service package gaps.

As shown below on the RAD-IT tab discussion, the Services tab contains the service package name, status, and mapping to elements of the architecture. Other aspects of the service package are entered on the Functions and Interfaces tabs. Diagrammatic outputs of service packages, whether coming directly from RAD-IT or from another diagrammatic tool (see below for examples of both) would be created as part of the update so that the revised diagrams could be reviewed with the stakeholders.

Review Service Package Updates with Stakeholders

The updates to service packages will be a key element of any review with stakeholders carried out as part of the update. In this review, organizing the information via a website or diagrams is a key to gaining consensus with the stakeholders on the changes. If done via stakeholder meetings, a suggestion is to use focused engagements so that stakeholders' time will be spent focusing on their portions of the architecture. This can be done by breaking into groups organized by stakeholder areas (e.g. traffic, transit, or public safety)

A suggestion is to use the Service Package Instance feature of RAD-IT to create a set of service package instances for each service that focus on the important interfaces centering on a single stakeholder. For example, if your architecture has the service package TM03 Traffic Signal Control (and pretty much every architecture does have this one), create a separate TM03 instance for each city, county, or state stakeholder actively engaged (or planning to be engaged) in traffic signal control. Putting the stakeholder name in the service package instance title will make it easy for stakeholders to identify service packages that focus on their operations. Using these instances will allow creation of simpler service package diagrams (either using the RAD-IT output or web features or using a customized diagram capability).

Defining ITS Services

The steps below describe an approach for defining ITS services in an architecture for the first time.

Create Initial List of ITS Services

The first step in creating a set of ITS services for a region is to review the planning documents for the region, which are described under the Regional Goals, Objectives, and Strategies component. Transportation long range plans typically discuss economic and social trends and how the infrastructure should be built to meet the region's needs. Many of these long term policies and goals are directly related to the ITS services that guide a regional ITS architecture. For example, if major new facilities are planned for the region, then it is appropriate to plan to add ITS services into those new facilities. If the region is making major investments in enhancing transit service, these enhanced services should be reflected in the regional ITS architecture.

The next step in developing an initial list of services is to review the Service Packages of ARC-IT. See www.arc-it.net. These service packages represent a very broad range of ITS services and identify the pieces of the architecture that are required to implement a particular service. They are also the key way that ITS services are described in RAD-IT (see the RAD-IT Tab). The developers can create an initial list of potential services and review these services with the stakeholders to gather their inputs. While the list of service packages in ARC-IT is quite extensive, there may be ITS services that go beyond those described in ARC-IT, or are variations of those in ARC-IT. Some regions have added services such as red light enforcement or flood monitoring, permitting coordination to the services identified by ARC-IT.

Beginning with a list of service packages or an alternative list of ITS services, services should be identified that:

-         Are currently provided by the ITS elements in the region,

-         Will be provided once planned projects are implemented, or

-         Address regional needs and may be implemented in the future.

Create a Full Set of ITS Service Packages

Starting with the list of service packages, the next step is to identify the key components of each service package. These components are:

-         Stakeholders

-         Elements

-         Information flows

These components should be entered into RAD-IT to fully define the architectures ITS services.

At this point, assuming Stakeholders and Elements have been defined you can focus on identifying the elements for each service. The stakeholder mapping will come because the elements are already mapped to a stakeholder. The information flows will be selected and customized during the Interfaces step.

Gather Stakeholder Inputs

Stakeholder input on each of these choices should be actively solicited, preferably in a direct forum like a brainstorming session or workshop. Remember that the focus for this task is on identifying the important ITS services; avoid getting bogged down in the specifics of how those services will be provided in this process step.

To make best use of stakeholder representative time, focus group discussion on ITS services that require group buy-in. ITS services that can be or will be implemented by a single agency require less discussion than ITS services that require integration between different stakeholders' ITS elements. For example, the decision to deploy a Surface Street Control service is an individual decision for a particular traffic agency, and may not be a priority for group discussion. In contrast, the decision to deploy Transit Signal Priority requires consensus by traffic and transit agencies and should be agreed to by all parties. Individual agency service choices can be coordinated offline if time is short.

It is usually appropriate to focus the discussion on services that have public sector involvement. Service packages that are exclusively private sector with no public sector interfaces (e.g., some autonomous vehicle safety and commercial services) can generally be excluded.

RAD-IT

The key information about Service Packages is contained on the Services Tab of RAD-IT. As shown below this is where the initial entry or updates of services names or descriptions and element mappings are performed. As shown on the tab, each service package has a name and description. In addition, the tab includes the indication of the status of the service (existing, planned, etc.), a list of projects associated with the service, and a listing of what elements are a part of the service. This last connection, between service package and elements is key to defining the interfaces contained in the service packages, as well as the functions defined for the elements.

Services Tab in RAD-IT

Once the interfaces tab has been filled out it is possible in RAD-IT to create service package diagrams such as the one below, which is for a service package instance of TM01 Infrastructure Based Surveillance from the above RAD-IT file.

Service Package Based Diagram Example

Examples

Examples of ITS Services can be found in every regional ITS architecture. The most common representation is found on architecture websites. There are many versions of architecture websites which can display services information in a variety of ways. Many regions create a website using RAD-IT to generate web pages. An example of how service packages are described on these sites is given in the example from the Nevada Statewide ITS Architecture shown below. In this case for each service package (instance) there is the name, description, list of elements in the service package, and a link to a diagram generated by RAD-IT. For this example, the diagram for this service package is shown below as well.

Nevada Service Package Web Page Example

Nevada Service Package Web Page Diagram

The second example comes from the Maricopa County Regional ITS Architecture, showing a diagrammatic view of the service package in addition to elements and information flows associated with the service package.

Maricopa County Service Package Example