Hazard Warnings in Sri Lanka: Challenges of Implementing CAP


Posted on February 15, 2007  /  5 Comments

There is a growing call for the use of open source content standards for all-hazards, all-media alert and notification systems. Content standards such as Common Alerting Protocol (CAP), Emergency Data Exchange Language (EDXL) and others promise to improve the interoperatiblity of hazard information systems at both the internetworking and last-mile stages of distribution. Despite the promise that these standards hold for improved disaster management, there is limited understanding of specific implementation issues and challenges associated with the use of content standards for last-mile alert and notification system. This is especially the case in developing countries, such as Sri Lanka, where community-based hazard information systems are being introduced to complement and extend the functionality of national and regional systems.

The Discoveries and Breakthroughs in Science report on “New Disaster Warning Standards” provide the true features of CAP. However, fails to realize that the CAP standard was developed in the English Speaking Countries and has only been tested in those developed countries. The standard does give provision to issue warnings in multiple languages by creating a new “info” section for each language; where the info section is a subelement of the CAP Message. CAP still requires testing over a multiple array of ICT devices that can be used in a last-mile with language localized alerting applications before it is concluded as a “universal standard”.

CAP is being deployed as part of the HazInfo project, which has established last-mile networking capability for 32 tsunami-affected Sarvodaya embeded villages in Sri Lanka in order to study the suitability of various Information Communication Technologies (ICTs) for a standards-based community hazard information system. A major component of the HazInfo Project is the use of the Common Alerting Protocol to enable data interchange between the Hazard Information Hub (HIH) and a range of end-user technologies. CAP is a simple, flexible data interchange format designed for collecting and distributing “all-hazard” safety notifications and emergency warnings over information networks and public alerting systems.

“Evaluating Last-Mile Hazard Information Dissemination: A Research Project”, also referred to as the “HazInfo Project” was launched in December 2005 and is being tested in the Sarvodaya embedded Coastal Districts of Sri Lanka. The research project is funded by the International Development Research Center of Canada (IDRC). The research findings from the simulated tests and exercises of the 5ICTs and Processes will provide a guide to implementing an early warning system for the next 1000 Grama Swaraja villages.
CAP as a content standard is deliberately designed to be transport-neutral. 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 provides compatibility with all kinds of information and public alerting systems, including those designed for multilingual and special-needs populations. Further, CAP incorporates geospatial elements to permit flexible but precise geographic targeting of alerts. CAP also provides for associating digital images and other binary information with alerts and supports various mechanisms for ensuring message authenticity, integrity and confidentiality where required.

CAP was integrated into the project because of the following perceived benefits and advantages:

  • Since it is an open source, XML-based protocol with clearly defined elements, CAP should be capable of supporting data interchange across multiple dissemination channels.
  • With CAP, one input at the central information hub can be translated into multiple outputs for downstream alerting.
  • CAP provides a standardized template for submitting observations to the central hub (upstream) and thereby supports situational awareness to improve overall management of a critical incident.
  • A CAP-enabled system will more easily integrate with other national and international information systems.

Results to date suggest that the basic internetworking arrangement at lower technical layers has proven to be reasonably robust and reliable but that a key challenge remains in the upper layers of application software and content provision. This is evident in the apparent difficulties faced when implementing CAP messaging over multiple last-mile systems that include commercial satellite and terrestrial network technologies .

Lessons learned from silent-tests and live-exercises points to several key bottlenecks in the system where the integrity of CAP messages is compromised due to problems associated with software interoperability or direct human intervention. The wider implication of this finding is that content standards by themselves are not sufficient to support appropriate and timely emergency response activities. Those working with content standards for hazard information systems must consider closely the interoperability issues at various layers of interconnectivity.

Designers: Botrel et al of CAP have given the message recipients full autonomy to take action based on the information they receive. It is expected that the community has an Emergency Response Plan (ERP) that is executed on the basis of the content in the CAP message. Therefore, it is important to avoid ambiguity in the alerts; example: if the message indicates that the particular community is absolutely at no threat then the community ERP will be to record/acknowledge message only and do not relay any further (i.e. terminate event).

Global Organizations such as United States Geological Survey (USGS) that issue CAP messages, to this day, use the OASIS CAP version 1.0 and not version 1.1, which was released by OASIS in October 2005. HazInfo Project has been testing with the latest version 1.1 and has difficulty automatically importing the USGS Messages in to the CAP readers used in the project because of the mismatch in the Document Object Model (DOM).

5 Comments


  1. Great to see that the implementation is well reaching its end. Are there a STD(state transition diagrams)? for the CAP? Having the messaging done using XML standard’s pretty good paving way to more possibilites. I guess you will also be running WS’s for this project so other applications can be based on it.

  2. Let’s say the Sarvodaya Hazard Information Hub (HIH) wants to notify the Batticaloa, Ampara, and Hambantota District Coordinators via SMS that there is a possible threat of a mini-cyclone in those 3 Districts. Therefore, interface must work in Sinhala, Tamil, and English. Since we use off-the-shelf market solution, there is a need for a “broker” type messaging software module that can plug in to the gateways of any communications service provider in the world.

    Dialog Telekom and Microimage Private Limited in Sri Lanka has developed a GSM alerting system: Disaster Erly Warninig Network (DEWN) for both fixed and mobile devices; with some limitations that they are based on symbian GSM chipsets. The Microimage developed CAP SMS Messaging module is capable of sending SMS Alerts in Sinahala, Tamil, & English. The message displayed on Mobile Phone screen is limited to 2 of the CAP element — and . The best part in the SMS messaging is recieving an automatic acknowledgement, namely SMS message back to the SMSC confirming delivery of packets to device. The ANNY Network of the WorldSpace Disaster Warning, Recovery and Response (DWRR) is the only solution in the project that could accept, deliver, and display a Full-CAP message (i.e. all XML tags). However, the message is not complete becasue the message is only in English. The Innovative Technologies — Very Small Aperture Terminal (VSAT) and Solana Networks — Internet Public Alerting System (IPAS) solution works independently from any communication infrastructure in Sri Lanka becasue the VSAT connects directly with Singapore and bypass the local backbones and sea-cable. This VSAT is also catalyst to making the WorldSpace system independent of local communication infrastructure. Unlike the WorldSpace addressable satellite radios that can operate on solar charged 7v batteries the heavy expensive infrastructure based VSATs require computers/routers/skilled-labor. That doesn’t mean we can absolutely do without them.

    I am also introducing Peter Anderson, a world-recognized expert in the use of information and communication technologies in disaster preparedness and management, is spending some time during his sabbatical leave from the Telematics Research Lab, Simon Fraser University, as a visiting scholar at LIRNEasia . Professor Anderson arrived in Sri Lanka on 12 February 2007 accompanied by his wife Marcia Anderson. He is spending time at the Sarvodaya HIH analysing and providing expert advise on the system. Part of his effort will be to implent an opensource solutions such as the Sahana Messaging Module to complete the CAP alerting requirement at the Hub. Sahan already has a CAP messaging module they developed for the Sarvodaya HIH. The objective of the effort was to to develop a series of templates in the local languages. Use the tool to validate their “CAP-Profile” for the Last-Mile Hazard Warning System (LM-HWS).

  3. Nuwan, the lead author of CAP is Art Botterell (misspelt in your post) but it has been a collective effort by some 130 experts in emergency management working in conjunction with the Partnership for Public Warning.

    CAP is an open source standard, so changes will continue over time. The HazInfo Project offers an important opportunity to provide input to this dynamic development process.

    It might also serve as a catalyst for a regional coordination of CAP implementation among various governments, industry and community groups that are seeking to build on each other’s strengths in creating a robust and reliable alert and notification system based on horizontal linkages between stakeholder groups.

    Lanka Software Foundation’s work on Sahana, including the CAP module they’ve added, is another important contribution that Sri Lanka is making in this area:
    http://www.sahana.lk/

  4. Gordon, Thanks for making the correction. I agree that the HazInfo project should implant the knowledge; i.e. lessons learned, in this Open Source efforts to develop the Messaging Module. The following link — http://www.reliefsource.org/foss/index.php/Req:alerts is the Wiki to the Sahana Messaging Module requirements database. I hope members of the PPW etc could also contribute to defining the set of requirements.

  5. Hi Nuwan,

    I’m graduating this june and will be coming to SL. Let me know if you require any help.

    regards
    Janantha