EM06-Wide-Area Alert
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 4 TSDs and so only a portion of the numbered items below refer to the above TSD.

EM06 transaction set diagrams: 1 2 3 4 Next TSD

  1. The process begins when an alert is received by the Emergency Management Subsystem and is presented to the Emergency System Operator. Actual implementations must consider and allow for scenarios where multiple simultaneous alerts may be issued. This scenario describes the process of issuing a single isolated alert.

    The alert may be received from Alerting and Advisory Systems (alerts and advisories – for example an alert received through the Emergency Alerting System) or from another Emergency Management Subsystem (alert notification coordination – for example, an alert generated by the state police). The alert information is presented to the Emergency System Operator (emergency operations status). The Emergency System Operator reviews the alert, determines whether a coordinated alert using traveler information systems is warranted, and initiates the wide-area alert for the region (emergency operations inputs). Alternatively, the Emergency System Operator may also be the source for alert information that is received through voice communications and entered directly (emergency operations inputs). The decision to issue a wide-area alert is coordinated with public safety and other allied organizations (alert notification coordination).

  2. Under control of the Emergency System Operator, transportation system operators and traveler information providers for the region affected by the alert are notified (alert notification):

    • Information Service Provider

    • Traffic Management Subsystem

    • Transit Management Subsystem

    • Maintenance and Construction Management Subsystem

    • Toll Administration

    The alert is also provided to the media via the Emergency Alerting System (EAS) or other mechanism, but the process for injecting alerts into the media is outside ITS and not covered by this transaction.

  3. On receipt of the alert, the ISP presents the alert to the ISP Operator (ISP operations information presentation) who controls injection of the alert into the traveler information services operated by the ISP. The alert may be provided to travelers via:

    • Personal Information Access Subsystem (PIAS) representing personal computers, personal digital assistants (PDAs) and other personal devices.

    • Remote Traveler Support Subsystem (RTS) representing kiosks, public displays, and other public information access points.

    • Vehicle Subsystem (VS) representing in-vehicle driver information systems

    As priority traveler information, the alert is broadcast to all active users (emergency traveler information). The traveler interface updates and driver updates flows represent the actual presentation of the alert information to the traveler and driver. The traveler (or driver in the case of the Vehicle Subystem) can control or interact with the local device being used (traveler inputs for PIAS or RTS and driver inputs for the Vehicle.

    Similarly, the alert is injected into voice-based traveler information systems such as 5-1-1 (voice-based alert notification). The basic alert information could be provided to all system users using a “floodgate” message – a default message presented to all users. Depending on the nature of the alert, additional detailed information may be accessed by request (voice-based traveler request).

    Once the alerting capabilities provided by the ISP have been activated, the alert status is provided back to the Emergency Management Subsystem under control of the ISP operator (ISP operator inputs).

  4. On receipt of the alert, the Traffic Management Subsystem (TMS) presents the alert to Traffic Operations Personnel (traffic operator data) who control formatting and injection of the alert into the driver information services provided by the TMS. An alert message may be formatted and sent to dynamic message signs, highway advisory radio, or other driver information systems in the roadway (roadway information system data). In some cases, the alert information may be more than can be presented on a DMS. In these cases, a brief notification message may be generated that alerts drivers and directs them to tune to a radio station or other source for additional information. The message that the driver sees on the driver information system is represented by the driver information flow. When the driver systems have been activated, as indicated by roadway information system status, the status of the alert is provided back to the Emergency Management Subsystem (alert status) as directed by Traffic Operations Personnel (traffic operator data).

  5. On receipt of the alert, the Transit Management Subsystem (TRMS) presents the alert to Transit Operations Personnel (transit operations status) who control formatting and injection of the alert into the traveler information services provided by the TRMS (transit operations personnel inputs). The alert information is provided to transit vehicle operators (transit vehicle operator information) and also to travelers (transit traveler information) through kiosks and information displays operated by the transit agency (which are represented by the Remote Traveler Support subsystem) and on-board vehicle displays that provide information to passengers (on-board the Transit Vehicle Subsystem). As with other traveler information systems, the traveler may request additional information about the alert (transit information user request from the RTS or transit traveler request from the TRVS) depending on the capabilities of the transit information devices. The traveler interface updates flow represents the actual presentation of the alert information to the traveler. Traveler inputs represents the actual input from the traveler that requests more information.

  6. The Maintenance and Construction Management Subsystem also receives and presents the alert to Maintenance and Construction Personnel (maint and constr personnel information presentation). Maintenance and Construction personnel control the distribution of the alert throughout the maintenance and construction organization (maint and constr center personnel inputs). In this case, the purpose of the alert is to notify maintenance and construction personnel in the field that should be cognizant of active alerts for their own safety and so they can participate in alerts like child abduction alerts (Amber Alerts) where assistance in locating a suspect is requested. Alert status is reported back to the Emergency Management Subsystem confirming receipt and distribution of the alert.

  7. The Toll Administration Subsystem also receives and presents the alert to the Toll Administrator (toll information presentation). The Toll Administrator controls distribution of the alert within the toll organization (toll administration requests). This distribution includes distribution to toll operators working at toll plazas (toll advisories). As with Maintenance and Construction, the purpose of the alert is to notify agency personnel that should be cognizant of active alerts for their own safety and so they can participate in alerts like child abduction alerts (Amber Alerts). Alert status is reported back to the Emergency Management Subsystem confirming receipt and distribution of the alert, again under control of the Toll Administrator (toll administration requests).


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