(WIRLED PEAS): World Information Resources, Localized Environment Distribution: Personalized Emergency Alerting System

Michelle Raymond
michelle.raymond@honeywell.com

Abstract

As we become increasingly conscious of the risks in the world around us, we also become aware of the need to communicate with large numbers of people who may be exposed to a variety of hazards. Central services need to deliver the right information to the right people, giving first responders, public officials, news organizations, and members of the general public information they can actually use, without causing avoidable distress. The OASIS project for a Common Alerting Protocol, when combined with a reasoning system based on the OASIS eXtensible Access Control Markup Language, offers a new way to build emergency notification systems. CAP and XACML provide means for issuing alerts and building customized messages that can be delivered to individuals on cell phones, PDAs, and computer screens.

The issues addressed by this paper stem from the Homeland Security challenge to address the need to expediently provide emergency information to the general public. The Minneapolis Director of Emergency Preparedness called the issue of personal alerting, "the elephant no one in Emergency Response is really addressing."[Rollwagen]

To get appropriate information to each user, information about the users issues, interests, communication environment, and support mechanisms are highly useful. In this paper, a Common User Alerting Profile is showcased that provides a way to document a sharable user profile maintaining only the key points needed in determining appropriate presentation of the alert to the user.

Keywords: Technology Adoption; Metadata

Michelle Raymond

Michelle Raymond's expertise is in the area of Web-based Application's Design, Development and Usability, and Human Centered Focused Development and Application of Knowledge Technologies. Michelle began working with web technologies in 1995 creating educational and informational web sites for The Geometry Center, a National Science Foundation Research Center. In 1996 she moved to the Honeywell Labs' Human Centered Systems section. She is now a Senior Research Scientist in the Automation and Control Solutions, Knowledge Services Lab. Currently, Michelle's main interests are in Human Centered, Dynamic Generation of User Interfaces, Augmented Cognition and in bringing vital technologies to the areas of Emergency First Responder and Emergency Alert. External to Honeywell, Michelle owns and operates "Knowledge Interaction Consulting," and is a trained member of a "Community Emergency Response Team" in Minneapolis, Minnesota, USA.

(WIRLED PEAS)

World Information Resources, Localized Environment Distribution: Personalized Emergency Alerting System

Michelle Raymond [Senior Research Scientist; Honeywell Automation and Control Solutions, Knowledge Services Labs]

Extreme Markup Languages 2004® (Montréal, Québec)

Copyright © 2004 Michelle Raymond. Reproduced with permission.

Emergency Alerting

Problem Statement

In many alerting situations, people do not take the "emergency" seriously or delay action due to inadequate information. When they do respond, people's responses may complicate or exacerbate the situation. This is often due to insufficient, inconsistent or misinterpreted information. All of these issues can quickly lead to additional difficulties for the Emergency Response Personal and the communications and transportation infrastructure.

When alarms sound, even when people "know" the appropriate response, people often complacently ignore the alarm, idly delay response while waiting for further information or begin to search for information potentially jamming communication systems. An example of the communication >overload can be found at the Australian Bush Fire report that deals with an emergency information website and how it becomes overloaded by the public.[Worthington]

When Warning Sirens and Emergency Broadcast Systems are used to get people's attention and provide information, the alarms are generally more widely broadcast than necessary and slow to provide information pertinent to individuals or organizations at a specific location

"More timely and effective public alert and warnings would save lives, reduce property loss and speed economic recovery. Unfortunately, despite a public perception that an effective national alert and warning system exists, it does not. Existing systems fail to reach many people at risk while warning and alarming many who are not at risk... ...[Systems] are fragmented, unable to target only those people at risk, provide inconsistent messages and information, and lack coordination and interoperability." - Partnership for Public Warning (10/09/03) [PPW]

The current siren based alerting system can be dangerous due to people's complacency and regional habits. The scenario outlined at the end of this paper is based on a situation cited by the Minneapolis Office of Emergency Preparedness Director, Kristi Rollwagen. The current alerting system, Rollwagen noted, is based on a siren sounding near your neighborhood. Most United States Midwesterners assume the alert is weather related and rather than sheltering-in-place and turning on a radio or television for information, they stick their head out the front door and look at the sky. If there was an ammonia spill nearby, they would have just exposed themselves to potentially deadly harm. [Rollwagen]

Other methods, such as phone-tree contact lists, and email lists still only partially address the information dissemination needs. Often the communication systems are tied-up or taken-down before a phone-tree or email list can be completely traversed.

Solution

To get people to respond expediently and appropriately to an Emergency Alert, they must receive only alerts that require their attention and/or response and information that is timely, pertinent, and presented in an easy to understand manner. Communications must be meaningful and aid the recipient in choosing an appropriate response.

Emergency Alerting must address the need not only to alert and catch the attention of people; but also must:

  • provide the human user with immediate, relevant information
  • inform the user in an easy to understand format
  • continue to deliver updated and timely information
  • support each user or use community with personalized, appropriate data

The system focus is on timely information presented in a manner that encourages appropriate response to the emergency situation by including personalized instructions in the alert.

The key differentiator of the approach outlined in this paper is its focus on facilitating information presentation, timeliness and applicability to each end-user. This differentiator directly effects more appropriate responses by its users. Other results of the Personalized Emergency Alerting System include:

  • overall emergency response running more smoothly due to less interference from the public
  • easing the concerns of the public involved and
  • ultimately saving lives by faster and more appropriate actions on the part of individuals and organizations.

These differentiators are achieved and easily managed using several Markup Languages and a Reasoning System based on rules and policies encoded in various Markup Languages. The alerts are marked up adhering to the OASIS CAP [Common Alerting Protocol] 1.0 XML Schema.[CAPXSD] The User Profiles are based on profiles from a selection of sources and then mapped into a Common User Alerting Profile, showcased in this paper. The Common User Alerting Profile works well with reasoning systems where the rules and policies are based on the OASIS XACML [eXtensible Access Control Markup Language]. [XACML] The reasoning system used by the author for generating the information presentation (user interface) is the Interaction Design System. Any system can be used that can parse CAP compliant alerts and present the alert via a user communication device.

Personalized Emergency Alerting System Process Overview

When building a system that will accept many bits of disparate data, formatting it into an expected format makes sense. It makes sense, not only from our traditional data transfer view, where specific protocols make machine interpretation easier, but also for the ultimate view given to the information recipient. Obviously, the recipient can assimilate the information quicker and more accurately when it is provided in an expected, highly intelligible format.

"Expected formatting" is one reason it is recommend that data entering a system meant to construct alerting requests be formatted in XML and reference any appropriate data dictionaries or schema appropriate to the domain. It is one tiny step in making the construction of alerting systems quicker and more accurate.

The information sources 'feed' the XML formatted data to the systems and applications designed to construct the request for alerts. This part of the process acts as the point where the alert is formally requested and where a successful request will handle any intended information exchange side-effects, such as updating a database.

Next the applicable authorization systems allow or deny access to the data or user communications based on predetermined policies for handling 'alert construction' requests.

If the information is provided, the systems and applications that handle alert construction apply alert rules to create alerts that comply with the Common Alerting Protocol (CAP).

This process is shown in Figure 1 and continues in Figure 2.

Once the alert is encoded according to the Common Alerting Protocol, it is passed to the final systems and applications that generate presentations for the intended user or user sets. More information on one presentation generation approach can be found in [Raymond2].

Figure 1: Process of Information to Alert Construction
[Link to open this graphic in a separate page]
Figure 2: Process of Alert Construction to Information Presentation
[Link to open this graphic in a separate page]

User Profiles

Common User Alerting Profile Markup

The Common User Alerting Profile Markup described herein focuses on the needs of Emergency Alerting Systems. Organizations participating in a Personalized Emergency Alerting System are encouraged to encode commonly needed information, such as contact data and alert interests, directly in the Common User Alerting Profile Markup. This aids in speedy alert approval and alert construction. Organizations are likely to have additional profile information that is specific to their operations. This data can be kept in any internal format that allows query by systems with proper security authorization.

Organizations are encouraged to protect their data with access policies written in the eXtensible Access Control Markup Language. These policies allow queries from approved Policy Decision Points for only the information pertinent to alerting. Facilitation of data access by means of XPath support is recommended. Use of XPath to access additional data eases the burden of writing specific data access mechanisms for each data storage type and is supported by XACML for data lookup.

The Common User Alerting Profile contains three nodes:

  • information content of interest to the user
  • possible methods for alerting the user and
  • references to other people who are expected to receive the alert in the users place if the user cannot be contacted

Within the information content node is data about the source of the information, the context of the information and the subjects of interest from this source. There can be multiple information content nodes within a profile. This facilitates the merging of data when multiple sources contain information on the same subject of interest.

Within the methods of alerting node are references to contact types and the contact data. For example, a 'home phone' with data '612 555-3445' or a 'business email' with data 'Ada.Alice@happyhill.com.'

Finally, within the approved contact node is a reference to another user's id and one or more information content nodes detailing the information for which the user is approved.

Profile Content Separation

As noted above, it will be typical for companies to have a semi-public user alerting profile and a less accessible user profile for additional data.

For example, Alice Ada may have a profile with Roadside Companion, a traffic and roadside assistance service. Her common profile from Roadside Companion may look like this:

Figure 3: Alice Ada's Common User Alerting Profile for Roadside Companion
<?xml version="1.0" encoding="utf-8" ?>
<userProfile
  xmlns="http://www.alerts.honeywell.com/schema/commonuseralertingprofile.xsd"
  id="rs435233557" name="Dr. Alice Ada">
  <approvedContact id="Shr00244" name="Alert Man">
    <informationContent>
      <informationSource>
        <accessClearance>
          <identification>DM556842224</identification>
          <passCode>O3J9H</passCode>
          <parameters>VIN-450-344-22-2445</parameters>
        </accessClearance>
      </informationSource>
      <informationContext contextID="RegisteredSchedule" />
      <informationContext contextID="TripEntry" />
      <informationContext contextID="CurrentLocation" />
      <informationSubject>
        <subjectLabel>RoadWork</subjectLabel>
        <subjectLabel>TrafficFlow</subjectLabel>
      </informationSubject>
    </informationContent>
  </approvedContact>
  <informationContent>
    <informationContext contextID="RegisteredSchedule" />
    <informationContext contextID="TripEntry" />
    <informationContext contextID="CurrentLocation" />
    <informationSubject>
      <subjectLabel>RoadWork</subjectLabel>
      <subjectLabel>TrafficFlow</subjectLabel>
    </informationSubject>
  </informationContent>
  <contactInformation>
    <contactDetail contactType="automobileSpeakerAlert">152.334.56.554</contactDetail>
    <contactDetail contactType="automobileRadioInterupt">80.1</contactDetail>
    <contactDetail contactType="automobileDisplay">800 555-7887</contactDetail>
    <contactDetail contactType="cellPhone">612 555-4555</contactDetail>
    <contactDetail contactType="homePhone">612 555-3356</contactDetail>
    <contactDetail contactType="homeEmail">AAda@hotmail.com</contactDetail>
    <contactDetail contactType="homeAddressIP">255.332.23.454</contactDetail>
    <contactDetail contactType="workEmail">Alice.Ada@HappyHills.com</contactDetail>
    <contactDetail contactType="workPager">651 555-5566</contactDetail>
  </contactInformation>
</userProfile>
          

The above information all fits within the format of the Common User Alerting Profile, yet the roadside assistance application also needs domain and service information specific to its system. This data may be held in a second user profile containing data appropriate only to that domain or information of a more secure nature.

For example, The Roadside Companion company may keep data on Alice's scheduled travel and her automobile's current location. Although, some of this information may be valuable for other systems in determining the most appropriate alert, access to that information can be restricted by Alice or Roadside Companion through use of XACML policies and a second level data storage that requires password and situational clearance. The methods for access will be noted later in the paper.

The secondary, more secure Roadside Companion data store may be encoded in any way. This example shows the data in XML.

Figure 4: Alice Ada's User Profile with Roadside Companion
...
<autoInformation vinNumber="VIN-450-344-22-2445">
  <manufacturer>Volkswagon</manufacturer>
  <model>Jeta</model>
  <year>2005</year>
  <color>white</color>
  <licencePlate state="MN">PEA001</licencePlate>
  <trackingMethods>
    <device id="TrackOne_M216" />
    <device id="CityTrackPEA001" />
  </trackingMethods>
  <communicationDevices>
    <device id="dashboardDisplay07" />
    <device id="carRadioInterupt">
      <parameter parmType="frequency">80.1</parameter>
    </device>
    <device id="visorMountSpeaker1-01" />
  </communicationDevices>
</autoInformation>
<baseSchedule>
  <trip name="workToHome">
    <scheduleApplication>
      <daysOfWeek>
        <day>Monday</day>
        <day>Thursday</day>
      </daysOfWeek>
      <startTime>13:55:00-05:00</startTime>
      <arrivalTime>14:30:00-05:00</arrivalTime>
    </scheduleApplication>
    <route>
      <startAddress>
        <streetAddress>510 Fairview Ave. North</streetAddress>
        <city>St. Paul</city>
        <state>Minnesota</state>
      </startAddress>
      <endAddress>
        <streetAddress>3500 Newton Ave North</streetAddress>
        <city>Minneapolis</city>
        <state>Minnesota</state>
      </endAddress>
      <path type="shortest"> ...
...
      </path>
    </route>
  </trip>
  <trip name="homeToMall"> ...
...
        

In this data store, information is included that notes which information specific requestors can access given specified requirements. For example, a requestor company, Alert Man, can get information on the user's current location and copies of alerts on traffic flow if they have access clearance. Instead, this could be written as a specific policy in XACML stating that the subject, Alert Man, is entitled to the resource Alice Ada's current location and traffic flow alerts if the rules for access clearance are met. The downside of this approach is that the policy is very specific and therefore, a policy has to be written for each data resource request. By storing the information sharing requirements in an XML data store, a single approval policy can be written and applied to any user profile supporting this data format. More on the access policy will be addressed later in this paper.

Combining Common User Alerting Profiles

Alert subscribers may become inundated with alerts and overlapping information, as more organizations and services provide alerting. This can quickly become confusing and cumbersome in a large-scale or multiple system emergency. Services that manage and filter alerts can take Common User Alerting Profiles and combine them to create a consolidated picture of the users alerting interests, information sources and communication mechanisms. This will aid in keeping the flow of information appropriately coordinated to ease both the stress on the communication systems and the end users cognitive processing.

Below, the alerting profile for Alice Ada's Roadside Companion service is merged with her alerting profile for alerting services provided by the city of Minneapolis. Note that information content is still separated by provider. The contact information is combined. Sources of contact supported by less than all of the providers are tagged with source provider data.

Figure 5: A Multi-source Common User Alerting Profile
<?xml version="1.0" encoding="utf-8" ?>
<subscriber
  xmlns="http://www.alerts.honeywell.com/schema/commonurseralertingprofile.xsd"
  id="432768990" name="Dr. Alice Ada">
  <informationContent>
  <informationSource id="MINDOT" name="Department of Transportation">
    <accessPath>url:city:minneapolis:MINDOT</accessPath>
    <accessClearance>
      <userName>Dr. Alice Ada</userName>
      <identification>432768990</identification>
      <passCode>WqR5^</passCode>
    </accessClearance>
  </informationSource>
  <informationContext contextID="Minneapolis">
    <contextRoll>resident</contextRoll>
  </informationContext>
  <informationSubject>
    <subjectLabel>SnowEmergency</subjectLabel>
  </informationSubject>
</informationContent>
<informationContent>
  <informationSource id="MINDOT" name="Department of Transportation">
    <accessPath>url:city:minneapolis:MINDOT</accessPath>
    <accessClearance>
      <userName>Dr. Alice Ada</userName>
      <identification>432768990</identification>
      <passCode>WqR5^</passCode>
    </accessClearance>
  </informationSource>
  <informationContext contextID="3500 Newton Ave North" />
  <informationSubject>
    <subjectLabel>NoParking</subjectLabel>
    <subjectLabel>RoadWork</subjectLabel>
    <subjectLable>TrafficFlow</subjectLabel>
  </informationSubject>
</informationContent>
<informationContent>
  <informationSource id="RS7786">
    <accessPath>urn:roadside:traffic</accessPath>
    <accessClearance>
      <userName>Alice Ada</userName>
      <identification>DM556842224</identification>
      <passCode>O3J9H</passCode>
      <parameters>VIN-450-344-22-2445</parameters>
    </accessClearance>
    </informationSource>
    <informationContext contextID="RegisteredSchedule" />
    <informationContext contextID="TripEntry" />
    <informationContext contextID="CurrentLocation" />
    <informationSubject>
      <subjectLabel>RoadWork</subjectLabel>
      <subjectLabel>TrafficFlow</subjectLabel>
    </informationSubject>
  </informationContent>
  <contactInformation>
    <contactDetail contactType="homePhone">612 555-
      3356</contactDetail>
    <contactDetail contactType="cellPhone">612 555-
      4555</contactDetail>
    <contactDetail contactType="personalEmail">
      AAda@hotmail.com
    </contactDetail>
    <contactDetail
      contactType="workEmail">Alice.Ada@HappyHills.com
    </contactDetail>
    <contactDetail
      contactProvider="roadsidecompanion"
      contactType="dashboardDisplay">
      dashboardDisplay07
    </contactDetail>
    <contactDetail contactType="carRadioInterupt">
      <parameter paramType="frequency">80.1</parameter>
    </contactDetail>
    <contactDetail
      contactProvider="roadsidecompanion"
      contactType="automobileSpeaker">
      visorMountSpeaker1-01
    </contactDetail>
  </contactInformation>
</subscriber>
        

Alert Approval Policies

Alerting Markup

The alerting markup is critical in enhanced speed and uniformity of processing. The alerting structure must be:

  • independent of the information source, allowing for many types of situations to be encoded in adherence to a common alerting schema.
  • controlled, allowing only authorized individuals or systems to send and receive information within their purview.
  • minimal in construction time of alerts.
  • able to use as the context of the alert, alert senders and recipients, as well as other people associated with the recipients.
The last item aids in allowing the individuals or groups to be the central context of the subscribers alerts. For example, Alice Ada may receive the message that "Your grandson, Josh, is sheltered at the Northern Community Center," rather than the message "The central elementary schools are being evacuated." Josh in the relationship of grandson is central context. This is more specific and psychologically impacting than a general alert about schools.

The basis for the alerting markup is the Community Alerting Protocol 1.0 provided through the OASIS Emergency Alerting Tech Group.

"The Common Alerting Protocol (CAP) is the OASIS Emergency Management Technical Committee's first standard for homeland security and civil emergency management... ...[CAP] is a simple, flexible data interchange format for collecting and distributing "all-hazard" safety notifications and emergency warnings over information networks and public alerting systems. ... ...[It] is a content standard, deliberately designed to be "transport-agnostic." In web-services applications, CAP provides a lightweight standard for exchanging urgent notifications. CAP can also be used in data-broadcast applications and over legacy data networks." - CAP Fact Sheet [CAPFact]

Examples of alerts are shown later in the paper.

Approving Alert Construction

Alerts are constructed to get the right content to the right user with ease of user uptake. The initial step in this process is verifying that the alert is appropriate to the given user. For example, a chemical cloud containing anhydrous ammonia is six minutes away from a local high school and the school is alerted to this emergency. The school's Alerting System checks its policies against the incoming alert and determines that there is no time to evacuate and the facility must engage its shelter-in-place procedure. Part of that procedure is the automatic sending of alerts to the students' approved first level contacts, alerting them that their charges are safely sheltered and not to approach the building until further notice.

Figure 6: School Policy for Constructing Alerts for Students' Primary Contact
<Policy
... >
  <Target>
...
  </Target>
  <Rule
    RuleId="urn:alerts:honeywell:names:emergencyalert:1.0:school:SendEmergencyAlert:rule"
    Effect="Permit">
    <Description>
      Test to see if the subscriber is the first contact  for a student and
      as such should receive an alert.
    </Description>
    <Target>
      <Subjects>
        <Subject>
          <SubjectMatch
            MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue
              DataType="http://www.w3.org/2001/XMLSchema#string">
              student
            </AttributeValue>
            <SubjectAttributeDesignator
              AttributeId="subscriber:informationContent:informationContext:
              attribute:contextType"
              DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </SubjectMatch>
          <SubjectMatch
            MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue
              DataType="http://www.w3.org/2001/XMLSchema#string">
              first contact
            </AttributeValue>
            <SubjectAttributeDesignator
              AttributeId="subscriber:informationContent:informationContext:roll:
              attribute:value"
              DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </SubjectMatch>
        </Subject>
      </Subjects>
      <Actions>
        <Action>
          <ActionMatch
            MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <AttributeValue
              DataType="http://www.w3.org/2001/XMLSchema#string">
              read
            </AttributeValue>
            <ActionAttributeDesignator
              AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
              DataType="http://www.w3.org/2001/XMLSchema#string"/>
          </ActionMatch>
        </Action>
      </Actions>
    </Target>
  </Rule>
</Policy>
        

The automatic alerting frees school staff from needing to start phone-tree alerts or contact the media. They can start addressing the immediate needs of the facility's occupants. This system also provides for quicker delivery of alerts and far less chance of a portion of the phone-tree recipients not receiving the alert.

Approving Alert Merging within a Single Alert Provider

Often a potential recipient of an alert may have multiple contexts for receiving the same message. One example, is a guardian with multiple charges attending the same school. Another example, is an employee at a nursing home who, also, has a parent who lives at the facility. The formulated alert may apply to both employees and the contact people for facility residents.

The Policy for approval produces a bag of alert recipient data. In the case of the school, sending alerts to subscribers in the roll of first contact, the bag may contain both:

<recipient subjectID="AliceAda_Sub00034532"
  contextID="PaulAda-Jones_2005_St575432"
  contextRelation="son" />
      
and
<recipient subjectID="AliceAda_Sub00034532"
  contextID="SaraJones_2007_St745788"
  contextRelation="niece" />.
      

When the alerts are constructed the common subjectID can cue the system with the context "your son Paul Ada-Jones and your niece Sara Jones ..." instead of two separate messages with highly overlapping content.

In the case of the employee of the nursing home, a common alert may have the combined context "as an employee and as the contact for Mr. Raj Ada ..." However, in this case it is likely that the alerts will also be based on the user's roll and the same alert will not be applicable to each roll. Perhaps contacts of residents are requested to not come to the facility: yet the employees are requested to come to the facility to aid in the evacuation of the residents. This case will be addressed later in the roll based alerting section.

Approving Alert Merging within Multiple Alert Providers

When multiple alert providers are producing alerts that may be combined, it is usually handled by a multiple source alerting service. This type of service was presented in the Alert Man example “A Multi-source Common User Alerting Profile” where a combined user alert profile was constructed. Continuing with the example, the Alert Man application may receive traffic alert information both from the City and from the Roadside Companion service. The alerts are encoded in the Common Alerting Protocol and can be evaluated by a policy designed to determine their content overlap.

Below is an example of the alert from the city followed by the alert from the roadside service. The lines that differ are in bold text.

Figure 7: City Travel Alert
<?xml version="1.0" encoding="utf-8" ?>
<alert xmlns="http://www.incident.com/cap/1.0.xsd">
  <identifier>2005-04-10TravelAlert-FreewayReversal</identifier>
  <sender>traffic_alert@dot.city.mi.mn.gov</sender>
  <sent>2005-04-10T14:09:05-05:00</sent>
  <status>Actual</status>
  <msgType>Alert</msgType>
  <source>Department of Transportation</source>
  <scope>Restricted</scope>
  <restriction>GreaterTwinCitiesArea</restriction>
  <references>
    0006-04-10CityMinneapolisHazmat0007
    2005-04-10TravelAlert-20mileRadius
  </references>
  <incidents>
    20050410AmmoniaDetectionNorthTrainYard/special-alerts@meteorology.org
  </incidents>
  <info>
    <category>Geo</category>
    <category>Safety</category>
    <category>Health</category>
    <category>Transport</category>
    <category>Infra</category>
    <event>20050410ReversalOfI94</event>
    <urgency>Immediate</urgency>
    <severity>Severe</severity>
    <certainty>Very Likely</certainty>
    <effective>2005-04-10T14:15:00-05:00</effective>
    <senderName>Department of Transportation</senderName>
    <headline>Reversal of Parts of I-94 Traffic Flow</headline>
    <description>
      An accident involving Ammonia has released over 80 tons into Northern
      Minneapolis.  Anyone driving within the 494/696 loop, or the southern parts
      of Minneapolis and St. Paul should get off the roadway or leave the area.
    </description>
    <instruction>
      To facilitate movement away from the effected areas, Interstate-94 will be
      blocked off so that both sets of lanes NorthWest of the Dowling Exit will
      move West and both sets of lanes SouthEast of the Dowling Exit will move
      East.  The reversal will be in effect along the stretch from Maple Grove
      to Woodbury.
    </instruction>
    <resource>
      <resourceDesc>
        Maps of the affected area and potential hazard travel
      </resourceDesc>
      <uri>
        http://public.meteorology.org/reports/2005-05-10/0022/
      </uri>
    </resource>
    <area>
      <areaDesc>Location of the reversal point.</areaDesc>
      <polygon>
        45.01.68, 93.17.17 45.01.22, 93.16.96
        45.01.43, 93.17.06 45.01.68, 93.17.17
      </polygon>
    </area>
    <area>
      <areaDesc>Location of the West end.</areaDesc>
      <areaDesc>Intersection of I-94 and 694.</areaDesc>
      <polygon>
        45.05.89, 93.27.15 45.05.39, 93.26.15
        45.05.89, 93.27.15
      </polygon>
    </area>
    <area>
      <areaDesc>Location of the East end.</areaDesc>
      <areaDesc>Intersection of I-94 and 494.</areaDesc>
      <polygon>
        44.56.92, 92.57.77 44.56.92, 92.57.31
        44.56.92, 92.57.53 44.56.92, 92.57.77
      </polygon>
    </area>
  </info>
</alert>
        
Figure 8: Roadside Area Alert
<?xml version="1.0" encoding="utf-8" ?>
<alert xmlns="http://www.incident.com/cap/1.0.xsd">
  <identifier>2005-04-10T14:08:45AreaEmergency</identifier>
  <sender>alerting@roadsidecompanion.com</sender>
  <sent>2005-04-10T14:08:45-05:00</sent>
  <status>Actual</status>
  <msgType>Alert</msgType>
  <source>Roadside Companion</source>
  <scope>Restricted</scope>
  <restriction>Minneapolis</restriction>
  <restriction>North Metro</restriction>
  <restriction>St Paul</restriction>
  <restriction>SouthEast Metro</restriction>
  <restriction>Current Location</restriction>
  <restriction>Less than 2 Hour Future Location</restriction>
  <references>2005-04-10TravelAlert-20mileRadius</references>
  <incidents>
    20050410AmmoniaDetectionNorthTrainYard/special-alerts@meteorology.org
  </incidents>
  <info>
    <category>Safety</category>
    <category>Health</category>
    <category>Transport</category>
    <event>20050410AmmoniaDetectionNorthTrainYard</event>
    <urgency>Immediate</urgency>
    <severity>Severe</severity>
    <certainty>Very Likely</certainty>
    <effective>2005-04-10T13:52:23-05:00</effective>
    <senderName>Roadside Companion Travel Alert</senderName>
    <headline>Chemical Spill Hazard to Motorists</headline>
    <description>
      An accident involving Ammonia has released over 80 tons into Northern
      Minneapolis.  Anyone driving within the 494/696 loop, or the southern parts of
      Minneapolis and St. Paul should get off the roadway or leave the area.
    </description>
    <instruction>
      If you are currently driving in North or NorthEast Minneapolis there is a
      sever danger of ammonia poisoning. Find immediate shelter. It is safer
      inside most buildings than in a moving vehicle.  If you are still outside
      of the severe area, drive North or South out of the wind path. The path
      starts in North Minneapolis and travel SE toward Downtown St. Paul.
      Avoid use of I-94.
    </instruction>
    <resource>
      <resourceDesc>Travel hazards maps</resourceDesc>
      <uri>
        http://roadsidecompanion.com/twincities/emergency/20050410/
      </uri>
    </resource>
    <area>
      <areaDesc>Location of the hazmat incident.</areaDesc>
      <circle>45.02, 93.18 .2</circle>
    </area>
    <area>
      <areaDesc>
        Area predicted to be affected by 2:30 PM.
      </areaDesc>
      <polygon>
        45.02, 93.18 45.02, 93.17 45.02, 93.15 45.01, 93.12 45.01, 93.10
        45.00, 93.08 44.59, 93.07 44.58, 93.07 44.57, 93.08 44.56, 93.10
        44.56, 93.12 44.57, 93.14 44.58, 93.15 45,00, 93.17 45.01, 93.18
        45.02, 93.18
      </polygon>
      <altitude>10</altitude>
    </area>
  </info>
</alert>
        

The alert management policy that determines how to combine the alerts may produce a single alert like the following:

Figure 9: The Alert Man Service Combined Travel Emergency Alert
<?xml version="1.0" encoding="utf-8" ?>
<alert xmlns="http://www.incident.com/cap/1.0.xsd">
<!-- Substitute in new header information -->
  <identifier>
    am2005-04-10TrafficEmergency14:09:25
  </identifier>
  <sender>alerting@alertman.com</sender>
  <sent>2005-04-10T14:09:25-05:00</sent>
<!-- Where information is the same, leave the
  content alone. -->
  <status>Actual</status>
  <msgType>Alert</msgType>
<!-- Attribute both sources but using the union of
  the sources.-->
  <source>Department of Transportation</source>
  <source>Roadside Companion</source>
  <scope>Restricted</scope>
<!-- Use the intersection of the restricted
  geographic area.  In this case, one set
  supercedes the other. -->
  <restriction>GreaterTwinCitiesArea</restriction>
<!-- Use the longer of the two time restrictions.
  In this case one set is empty, implying a limitless time.  Thus, the
  location restrictions are removed from the merged alert. -->
<!-- Use the union of the sets of references. -->
  <references>
    0006-04-10CityMinneapolisHazmat0007
    2005-04-10TravelAlert-20mileRadius
  </references>
  <incidents>
    20050410AmmoniaDetectionNorthTrainYard/special-alerts@meteorology.org
  </incidents>
  <info>
<!-- Use the union of the set of categories. -->
    <category>Geo</category>
    <category>Safety</category>
    <category>Health</category>
    <category>Transport</category>
    <category>Infra</category>
<!-- Use the union of events. -->
    <event>20050410AmmoniaDetectionNorthTrainYard</event>
    <event>20050410ReversalOfI94</event>
    <urgency>Immediate</urgency>
    <severity>Severe</severity>
    <certainty>Very Likely</certainty>
<!-- Use the earlier effectiveness time. -->
    <effective>2005-04-10T13:52:23-05:00</effective>
    <senderName>Alert Man</senderName>
<!-- Combine headlines with colons.  These next three nodes are
  generally checked by a human when possible to ensure readability. -->
    <headline>
      Chemical Spill Hazard to Motorists:
      Reversal of Parts of I-94 Traffic Flow
    </headline>
    <description>
      An accident involving Ammonia has released over 80 tons into Northern
      Minneapolis.  Anyone driving within the 494/696 loop, or the southern
      parts of Minneapolis and St. Paul should get off the roadway or leave
      the area.
    </description>
<!-- Use both instructions. Note that in this case the human trimmed off
  the warning, in the original Roadside Companion alert, to avoid
  Interstate 94. -->
    <instruction>
      If you are currently driving in North or NorthEast Minneapolis there is a
      sever danger of ammonia poisoning. Find immediate shelter. It is safer
      inside most buildings than in a moving vehicle.  If you are still outside
      of the severe area, drive North or South out of the wind path. The path
      starts in North Minneapolis and travel SE toward Downtown St. Paul.
    </instruction>
    <instruction>
      To facilitate movement away from the effected areas, Interstate-94 will be
      blocked off so that both sets of lanes NorthWest of the Dowling Exit will
      move West and both sets of lanes SouthEast of the Dowling Exit will move
      East. The reversal will be in effect along the stretch from Maple Grove
      to Woodbury.
    </instruction>
<!-- In the case of map resources there is standing rule to use the
  Roadside Companion maps -->
    <resource>
      <resourceDesc>Travel hazards maps</resourceDesc>
      <uri>
        http://roadsidecompanion.com/twincities/emergency/20050410/
      </uri>
    </resource>
<!-- Use the union of all area nodes from both sets of area nodes. -->
    <area>
      <areaDesc>Location of the hazmat incident.</areaDesc>
      <circle>45.02, 93.18 .2</circle>
    </area>
    <area>
      <areaDesc>Area predicted to be affected by 2:30 PM.</areaDesc>
      <polygon>
        45.02, 93.18 45.02, 93.17 45.02, 93.15 45.01, 93.12 45.01, 93.10
        45.00, 93.08 44.59, 93.07 44.58, 93.07 44.57, 93.08 44.56, 93.10
        44.56, 93.12 44.57, 93.14 44.58, 93.15 45,00, 93.17 45.01, 93.18
        45.02, 93.18
      </polygon>
      <altitude>10</altitude>
    </area>
    <area>
    <areaDesc>Location of the reversal point.</areaDesc>
      <polygon>
        45.01.68, 93.17.17 45.01.22, 93.16.96
        45.01.43, 93.17.06 45.01.68, 93.17.17
      </polygon>
    </area>
    <area>
      <areaDesc>Location of the West end.</areaDesc>
      <areaDesc>Intersection of I-94 and 694.</areaDesc>
      <polygon>
        45.05.89, 93.27.15 45.05.39, 93.26.15 45.05.89, 93.27.15
      </polygon>
    </area>
    <area>
      <areaDesc>Location of the East end.</areaDesc>
      <areaDesc>Intersection of I-94 and 494.</areaDesc>
      <polygon>
        44.56.92, 92.57.77 44.56.92, 92.57.31 44.56.92, 92.57.53
        44.56.92, 92.57.77
      </polygon>
    </area>
  </info>
</alert>
        

Customized Alerts

Customized alerts have already been addressed based on simple attributes of the user profile. Customization was shown in the school example, where the student's name and the student's relationship to the subscriber was inserted into the message. The combination of the school alerts for two students with the same contact was also an example of customization. Further customization was shown in the example of combining alerting data from multiple alerting services through the use of an alert management service.

Alert Construction based on User Roll

In the following example, the alerts pertain to a train derailment releasing anhydrous ammonia. The City Hazmat Office is sending alerts to the local hazmat team and the city residents living near the emergency incident. Both groups are provided information needed to respond to the incident quickly and appropriately based on their roll. The hazmat team is alerted to show up at the emergency site in full hazmat gear. The nearby residents are alerted to shelter-in-place. Both groups are given web links to further information. The sites of the information are in separate server-farms, thus the public can't bring down the Incident Responder information site. The public site is provided faster loading data by caching preformatted images and restricting the resolution of the data that can be retrieved. For example, if evacuation maps are appropriate, they may not be custom produced for each user. Instead the system may use a set of pre-stored neighborhood evacuation maps at a common street level resolution. For more information on this concept see the report on the 2002 Australian Bush Fires. [Worthington]

Much of the data is the same in the alerts. The data modified for appropriate processing and personalization to the appropriate user groups is noted as comments in the Alert encoding. In reality, these would appear as two messages, "2005-04-12HazmatAlert-HazmatTeam12Msg1" and "2005-04-12HazmatAlert-Zone1ResidentsMsg1".

Here are the alerts to the Fire Department Hazmat Team at Station 12 and to the city residents living near the incident site:

Figure 10: Intermixed Alerts to Two Distinct User Groups Regarding the Same Incident
<?xml version="1.0" encoding="utf-8" ?>
<alert xmlns:rr="http://www.incident.com/cap/1.0.xsd">

<!-- 'identifier' in message to the Hazmat Team -->
  <identifier>2005-04-12HazmatAlert-HazmatTeam12Msg1</identifier>
<!-- 'identifier' in message to the Nearby Residents -->
  <identifier>2005-04-12HazmatAlert-Zone1ResidentsMsg1</identifier>

  <sender>situation-response@hazmat.city.mi.mn.gov</sender>

<!-- time 'sent' in message to the Hazmat Team -->
  <sent>2005-04-12T14:06:04-05:00</sent>
<!-- time 'sent' in message to the Nearby Residents -->
  <sent>2005-04-12T14:06:03-05:00</sent>

  <status>Actual</status>
  <msgType>Alert</msgType>
  <source>City Hazmat Office</source>
  <scope>Restricted</scope>

<!-- 'restriction' in message to the Hazmat Team -->
  <restriction>Hazmat Team: Station 12</restriction>
<!-- 'restriction' in message to the Nearby Residents -->
  <restriction>Zone 1 Area Residents</restriction>

  <references>
    rrAlert005EmergencyTeam/emergency-lead@mn.rail.com
    indReportSpecialChemAlert2005-04-12_0022/
  </references>
  <incidents>
    20050412AmmoniaDetectionNorthTrainYard/special-alerts@meteorology.org
  </incidents>
  <info>
    <category>Met</category>
    <category>Safety</category>
    <category>Health</category>
    <category>Env</category>
    <category>Transport</category>
    <event>
      20050412AmmoniaDetectionNorthTrainYard
    </event>
    <urgency>Immediate</urgency>
    <severity>Severe</severity>
    <certainty>Very Likely</certainty>
    <effective>2005-04-12T13:52:23-05:00</effective>
    <senderName>
      City Hazmat Office, Officer Uri Wold
    </senderName>

<!-- 'headline', 'description' and instruction' in message to
  the Hazmat Team -->
    <headline>
      Take Immediate Action: Railroad Ammonia Leak
    </headline>
    <description>
      A train derailed at 13:52 today,
      releasing anhydrous ammonia. The site of spill is
      near railway marker 1704 on the North track.
    </description>
    <instruction>
      Assistance is needed in hazmat
      containment. Report directly to the site, fully suited.
      The site can be reached via the railyard access road
      North of the Humbolt junction.
    </instruction>
<!-- 'headline', 'description' and instruction' in message to the
  Nearby Residents -->
    <headline>
      Take Immediate Action: Railroad Ammonia Leak
    </headline>
    <description>
      A train derailed at 1:52 this afternoon, releasing a
      hazardous chemical near your neighborhood.
      Railroad and City Emergency Responders are
      containing the spill.
    </description>
    <instruction>
      If you are home, close all windows and turn off
      the heat or air conditioner. Move to the most
      protected part of you home and await further
      instructions. Do not leave your home. It is
      safer inside than in a moving vehicle.
    </instruction>

<!-- Each 'resource' holds a 'uri' to a secure website on a
  separate server from the one used by the public in the
  message to the Hazmat Team. -->
    <resource>
      <resourceDesc>
        Set of wind pattern maps
      </resourceDesc>
      <uri>
        https://meteorology.org/reports/2005-05-12/0022/
      </uri>
    </resource>
    <resource>
      <resourceDesc>
        Animation of wind and chemical plume
      </resourceDesc>
      <uri>
        https://meteorology.org/reports/2005-05-12/0022/anim/
      </uri>
    </resource>
<!-- 'resource' holds a 'uri' to a public website on a separate
  server from the one used by incident responders in the
  message to the Nearby Residents. -->
    <resource>
      <resourceDesc>
        Maps of the affected area and potential hazard travel
      </resourceDesc>
      <uri>
        http://public.meteorology.org/reports/2005-05-12/0022/
      </uri>
    </resource>

    <area>
      <areaDesc>
        Location of the hazmat incident.
      </areaDesc>
      <circle>21.1, -87.08 .2</circle>
    </area>

<!-- The second 'area' element contains a polygon representing the
  area covered by the maps available at the 'resources' noted
  above in the message to the Hazmat Team. -->
    <area>
      <areaDesc>Minneapolis and Surrounding Area
        Map Size</areaDesc>
      <polygon>18, -88 18, -86 23.5, -86 23.5,
        -88 18, -88</polygon>
      <altitude>375</altitude>
    </area>

<!-- The second 'area' element contains a polygon representing the
  area predicted to be affected by 2:30 PM in the message to
  the Nearby Residents. This would not be shown to the user
  as a list of coordinates. It would be converted to an image
  or vector drawing over an appropriate map. If their
  communication device does not support graphics, this
  data would not be presented. -->
    <area>
      <areaDesc>Area predicted to be affected by
        2:30 PM.</areaDesc>
      <polygon>20.5, -87.0 20, -86.0 20, -85.5
        20.5, -90.0 22, -93.5 24, -93 24.5, -94 24,
        -90 20, -87.5 20.5, -87.0</polygon>
      <altitude>375</altitude>
    </area>

  </info>
</alert>
      

The case where a subscriber has two distinct roles within one system and both rolls are approved for alert receipt has two sub-cases. The first is where the two roles would receive customized alerts based on the same template. For example, a person in the roll of first contact for a student and softball coach would both be alerted not to come to the school before receiving notification that the situation was clear.

The second case is as in the earlier example of subscriber, Dr. Ada, who both works at the Happyhills Elder Home and is the contact for her father Raj Ada, two different alerts are formulated based on the rolls of employee and contact. Within the alerting policy, the rule for the employee role, creating an alert to ask for assistance, would override the rule for the contact role, creating an alert to redirect visitors to a secondary facility.

Alert Construction based on Combined Data

Obviously, if data for an alert is all maintained by a single source, the associated system can construct the alert. When data across systems is desirable, either for combining in an alert or for decision making, the data sources can control what information is shared. Each system either maintains its own policies on "Alert Approval," "Alert Construction," and "Alert Presentation" or uses a service to provide these functions. These policies may be written to determine whether or not to share data, as well as, whether or not to process the alert internally.

For example, Alice Ada is a doctor and a volunteer for medical staffing of community shelters. In the case of a chemical plume, it is desired to assign volunteers to shelters they can reach quickly without their own overexposure to the chemical. Therefore, if there is an alternate shelter, doctors shouldn't be asked to report to a shelter South of the chemical path if they are currently located North of the emergency. They would have to drive around the incident area to arrive safely. This adds to traffic congestion and slows the arrival of medical service. In the example of Dr. Ada, her location is not available directly to the shelter scheduling system. However, the roadside service has a track on her location via the location of her automobile. If the shelter scheduler makes a request to the alert management system, that connects with the roadside alert policy request system for Dr. Ada's location, the data exchange can be handled by the service and used in the construction of a customized alert.

In this example, Alert Man, the alerting management service, requests the current location of Alice's automobile from the Roadside Companion Policy Enforcement Point. The Policy Enforcement Point will evaluate if Alert Man has the appropriate security clearance to receive the requested data. The XACML request may look like the following:

Figure 11: Request for Location Data
<?xml version="1.0" encoding="utf-8" ?>
<Request
  xmlns="urn:oasis:names:tc:xacml:1.0:context"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context:
  cs-xacml-schema-context-01.xsd">
  <Subject>
    <Attribute
      AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
      DataType="http://www.w3.org/2001/XMLSchema#string">
        <AttributeValue>Shr00244</AttributeValue>
    </Attribute>
    <Attribute
      AttributeId="urn:roadsidecompanion:names:external:
      approvedcontact:identification"
      DataType="http://www.w3.org/2001/XMLSchema#string"
      Issuer="rs435233557">
      <AttributeValue>DM556842224</AttributeValue>
    </Attribute>
    <Attribute
      AttributeId="urn:roadsidecompanion:names:external:
      approvedcontact:passCode"
      DataType="http://www.w3.org/2001/XMLSchema#string"
      Issuer="rs435233557">
      <AttributeValue>O3J9H</AttributeValue>
    </Attribute>
  </Subject>
  <Resource>
    <Attribute
      AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
      DataType="http://www.w3.org/2001/XMLSchema#string">
      <AttributeValue>rs435233557</AttributeValue>
    </Attribute>
  </Resource>
  <Action>
    <Attribute
      AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
      DataType="http://www.w3.org/2001/XMLSchema#string">
      <AttributeValue>getCurrentLocation</AttributeValue>
    </Attribute>
  </Action>
</Request>
        

and the policy applied may look like this:

Figure 12: Policy for Granting Location Data
<?xml version="1.0" encoding="utf-8" ?>
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
  PolicyId="urn:roadsidecompanion:names:external:sendlocation:policy"
  RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:
  rule-combining-algorithm:deny-overrides">
  <Description>
    Evaluate if external Subject has the appropriate security clearance to
    receive the automobile location.
  </Description>
  <Target>
    <Subjects>
      <AnySubject />
    </Subjects>
    <Resources>
      <AnyResource />
    </Resources>
    <Actions>
      <AnyAction />
    </Actions>
  </Target>
  <Rule
    RuleId="urn:roadsidecompanion:names:external:sendlocation:rule"
    Effect="Permit">
    <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:
      and">
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:
        string-equal">
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:
          string-one-and-only">
          <SubjectAttributeDesignator
            AttributeId="urn:roadsidecompanion:names:external:
              approvedcontact:identification"
            DataType="http://www.w3.org/2001/XMLSchema#string" />
        </Apply>
        <Apply FunctionId="urn:roadsidecompansion:names:functions:
          getIdentification">
          <Apply FunctionId="urn:rpadsidecompanion:names:functions:
            getApprovedContact">
            <Apply FunctionId="urn:roadsidecompanion:names:functions:
              getUserProfile">
              <AttributeSelector
                RequestContextPath="//Resource/Attribute/
                  AttributeValue/(value)"
                DataType="urn:roadsidecompanion:name:userProfile:
                  attribute:id" />
            </Apply>
            <SubjectAttributeDesignator
              AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
              DataType="http://www.w3.org/2001/XMLSchema#string" />
          </Apply>
        </Apply>
      </Apply>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:
        string-equal">
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:
          string-one-and-onl5">
          <SubjectAttributeDesignator
            AttributeId="urn:roadsidecompanion:names:external:
              approvedcontact:passCode"
            DataType="http://www.w3.org/2001/XMLSchema#string" />
        </Apply>
        <Apply FunctionId="urn:roadsidecompansion:names:
          functions:getPassCode">
          <Apply FunctionId="urn:rpadsidecompanion:names:functions:
            getApprovedContact">
            <Apply FunctionId="urn:roadsidecompanion:names:
              functions:getUserProfile">
              <AttributeSelector
                RequestContextPath="//Resource/Attribute/
                  AttributeValue/(value)"
                DataType="urn:roadsidecompanion:name:userProfile:attribute:id" />
            </Apply>
            <SubjectAttributeDesignator
              AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
              DataType="http://www.w3.org/2001/XMLSchema#string" />
          </Apply>
        </Apply>
      </Apply>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema
            #string">
            CurrentLocation
          </AttributeValue>
          <Apply FunctionId="urn:roadsidecompansion:names:functions:
            getContextIDs">
            <Apply FunctionId="urn:rpadsidecompanion:names:functions:
              getApprovedContact">
              <Apply FunctionId="urn:roadsidecompanion:names:functions:
                getUserProfile">
                <AttributeSelector
                  RequestContextPath="//Resource/Attribute/
                    AttributeValue/(value)"
                  DataType="urn:roadsidecompanion:name:userProfile:
                    attribute:id" />
              </Apply>
              <SubjectAttributeDesignator
                AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
                DataType="http://www.w3.org/2001/XMLSchema#string" />
            </Apply>
          </Apply>
        </Apply>
      </Apply>
    </Condition>
  </Rule>
</Policy>
        

The desired information can then be used through the alert management service to aid the shelter staff in scheduling and alerting.

Alert Presentation

The alert presentation portion of the Personalized Emergency Alerting System uses an existing information and development architecture that serves as the programming and data processing foundation. This platform is called the Interaction Design System (IDS). The following briefly describes the IDS Communication Requirement and its applicability to construction of presentations for emergency alerting:

"Within IDS, a Communication Requirement is a necessary 'resource' without which a specified Alert cannot be completed and the associated outcome (goal) of the process not achieved. Communication Requirements are described in a raw, information theoretic sense. In particular, no commitment by the Reasoning Engine has yet been made about how they will be presented. Communication Requirements can be met by a potentially wide variety of Presentations, such as: text messaging on a cell phone, screen pop-ups on a personal computer or audio alerts via Public Address Systems. The Requirements are dynamic: they are created in response to a User-Alert pairing being applied in a specific emergency situation. They can be thought of as the container or glue that brings together all the resources needed by the Reasoning Engine." - adapted from IDS project documentation

The information needed by the IDS includes the alerts to be sent, the users to receive the alerts and the rules and policies used to determine the appropriate message content and presentation.

Methods of Alerting

During the terrorist attacks in the United States on 9/11/2001, cell phone service was rapidly overloaded. However, on many systems, text messaging still worked. This may partly be due to less traffic of text messaging in 2001, but the lower message bandwidth and communication protocol still makes it more reliable than audio communication systems.

During the 2002 Australian bush fires, a web server provided information about current fire coverage and generated evacuation route maps. This server was used by both the public and the emergency personnel. The extra burden of public access brought the server down. Steps were taken, outlined earlier in the paper, to keep information available, but the warning of network failure should not be overlooked.

In emergency situations, it may be that text messaging or one of the new emergency alert communication protocols will be one of the few options for alert dissemination. In that case, some of the optimal usability of visual display will be lost.

When users have multiple means of communication receipt, an algorithm is used by the Interaction Design System to ensure that the communication device and presentation arrangement selected meet the usability criteria encoded in the Communications Requirement or come as close as the available communication mechanisms will support.

Since each communication device has a profile defining its capabilities, new devices can be made available simply by providing its capabilities and the service that converts information presentations into the format required by the device and its communication protocol. Therefore, communications via text messaging, e-mail, instant alerts, dashboard displays, and from PDA to large television sized Internet applications display can be used as communication devices when appropriate and available.

More about the selection of presentations can be found in papers on the Interaction Design System.

Presentations to the User

The presentations for the example of the two alerts to the fire fighter hazmat team and the local residents about the same chemical spill emergency could be constructed for a variety of devices.

If the Alerts were sent via text messaging to cell phones, the displays may look something like below. The first alert shown is for the hazmat team.


    --------------------------------
    ALERT from: City Hazmat Office,
    Officer Uri Wold
    To: Hazmat Team: Station 12
    "Take Immediate Action: Railroad
    Ammonia Leak"
     .
                          <more>
    --------------------------------
    .
    --------------------------------
    A train derailed at 13:52 today,
    releasing anhydrous ammonia. The
    site of spill is near railway
    marker 1704 on the North track.
    .
    Instructions: Assistance is
    <back>                <more>
    --------------------------------
    .
    --------------------------------
    Instructions: Assistance is
    needed in hazmat containment.
    Report directly to the site,
    fully suited.  The site can be
    reached via the rail yard access
    road North of the Humbolt
    <back>                <more>
    --------------------------------
    .
    --------------------------------
    road North of the Humbolt
    junction.
    .
    If you have graphical website
    access for a 'Set of wind
    pattern maps' go to "https://met
    <back>                <more>
    --------------------------------
    .
    --------------------------------
    pattern maps' go to "https://met
    eorology.org/reports/2005-05-12/
    0022/"
    .
    .
    .
    <back>                <end>
    --------------------------------

    
And, here is the text-message on a cell phone for the local resident.

    --------------------------------
    ALERT from: City Hazmat Office,
    Officer Uri Wold
    To: Incident Area Residents
    "Take Immediate Action: Railroad
    Ammonia Leak"
    A train derailed at 1:52 this
                      <more>
    --------------------------------
    .
    --------------------------------
    A train derailed at 1:52 this
    afternoon, releasing a hazardous
    chemical near your neighborhood.
    Railroad and City Emergency
    Responders are containing the
    spill.
    <back>                <more>
    --------------------------------
    .
    --------------------------------
    Instructions: If you are home,
    close all windows and turn off
    the heat or air conditioner.
    Move to the most protected part
    of you home and await further
    instructions. Do not leave your
    <back>                <more>
    --------------------------------
    .
    --------------------------------
    instructions. Do not leave your
    home. It is safer inside than in
    a moving vehicle.
.
    If you have graphical website
    access for 'Maps of the affected
    <back>                <more>
    --------------------------------
    .
    --------------------------------
    access for 'Maps of the affected
    area and potential wind
    movement' go to "http://public.m
    eteorology.org/reports/2005-05-1
    2/0022/"
    .
    <back>                <end>
    --------------------------------

    

If the local resident received the alert as a popup message on their computer screen it may appear formatted in this manner:

Figure 13: City Alert Popup Message
[Link to open this graphic in a separate page]

Railroad Chemical Spill Scenario

A train has derailed near the North Rail Yard. Several of its cars contain anhydrous ammonia, a clear, colorless gas that "can attack parts of the body where moisture collects, including the eyes, ears, nose and throat."[Orban] A railroad derailment sensor is triggered and broadcast to the North Rail Yard Office. Shortly, a railroad bio-chemical sensor detects ammonia and broadcasts the information to the North Rail Yard Office. At the office, an automated system sends out pre-designed alerts for each sensor detection to the pre-defined list of recipients.

Figure 14: Railroad Derailment Sensor Triggers Alerts
[Link to open this graphic in a separate page]

Alerts can be constructed automatically from sensor data. The images in Figures 14 and 15 might be part of a screen that shows the alert graphically to the rail yard operators.

Figure 15: Hazmat Sensor Detecting Ammonia Triggers Alerts
[Link to open this graphic in a separate page]

The alerts for the Derailment and Hazmat send messages to Rail Company Groups. These are pre-programmed, but appropriate for each audience. Each group receives the same message header and description.

In the case of the Derailment Alert, the Emergency Response Team Group alert includes instructions to meet at the rail yard office to start the investigation. The Rail Company Management Group is alerted to wait for further instructions, pending an Emergency Response initial investigation.

In the case of the Hazmat Alert, the On-site Personnel Group is alerted to shelter-in-place. The Emergency Response Team Group is alerted to respond to the site and investigate. The Rail Company Management Group is alerted to wait for further instructions, pending an Emergency Response initial investigation. In addition to the Rail Company Groups an outside agency is sent an Alert. Each system is pre-set to accept Alerts from each other via their Common User Alerting Profile. The City Hazmat Department within the City Fire Department receives an alert similar to the internal Rail Company alerts with instructions to report to the site of the incident in full hazmat gear.

The Emergency Response Team Leader receives the alerts as text messages on his cell phone. He immediately realizes that not all Emergency Response Team members are Hazmat trained and constructs an Alert to the Emergency Response Team Group to put non-trained personnel on standby and have the Hazmat Responders come to the site wearing their face-masks. The alert is routed through the North Rail Yard Emergency Alerting System, which verifies the Team Leader's authority to send the alert and the authorization of the Group selected to receive the alert. The Alerts are both marked as Updates of the previous alerts sent by the Automatic System.

The City Hazmat Department alerts other agencies and emergency response organizations within the city of the potential incident. Both the City Hazmat Department and the Railroad Emergency Response Team Lead send alerts to the Satellite Meteorology Station requesting data on the wind conditions. The Meteorology Station Alerting System is able to determine that both requests pertain to the same incident and that the initial location information is likely to be more accurate from the Railroad Emergency Response Team Lead. This allows the Station to run a single analysis and send the response to both requesting parties citing their update as pertaining to both Alert IDs.

The Meteorology Station Update gives basic text information and points to a Resource containing a URL, where special weather maps have been placed. The URL points to a web page that can be displayed in a large browser window with all the images or on a small PDA device with a flip through of the images.

Figure 16: Current Wind Patterns with Hazmat Site marked as a Red Dot
[Link to open this graphic in a separate page]

The overlay of the wind flow was provided by The Weather Underground Inc. located on the web at http://www.wunderground.com/.

Using the weather information provided by satellite and observations by the hazmat crew, a model of the chemical plume over time is constructed. These images can be used as content within alerts or as input to more complex alert construction tools.

Figure 17: Hazmat dispersal after 15 minutes
[Link to open this graphic in a separate page]
Figure 18: Hazmat dispersal after 30 minutes
[Link to open this graphic in a separate page]
Figure 19: Hazmat dispersal after 45 minutes
[Link to open this graphic in a separate page]
Figure 20: Hazmat dispersal after 60 minutes
[Link to open this graphic in a separate page]
Figure 21: Composite of the 1 Hour Spread of Hazmat
[Link to open this graphic in a separate page]

Through out the scenario, the combined railroad and city hazmat teams continue to assess the situation and work to contain the release of anhydrous ammonia. Once the initial assessment is made, the Railroad Emergency Response Team Lead sends alert updates to all appropriate Rail Company Groups and an initial Alert to media organizations who have requested railway alerts. The City Hazmat Department sends alert updates to previously alerted agencies, sends alerts to the city and surrounding city governments, sends a general announcement alert to local media and, for extended personalized alerts to be formulated, sends all pertinent data to the City's Personalized Emergency Alerting System.

The Personalized Emergency Alerting System orders the Alerts based on the level of threat to the subscriber and the amount of time needed by the subscriber to respond (a school takes longer to mobilize than most individuals.) Some subscribers, such as schools, businesses and multiple dwelling housing, will have their own Alerting Systems that will be manually or automatically sending follow-on alerts to their subscribers. The following maps show a subset of the City Subscribers used to show how the trickle down alerting process works and how some subscribers will be given instructions counter to their likely initial response. The effect of the instructions coming from a respected source is often that the subscriber will follow the system's advice and not engage in an unsafe response. The example used in this scenario is a relative who is driving near their child's school and is told that the school is in the process of evacuating the children. The relative is likely to want to find the child at the school, when it is safer for all concerned if they meet the child at the evacuation site.

Figure 22: A Variety of Buildings and Organizations Involved in the Situation
[Link to open this graphic in a separate page]

Some of the icon symbols, such as the school icon and the community center icon are from an "Emergency Symbology Reference" published by the "Homeland Security Working Group" under the "Federal Geographic Data Committee." The "Emergency Symbology Reference" can be found on the web at http://www.fgdc.gov/HSWG/. The other icons were designed by the author for demonstration use in this paper and all were tinted for detection on a color interface. A final set of icons has not yet been established.

The effected homes, schools, businesses and community centers showcased in this scenario are noted on the map. The City's Personalized Emergency Alerting System and the subsequently alerted Organization's Personalized Emergency Alerting Systems will send most messages automatically.

Figure 23: Examples of Schools Effected by the Emergency
[Link to open this graphic in a separate page]

The school nearest the incident is told to shelter-in-place. They are less than 10 minutes from the hazard. The school that has over 30 minutes to respond is told to evacuate students to the Near North Community Center to their South.

Figure 24: Instructions Help User's Decide on Course of Action.
[Link to open this graphic in a separate page]

Alice receives an alert that her grandson, Josh, is sheltered at the Northern Community Center. Instructions are not to pick up the child at the school. Alice needs to get out of the path of the chemical plume herself and let the school do their planned evacuation. By being given explicit instructions, it is more likely that Alice will not show up at the school, which is more of a hindrance to the overall evacuation than a help to either her or her grandson.

Figure 25: Business Building that can Cutout Outside Air Intake
[Link to open this graphic in a separate page]

The large business building houses critical communications businesses and even though it is 30 minutes from the hazard, due to the safe structure of the building and nature of the business, it is instructed to shelter-in-place.

By having businesses that can cut off much of the external air, and shelter-in-place rather than evacuating, helps the city manage the traffic flow leaving the effected area. Certain businesses are critical to maintaining the infrastructure of communications and city life support. These businesses are encouraged to maintain Emergency Safe buildings. When this is not possible and as a backup plan, businesses of this nature are encouraged to have secondary building locations where operations could be quickly brought on line.

Figure 26: The Eldercare System Evacuation Plan
[Link to open this graphic in a separate page]

The Elder Care Facility, "Happy Spires," is alerted to "evacuate all residents, and not to travel North or West as they remove everyone to locations at least 5 miles South of the facility." The Happy Hills chain of Elder Care Facilities already has emergency evacuation plans in place. The residents will be taken to the "Happy Vale" and "Happy Meadows" facilities, both of which are South of the 5 mile requirement. The Happy Hills Personalized Alerting System will Alert all employees and contacts of the residents, letting them know the facility is being evacuated and where the residents are being taken. The alert also instructs that the residents should not be picked-up until an update is sent, thereby, insuring a safe evacuation process.

Figure 27: Alert Received Depends on the Location of the Residence
[Link to open this graphic in a separate page]

Effected residents and those close to the site that can safely evacuate are alerted of the location of the closest emergency shelter. The apartment building just outside the 15 minute chemical plume and within the 30 minute chemical plume (as seen on the maps) may receive an alert with instructions stating the safe evacuation period and preferred routes. Additionally, they are alerted to shelter-in-place if the residents can not evacuate before the safe period ends. This capability is due to strong sense of location and zone changes over time.

Generally, all the inhabitants within a residential area will receive the same information about evacuation and sheltering. Occasionally, there will be special cases within a neighborhood that receive individualized alerts. These will have User Profiles that indicate a resident as having a special condition. One example is that the resident is a block club leader and is requested to check that their block is cleared or sheltered within a certain period of time and send an acknowledgement to the City Hazmat Office. This would be a prearranged roll for that individual.

If the emergency situation changes, alert updates are sent to all effected subscribers. Once the immediate situation is over, alert updates are sent to inform people how they should handle the aftermath of the event. Most widespread emergencies are not over in an instant, but require considerable after-care. This needs to be handled by the alerting system as well as the response to initial situation was handled. However, after the event previously clogged or downed communication channels may be open or users may have access to a better selection of communication devices. This may give the system wider opportunities to construct user-centered alert presentations.

Conclusion

As the terrorist and natural disaster risks of the world are increasing and becoming more violent, the public wants to know that a specific Alert and Warning System exists and is ready to use.

This paper recognizes the void of an existing alerting system and presents a solution to this problem. The need to be able to communicate both with large numbers of people and small groups of specific individuals in a given area concurrently whenever, there is an exposure to any possible variety of extreme hazards is imperative. This allows the overall emergency responses to be carried out more smoothly due to less interference, the easing of concerns of the public involved and ultimately saving lives by faster and more appropriate actions on the part of individuals and organizations using the Personalized Emergency Alerting System.

Central services are responsible not only to coordinate efficiently the responses necessary to control, secure, and serve the effected area but also to keep all involved people and organizations informed. The right people need to know the right information at the right time. The service needs to focus on disseminating accurate information in a timely manner. This will encourage more appropriate responses from people while increasing the expediency of following the given alerting instructions without causing unnecessary distress.

In this paper the use of multiple XML based markup languages was showcased.

  • The Common User Alerting Protocol was used to format information about the users to receive alerts and about other people who may be the context of those alerts.
  • The eXtensible Access Control Markup Language was used both for formations of requests to construct alerts and the policies that determine if the requestor has the rights to have such an alert constructed.
  • The Common Alerting Protocol was used to format the alerts.

In addition, the Interaction Design System used XML, XPath and XSLT behind the scenes to generate the user presentation. These presentations were only shown on a text-messaging cell phone and a web-browser screen popup, but many other communication formats could be generated based on the user's profile.

The Personalized Emergency Alerting System is applicable in many venues and can cross venue or situation. Areas of use may include:

  • Schools - parents, facilities, organizations, districts ...
  • Commercial Office Buildings or Government Facilities - multi-tenanted, organizationally based
  • College Campuses - students, facility, employees, area wide, building specific, public and residential facilities
  • Healthcare or Nursing Facilities - employees, patients and residents, family members
  • Convention Centers and Shopping Malls - stores, center personal, visitors and customers
  • Emergency Service Providers - inter-agency, levels of public announcement
  • ...

There are many practical enhancements to the system to be made. Collaboration with standards bodies, government and protection agencies, other interested companies and individual experts is encouraged.

People want and need to know that they are not only being protected using all available resources, but that a working alert and warning system is in place to help and instruct them when the next tragic event occurs. The technologies presented here can help in meeting those desires.


Bibliography

[CAPFact] CAP Factsheet.dochttp://www.oasis-open.org/committees/download.php/5830/CAP_Factsheet.doc

[CAPXSD] OASIS Common Alerting Protocol 1.0 XML Schema, http://www.oasis-open.org/committees/download.php/4031/cap.xsd

[Orban] Orban, Brian, Tech. Sgt. "Minot experts help fight chemical spill,"Air Combat Command News Service. Jan. 23, 2002.

[PORTAL] "PortalsCommunity - About Categories", http://www.portalscommunity.com/about_categories.cfm

[PPW] Partnership for Public Warning, http://www.partnershipforpublicwarning.org

[Raymond1] Raymond, Michelle, "Concept Paper: Emergency Alerting and Communication", Whitepaper for Emergency Alerting and Communication Program Formation, 2004.

[Raymond2] Raymond, "Interaction Design System Use of XML." XML2001.

[Rollwagen] Conversation with Kristi Rollwagen, Minneapolis Director of Emergency Preparedness, February 04, 2004.

[Worthington] Worthington, Tom. "Dealing with Disaster - Using new Networking Technology for Emergency Coordination"http://www.tomw.net.au/2003/enet.html

[XACML] OASIS eXtensible Access Control Markup Language TC, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml



(WIRLED PEAS)

Michelle Raymond [Senior Research Scientist, Honeywell Automation and Control Solutions, Knowledge Services Labs]
michelle.raymond@honeywell.com