ATIS02-Interactive Traveler Information
Transaction Set Diagram



Get the Source Graphic, a Windows Metafile (WMF), in ZIP format.
More about ZIP files

The following discusses how the National ITS Architecture provides the transportation service described by this market package. Each numbered item describes the operation of that portion of the market package identified with the corresponding number on the transaction set diagram.

Note that this transaction set diagram (TSD) is only 1 of the 3 TSDs and so only a portion of the numbered items below refer to the above TSD.

ATIS02 transaction set diagrams: 1 2 3 Next TSD

  1. The entire process is under the asynchronous monitoring (ISP operations information presentation) and control (ISP operator inputs) by the ISP Operator.

  2. Concurrently and asynchronously, information is collected by the ISP from a variety of sources:

    • Traffic Management Subsystem (road network conditions)

    • Transit Management Subsystem (transit and fare schedules), which include static as well as real time transit information and transit incident information, which includes real time incident information

    • Emergency Management Subsystem (incident information), including incidents arising from large-scale natural or human-caused disasters

    • Emissions Management Subsystem (air quality information)

    • Maintenance and Construction Management Subsystem (current asset restrictions), (maint and const work plans), (roadway maintenance status), and (work zone information)

    • Parking Management Subsystem (parking information)

    • Toll Administration (toll data)

    • Border Inspection Systems (border crossing status information)

    • Event Promoters (event information)

    • Media (external reports), which include traffic or incident information collected by the media

    • Multimodal Transportation Service Providers (multimodal information), which includes information about other transportation modes such as train, airplane, and ferry

    • Surface Transportation Weather Service (transportation weather information)

    • Weather Service (qualified environmental conditions data and weather information)

    • Other (ISP coordination), which provides for multiple ISPs exchanging information from separate sources for purposes of augmenting the broadcast information or corroborating specific information items

    This information is often based upon exceptional conditions, such as an incident in traffic, a storm, or other special events.

    Information collected by the ISP from some sources may come as the result of a specific request or be obtained through subscriptions. Specific requests include (transit information request), (parking lot data request), (toll data request), (event information request), and (transportation weather information request). With subscriptions, providers usually send periodic updates on a scheduled basis.

  3. The ISP provides information to several centers or systems tailored to their requests or needs. It provides (traveler information for media) to the Media. In addition, data collected by the ISP can be associated with links and nodes of the transportation network. An interface to a Map Update Provider is available to keep this model of the transportation network current. The ISP also provides (voice-based traveler information) to 511 systems (i.e., Telecommunications System for Traveler Information) upon request.

  4. Periodically, possibly by subscription or maybe on a regular schedule, the Remote Traveler Support Subsystem, RTS (e.g. a kiosk), may request and download (map updates).

  5. Asynchronously, and as often as desired, Travelers (who may later become Drivers) may enter requests for information (traveler inputs) into the Personal Information Access Subsystem, PIAS (e.g. personal computing device) or the RTS. These requests often take the form of a traveler profile which is stored in advance of its use (see box 7).

  6. Asynchronously, whenever a Traveler uses a Traveler Card with the PIAS or RTS, user information will be retrieved from the card (traveler card information).

  7. The core aspect of this market package is that travelers (or drivers) can make a request for personalized travel information. One method of requesting information is through the use of a traveler profile, which can be sent from the PIAS or from the Vehicle Subsystem to the ISP (see box 5). This “request” registers the user for a specific scope of travel information provided at specified intervals or times (e.g. incident information on a specific route provided every day at 5 PM).

    Alternately the traveler profile may provide parameters that are used whenever additional specific requests are made. The other mode of operation is for the Traveler to make a specific request (traveler request) that will elicit a specific response (interactive traveler information). This information is provided to the Traveler by the PIAS or ISP through visual or audio means (traveler interface updates). The cycle of request and response may be repeated as often as needed.

    In a similar cyclical manner, Drivers may make information requests (driver inputs) and then traveler requests and corresponding traveler information may be exchanged between a Vehicle and an ISP, and the result (driver updates) returned to the Driver.

  8. In between the time that a travel information request is sent to the ISP and the time that information is returned, the ISP may present a request for payment (payment request) and then receive transaction status on that request from a Financial Institution.

  9. Optionally, in conjunction with the financial transaction with the Financial Institution, a similar request for payment and corresponding payment may be made using the Traveler Card. If payment is required for the information request, and the Traveler Card is capable of making the payment, the transaction with the Financial Institution may not occur.

  10. Optionally, traveler card updates may be made to the Traveler Card by the PIAS or RTS. These would update the personal information on the Traveler Card based upon the traveler interaction with the PIAS or RTS.

  11. As a part of traveler information request, the Traveler may make reservations for demand responsive transit services. (Selected routes) can then be sent from the ISP to the Transit Management Subsystem to confirm the “reservation” for the service.

Hypertext Architecture Version 6.0.0 generated on 4/23/2007 from the following databases
Physical Architecture dated 4/6/2007,
Logical Architecture dated 4/23/2007,
Market Packages dated 4/23/2007,
Security dated 4/20/2007,
User Services dated 4/9/2007,
AppMap dated 4/23/2007 and the
SDOMAP dated 4/23/2007