tornado_shelterOften people are misconstrued by alert messages and act inappropriately because they have not fully understood the message; especially, when they are short-text messages with partial information. There are many challenges with cognition, or understanding, of public warning messages. UNESCO estimates, on average, 30% of South/West Asians and Sub-Saharan Africans to be illiterate. Those countries combined account for ~40% of the world’s population.

World Bank tourism statistics have estimated over 955 million departures over the past 4 years (2008-2012) and the numbers to rise to 1.6 billion per annum by 2020. Could a Chinese tourist in USA, or any other person alien to English for that matter, understand a rapid-onset Tornado warning text-message?

Studies show that every country in the world is home to more than one language; on average 6 languages, according to recent studies by Ethnologist. In most cases it is above 50, if we consider regions such as Europe, Asia, and Central Africa. Addressing alerts in each language is cumbersome. Although the Common Alerting Protocol (CAP) content standard allows for carrying a message in multiple languages, delivering them in each language overwhelms the communications networks.

“Symbols in Alerting” was the basis of my talk at the 6th Common Alerting Protocol Implementation Workshop that took place in Geneva, Switzerland (23-25 April 2013). There were seventy participants (70) from thirty severn (37) countries representing and several International organizations, Sahana Software Foundation was one of them.

CLICK TO READ THE FULL REPORT

It is best to focus on “symbols in alerting for mobiles”. The challenges are in addressing all makes and brands. They typically vary between iOS, Android, Windows, Symbian, so on and so forth. The most effective way may be to host a small applet along with the pictograms in the mobile phone memory. Thereafter, trigger the appropriate pictogram using CAP message for display. A customizable generic applet can be developed. Cellular Operators can adopt the applet, then customize it for the country-context, based on the country CAP-profile. The customized applet can be deliver, over the air, to the subscribers. Thereafter, the subscriber could further customize as to which alerts they would like to see and at what threat levels. The symbol-based alerts on the mobile can be triggered using Cell-broadcast, SMS, or HTTPS (REST-ful) strings.

Symbols are indeed effective provided they carry both the hazard and the required response action. Colours and Numbers are a good way to present the priority (or the severity, certainty, and urgency) of the message. The common consensus of the workshop participants was that “symbols in alerting” is important and some initiatives must be exercised to research and develop a framework that is in in-line with the CAP standard. It may take time to understand the functional requirements, design parameters, and the process variables.

Recently, in Geneva, I met Massimo Cristaldi (CTO  Intelligence for Environment & Security – IES -  Solutions) at the CAP Implementation Workshop (23-25 April 2013). He mentioned, during a tea-break chat, that they evaluated the Sahana-Eden CAP Broker for possible adoption. Given that the Sahana-Eden CAP Broker was not fully developed, they default to building their own. Moreover, he was not at liberty to say whether or not they adopted parts or the existing version in their build; my hunch is that they did. This is an initiative driven by Italians for the European Union. I was thirlled to learn that the Sahana-Eden CAP Broker was, quietly, gaining some traction; especially, it being developed by students through GSOC and GCI programs.

IES developed “JIXEL” is a suite of web based application that allows emergency services (fire and rescue, ambulance, police, civil protection) to seamlessly exchange information during day-by-day operations and when managing catastrophic events and their aftermath. JIXEL adopts CAP as the interoperable content exchange protocol. In addition to the software products, JIXEL also focuses on hardware for rapid routing and sharing of crisis information.

Possibly, the Sahana Software Foundation’s EUROSHA project could find synergies in collaborating with IES Solutions in complementing their efforts by offering some of the available modules in managing European humanitarian crises.

 

GCI-GSOC Continuum

GCI-GSOC Continuum

The cycle continues as we look forward to GSOC 2013; already announced. Any interest or suggestions for GSOC-2013 in relation to the Sahana Eden CAP Broker? TALK TO US.

This is simply one of may Sahana modules/projects that continues to evolve through the contributions of GSOC and GCI student. My Sahana colleagues would agree. Thank you Google!

The International Telecommunications Union – Disaster (ITU-D) division recruited me to introduce ways in which the Common Alerting Protocol (CAP) interoperable emergency communication standard could be operationalized in the Asia Pacific region. The audience comprised member state delegates from their respective telecommunications regulatory authorities and their emergency operations centres (or disaster management centres). The workshop: “Use of Telecomunications/ICT for Disaster Management” took place in Bangkok, Thailand; 20-23 December 2012.

The Sahana CAP- enabled Messaging Broker software was put in to practice to simulate both inter- jurisdictional (between agencies) and intra-jurisdictional (within the agency) as well as direct (from system to human recipient) and cascade (i.e. Agency-A send message to Agency-B’s system, then Agency-B alerts its subscribers) alerting procedures. Enforcing the standard through a software removes the perceived technical complexities; otherwise seen cumbersome for National emergency communication policy-makers to comprehend.

Following the hands-on exercises, the delegates engaged in a SWOT analysis to evaluate their experience with CAP and the CAP-enabled Sahana software; especially, considering the utility and adaptability if they were to  institutionalize it in their own country.

Clik here to read the ITU-D workshop session 8 CAP report

The slides: “Introduction to Operationalizing CAP

The final report that came out of the Common Alerting Protocol (CAP) Policy Workshop in Montreal quoted Sahana in it. Here’s an excerpt from the report:

How to notify and utilize citizen volunteers
Community volunteers [e.g. Community Emergency Response Teams (CERT)] are increasingly seen as valuable resources to respond in emergencies. New tools and channels may need to be used by alerting authorities to be able to include trained citizen volunteers in alerts sent to responders (see Sahana Software Foundation). Also, citizen volunteers can be utilized to rapidly gather information on the status of hazards and disasters as well as the resources needed

I addition to our work with CAP the Eden team has been working on the CERT module. Perhaps one area to explore is combining CERT messaging component with CAP as an underlying standard. As I take on the role of Chair of the Sahana Standards and Interoperability Committee, investigating such needs to interchange information with disparate systems and then contributing that knowledge to the OASIS Emergency Interoperability Technical Committee, which Sahana Software Foundation is now officially a member, shall become a priority.

After watching the video, please take a few minutes to complete this questionnaire (there are only three simple questions to answer). You may scroll to the bottom to access the questionnaire; else click here. Thank you in advance.

With the spread of affordable telecom services, most Asians now use their own phones to stay connected. Can talking on the phone help those responding to emergencies to be better organised? How can voice be used more efficiently in alerting and reporting about disasters? Where can computer technology make a difference in crisis management?

These questions were investigated in an action research project by LIRNEasia in partnership with Sarvodaya, Sri Lanka’s largest development organisation. Experimenting with Sahana disaster management software and Freedom Fone interactive voice response system, it probed how voice-based reporting can fit into globally accepted standards for sharing emergency data. It found that while the technology isn’t perfect yet, there is much potential.

The LIRNEasia and Sarvodaya conducted feasibility study to integrate the Freedom Fone Interactive Voice Response (IVR) System with the Sahana Disaster Management System was presented at the Communicating with Disaster Affected Communities (CDAC) technology fair. The congregation took place in London, UK, March 22 & 23.

Brenda Burrell (Technical Director Freedom Fone), residing in Harare and I in Kunming, were invited with very short notice and couldn’t acquire visas to UK on time. However, our colleague in Oxford Fran Boon (Sahana Software Foundation) was able to fill our shoes given that he was already attending and presenting at the conference. Click to view the slides used to ignite the crisis management relevant message.

Fran Boon, presenting the Sahana Eden prospective of the case study, highlighted the key message: “Sahana Eden should become the single front-facing application for users and this should talk to the IVR via application programming interfaces (APIs). The APIs should allow for dynamic real-time interfacing with all functions: structuring menus, uploading audio files to the menu tree nodes, accessing “leave-a-message” audio files, and controlling outbound dialling. The Freedom Fone and Sahana Eden communities are currently discussing how this could be done.”

Fran Boon presents Freedom Fone Ignite talk at CDAC

In the Freedom Fone version of the case study, Brenda elaborates: “The lessons to date are promising for integrating voice for emergency communication; especially to bridge the last-mile with incident management hubs. Moreover, it is a particularly effective way to enable ICTs for low computer literate non-English working language community-based disaster management organizations in developing countries. Sahana Foundation and Freedom Fone are keen to pursue the integration of the two platforms. If successful, this would position the integrated voice-enabled disaster communication system, for wider adoption, especially, with community-based emergency management and response organisations.”

Once again Sahana participated in 2011 Google Code-In. Happy to have been part of it mentoring students. A big thrill was that they worked on the few research tasks that were related to the Common Alerting Protocol (CAP) Broker. The two main tasks were:

  1. develop a blueprint with wireframe to port the Sahana Agasti CAP Broker to Sahana Eden (because Sahana Agasti CAP Broker is no longer supported by the community; moreover, the new version that will be built in to Eden would build on the lessons learned and improve the shortcomings from the piece-wise build original version)
  2. develop a wireframe to build an XSL Editor (mainly to develop XSL files to transform full CAP messages to deliver through short-text, long-text, and voice-text messages through email, SMS, IVR, Twitter, etc)

The CAP Broker is a tool that I have been researching on and developing over the past six years. The real need of a CAP Broker is in early warning. Based on the systems definition for early warning system, it requires a Broker to acts as a messaging pivot between those who publish alerts/warnings and those who subscribe to them.

The first works were with the HazInfo project, when we tested various wireless technologies for their ability to carry CAP messages to last-mile communities. There was an opportunity to further develop and test it for cyclones and hurricanes but we failed to win the hearts of NSA to nail the grant. There was also interest to build the libraries and test components that would carry CAP messages over Radio Data Systems; however, could not secure any funding to try this as well.

What we did achieve was testing CAP over HF data platform. The first working Sahana CAP broker was tested for health alerting with delivery over HTTP, Email, SMS, and RSS. Then recently, the field testing of CAP messages disseminated through an IVR.

STANDBY … There’s more work to be done and shared.