Pilot Implementations of CAP in DOI

Document Sample
Pilot Implementations of CAP in DOI Powered By Docstoc
					World Meteorological Organization (WMO)
   Observing and Information Systems Department
          WMO Information System (WIS)




          Identifiers and the
           Common Alerting
            Protocol (CAP)

              Presented 23 June 2009 at
            Joint Meeting of MeteoAlarm
                      and the
   WIS CAP Implementation Workshop on Identifiers
       by Eliot Christian <echristian@wmo.int>
                      Outline

            What is CAP?
            Why and How would
             MeteoAlarm use CAP?
            What are the issues with
             Identifiers?



June 23, 2009   Common Alerting Protocol (CAP)   2
                What is CAP?
 The Common Alerting Protocol (CAP) is a standard
 message format designed for All-Media, All-Hazard,
 communications:
   over any and all media (television, radio, telephone,
   fax, highway signs, e-mail, Web sites, RSS "Blogs", ...)
   about any and all kinds of hazard (Weather, Fires,
   Earthquakes, Volcanoes, Landslides, Child Abductions,
   Disease Outbreaks, Air Quality Warnings, Beach
   Closings, Transportation Problems, Power Outages, ...)
   to anyone: the public at large; designated groups
   (civic authority, responders, etc.); specific people

June 23, 2009    Common Alerting Protocol (CAP)           3
      Structure of a CAP Alert
   CAP Alert messages contain:
    Text values for human
     readers, e.g., "headline",
     "description", "instruction",
     "area description", etc.
    Coded values useful for
     filtering, routing, and
     automated translation
     to human languages




June 23, 2009     Common Alerting Protocol (CAP)   4
            Filtering and Routing Criteria

                 Date/Time
                 Geographic Area
                 (polygon, circle, geographic codes)
                 Status
                 (Actual, Exercise, System, Test)
                 Scope
                 (Public, Restricted, Private)
                 Type
                 (Alert, Update, Cancel, Ack, Error)



June 23, 2009        Common Alerting Protocol (CAP)    5
            Filtering and Routing Criteria

      Event Categories
        (Geo, Met, Safety, Security, Rescue,
        Fire, Health, Env, Transport, Infra, Other)
      Urgency: Timeframe for responsive action
        (Immediate, Expected, Future, Past, Unknown)
      Severity: Level of threat to life or property
        (Extreme, Severe, Moderate, Minor, Unknown)
      Certainty: Probability of occurrence
        (Very Likely, Likely, Possible, Unlikely, Unknown)



June 23, 2009     Common Alerting Protocol (CAP)             6
       Typical CAP-based Alerting System




June 23, 2009   Common Alerting Protocol (CAP)   7
http://www.weather.gov/alerts
                The CAP Standard (X.1303)

         Compatible with legacy as well as newer
          transports (WMO messages, news wires,
          digital TV, Web Services, ...)
         Flexible geographic targeting
         Phased and delayed effective time, expiration
         Message update and cancellation features
         May include inline digital images and audio
         Approved by OASIS as Version 1.1 (2005)
         Adopted as ITU Recommendation X.1303 (2006)
         Significant uptake, many implementations

June 23, 2009      Common Alerting Protocol (CAP)         9
                ITU Resolution 136


    "The Plenipotentiary Conference [...] resolves
    to instruct the Directors of the Bureaux [...]
    to promote implementation by appropriate
    alerting authorities of the international content
    standard for all-media public warning,
    in concert with ongoing development of
    guidelines by all ITU Sectors for application
    to all disaster and emergency situations"



June 23, 2009   Common Alerting Protocol (CAP)      10
  U.S. Federal Communications Commission

     "Washington, D.C. - The Federal Communications
     Commission today adopted [an Order that] requires
     [Emergency Alert System (EAS)] participants to accept
     messages using Common Alerting Protocol (CAP) [...]
     The use of CAP will help to ensure the efficient and rapid
     transmission of EAS alerts [...] in a variety of formats
     (including text, audio and video) and via different means
     (broadcast, cable, satellite, and other networks) [...]
     In addition, the Order expands the EAS system by requiring
     participation by wireline video providers."



June 23, 2009       Common Alerting Protocol (CAP)                11
         World Meteorological Organization

  WMO Congress (2007) requested Secretary-General
   to improve the exchange of high priority data and
   products in support of a virtual all hazards network
  WMO Executive Council (2008) requested Commission
   for Basic Systems to follow up on CAP implementation
   as a matter of urgency
  WMO Executive Council (2009) asked the Secretariat,
   and invited all Members and Regional Associations,
   to spare no efforts in ensuring that the implementation
   of CAP benefits all user communities


June 23, 2009    Common Alerting Protocol (CAP)          12
                      Outline

            What is CAP?
            Why and How would
             MeteoAlarm use CAP?
            What are the issues
             with Identifiers?


June 23, 2009   Common Alerting Protocol (CAP)   13
        Why would MeteoAlarm Use CAP?

     Convergence on common standards makes any
      warning system more effective and efficient
     MeteoAlarm CAP messages would be more easily
      processed by software that handles CAP already
     Immediate Benefit: enhanced dissemination of
      MeteoAlarm messages
     Longer-term Benefit: Easier integration of
      MeteoAlarm with newer systems that use CAP




June 23, 2009   Common Alerting Protocol (CAP)         14
           How would MeteoAlarm Use CAP?
          A message in CAP format could be generated
           automatically for each MeteoAlarm message,
           in a way similar to the following DWD example
DWD Schema                        CAP Schema                   Notes

//warnings@issued                                              date-time & source for multiple alerts,
//warnings@src                                                 useful for RSS Channel of CAP alerts
//warnings/area@class+" "         //alert/info/headline        the event type and criticality should be
+//warnings/area@id               //alert/info/areaDesc        indicated in the headline

//warnings/area/altitude@bottom   //alert/info/area/altitude   Covert altitude between meters and
//warnings/area/altitude@tops     //alert/info/area/ceiling    feet
//warnings/area/altitude@unit
//warnings/area/warn@crit         //alert/info/responseType    generate the CAP element values
//warnings/area/warn@maxLevel     //alert/info/urgency         based on DWD "crit" and "maxLevel"
                                  //alert/info/severity        attribute values
                                  //alert/info/certainty
                                  //alert/info/instruction

//warnings/area/warn@src          //alert/identifier           generate the CAP element values
                                  //alert/info/sender          from a look-up table using the DWD
                                  //alert/info/senderName      "src" attribute value
                                  //alert/info/contact
                    Crosswalk of CAP and DWD
DWD Schema                        CAP Schema                     Notes
//warnings/area/warn@issued       //alert/sent                   UTC, using "issued" and "tz" attributes
//warnings/area/warn@valid        //alert/info/onset             UTC using "valid" and "tz" attributes
                                  //alert/info/expires
//warnings/area/warn@tz
//warnings/area/warn/gewitter     //alert/info/event             look-up using "gewitter" and "level"
//warnings/area/warn/wind@level   //alert/info/parameter/        Example CAP parameter:
//warnings/area/warn/                  valueName                 <valueName>wind level</valueName>
                wind@lowValue     //alert/info/parameter/value   <value>1</value>
//warnings/area/warn/wind@unit
//warnings/area/warn/text@lan     //alert/info/language          use value as it is
//warnings/area/warn/text         //alert/info/description       use value as it is
                                  //alert/status                 value "Actual"
                                  //alert/msgType                value "Alert"
                                  //alert/scope                  value "Public"
                                  //alert/info/category          value "Met"
                                  //alert/info/area/polygon      generate CAP element values from a
                                  //alert/info/area/geocode/     look-up table using the DWD area
                                               value             "class" and "id" attribute values
                      Outline

            What is CAP?
            Why and How would
             MeteoAlarm use CAP?
            What are the issues
             with Identifiers?


June 23, 2009   Common Alerting Protocol (CAP)   17
      What are the Issues with Identifiers?

 A few CAP elements allow free text
   (unconstrained values) for identifiers, BUT:
  Some identifiers are harder to communicate
    (e.g., UUID with 32 hexadecimal characters,
      550e84ac-e29b-41d4-a716-446655448732 )
  Harmonized identifiers could enhance the
   common understanding of message contents
  Harmonized identifiers are useful for
   aggregating across systems and over time

June 23, 2009   Common Alerting Protocol (CAP)    18
         The CAP Workshop on Identifiers

 As input to the relevant OASIS and ITU committees,
   the CAP Implementation Workshop on Identifiers is
   developing a Draft "Implementors Note" concerning:
  general requirements such as simplicity, usability,
   flexibility, extensibility, scalability, and deployability
  considerations about distributed versus centralized
   management approaches of various identifier schemes
  considerations about long-term reliability of identifier
   registrars, and the availability of high-performance
   tools for discovering attributes of any given identifier
  suggestions on some specific CAP identifiers

June 23, 2009     Common Alerting Protocol (CAP)            19
          Likely Suggestions on Identifiers


Different alerting authorities and carriers using
  CAP operationally could harmonize identifiers of:
 particular CAP messages
  e.g., 2.29.0.840.1.57.2009-06-22T23:56:38-04:00 =
   alert for Butler county, Alabama, 22 June at 11:56:38
 alerting authorities (organizations and policies)
  e.g., 2.29.1.840 = United States National Weather Service
 particular hazard threats/events
  e.g., 2.29.2.GLIDE.TC-2009-000118-MEX =
    GLIDE identifier for tropical storm Andres, in Mexico

June 23, 2009     Common Alerting Protocol (CAP)            20
            MeteoAlarm input
            on these matters
                would be
             Very Welcome!

June 23, 2009   Common Alerting Protocol (CAP)   21
                   References

  CAP "flyer"
     http://www.wmo.int/pages/prog/www/ISS/Meetings/
     WIS-CAP_Geneva2008/flyer2008.doc
  CAP Implementation Workshop on Identifiers
     http://www.wmo.int/pages/prog/www/ISS/Meetings/
     WIS-CAP_Geneva2009/DocPlan.html
  OASIS Emergency Management TC
     http://www.oasis-open.org/committees/emergency
  Contact Eliot Christian <echristian@wmo.int>


June 23, 2009   Common Alerting Protocol (CAP)        22

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:3/31/2011
language:English
pages:22