Live feed: Colloquium on A Common Alerting Protocol Message Relay

Posted on June 15, 2006  /  1 Comments

Nuwan Waidyanatha – Project Manager, Last Mile Hazard Warning System

The socioeconomic belief is that a CAP message relay is one way of effectively managing disasters, and that is what is envisioned in the Last-Mile Hazard Warning System (LM-HWS) Pilot Project. I will be talking about the current Workpackage of the LM-HWS project, which is developing the Hazard Information Hub (HIH). The general objective of the LM-HWS project is to evaluate the suitability of a selected set of ICT that can communicate CAP messages and alert the village first-responders. The Sarvodaya HIH was specifically built with the intension of providing structured risk information such as CAP messages to the local communities.

The objective of the project is to find optimal ICTs for issuing the last mile warnings in Sri Lanka, which can be extended to other developing countries. It is a community-based last-mile warning system, being tried out in a selection of Sarvodaya’s villages ( in Sri Lanka.

Different technologies will be tested in 32 of Sarvodaya’s Tsunami-affected villages; some are ‘organised,’ some are ‘less organised’ and some have received training, and some have not.

Five kinds of ICTs have been selected in this experiment:

1. Dialog Early Warning Network Remote Alarm Device Dialog Telekom & University of Moratuwa, SL)

2. Sinhala/Tamil SMS with alarm for Java compatible phones (Dialog Telekom & MicroImage)

3. Internet Emergency Public Alerting System (IPAS) with pop-up message (Solana Networks)

4.Disaster Warning Recovery and Response Addressable Satellite Radio (WorldSpace Global Data Solutions)

5. Fixed phone

All of these devices will function if they’re in standby mode when an alert is received. But, sirens will be set off in the case of 1, 2, 3 and 4. Conventional warning relies on TV and radio, which will if switched off, will be of no use.

Sarvodaya has a hazard informaiton hub, where hazard information is collected, and relayed out to the villages.

Common Alerting Protocol, cutting edge software, is being used in the project. By using CAP, large amounts of information can be relayed, in a standardised manner, which can be relayed to the village level.

A key issue is how to make it (CAP) effective , how to make it readble, in Sinhala and Tamil. Have a language tanslator on SAHANA. it makes use of standardised phrases that replace the english text. Once edited, the message has to be relayed. The CAP message can be translated into voice (developing this feature). A configurator informs ‘teleporters’ (e.g Dialog Telekom) which areas to alert.

Info is received from various agents (eg govt). an alert is received, then it is authenticated (with paper trail). CAP message is generated in software at the same time. But only after approval is recieved from Sarvodaya, the message is relayed to the relavant villages. Phone logs can be incorporated for reduncancy.

And now a live demonstration of IPAS by Solana…..

With some intro from Nabil Seddigh, Rupinder Singh, Dr. Gordon Gow and Biswajit Nandy (in Ottawa, via Skype): Solana has carried out field trials for public alerting using Television, the Internet and Telephone Dialers.
Users subscribe to receive certain alerts, they can choose the geographical area for alerts, the alert type (public security, health, etc), and the severity of the alert.

IPAS (internet emergency public alerting system) consists of alert servers (responsible for sending out alerts), public alert client software (resides on computer of end users), public official web portal (to issue alerts) and system admin tools.

This system was trialed three times – first in July 2004, then in November 2004 and finally in February 2005. The key objectives of the trials were to assess technology, to get feedback from public officials, and to get feedback from end users on the usability of the system. Seven Canadian municipalities participated, and included a diverse group of users (students, municipal staff, general public, officials, etc).

1 Comment

  1. I wanted to share some work in progress on above for people who have interest in this project/initiative,

    Let me do a quick breif of DEWN (Disaster and Early Warnning Network) which involves an advance middleware which has integration to SMSC/CBE, Multilingual mobile phone application which works as a alarm device and Alarm Box (GSM enabled equipment) capabale of listening to SMS/CB and trigger and alarm.

    The latest addition to this DEWN middleware is supporting CAP which is the standard established for this purpose. At the time DEWN project kicked off which was last year and the time we completed we didnt have much information and partners to try out CAP hence had to develop the solution based on our own message dissemination mechanism.

    However, with lirnasia initiative the CAP came into picture and what’s done now is that the DEWN – Middleware is CAP compliant where the message originator can dispatch/trigger a CAP message to DEWN middleware. Upon receiving the CAP message it will trigger the DEWN application to authorize and dispatch the message to phones and alarm boxes. In this process for extra security and since we are doing a pilot we have allowed DEWN-Admin to authorize the CAP and trigger the message. The received message will be in English and press of button it will be immediately transffered to the DEWN message dissemination console and the respective Admin can dispatch thereafter. At present CAP message comes in English and dynamic online translation is not there for the moment, however the DEWN-Admin can do a quick typo in the respective Sinhala/Tamil message box and dispatch the message.

    Importnat thing is to implement this as per the plans and try out pilot and be prepared for any emergency warnning dissemination through this system. And the online translation to other 2 languages should be done either on the CAP itself or through the middleware application of DEWN. It would be great if the CAP itself can be sent in all 3 languages as they are the originator of the message. I am sure the options 1,2,3,4,5 should be put into practice as we dont have anything now if a warnning has to be given tomorrow.