Sahana First Response Prototype is Ready

There is a global increase in climate-related, anthropological, and technological disasters. information communication technology has proven to reduce the complexities of managing multiple situations, improve the incident response efficiencies, and promote accountability. The Sahana First Response (SaFiRe) enterprise solution, along with its mobile applications, can be combined to manage the location and situation specific information exchange.

SaFiRe is designed to support a Simple All-Hazard Emergency Operation Center (EOC); especially during the 72 hour golden window. An EOC might utilize SaFiRe for managing simple incidents like burglary, accident, dispute. The response and resources dispatched to an incident varies upon the scenario. An extreme event such as an earthquake, with many casualties, damages, and losses would require managing a large volume of response activities. All these, whether big or small, require managing a series of response actions (or inactions) and sharing information with a Multi-Agency Coordination System (MACS).

A SaFiRe prototype was developed to test the various scenarios and context drawn from several experiences. The code is available as a Sahana Template in the Eden repository. We will continue to imprve SaFiRe. It would be most effective with an actual implementation, although the prototype can be demonstrated for ICS requirements.

Introducing the Sahana CAP-enabled Messaging Broker to ITU-D Asia Pacific Community

-->

The International Telecommunications Union - Disaster (ITU-D) conducted workshop in Thailand, introduced the utility of the Common Alerting Protocol (CAP) standard, to the delegates, through a the Sahana CAP-enabled software and a series of hands-on exercises. The CAP ease-of-use and utility were appreciated by those delegates. Participants experienced the efficiency gains of the single entry of a message being simultaneously disseminated through multiple technologies to multiple recipients, acknowledged the CAP message consistency removing ambiguity that may, otherwise, lead to false responses, and realized the capabilities of brokering multi-agency publishers and subscribers for improved situational-awareness^.
 

ITU-D hosted a session on the topic: “Introduction to Operationalizing the Common Alerting Protocol” at the workshop: “Use of Telecommunications/ICT for Disaster Management¹”. This hands-on CAP session was resourceful in producing positive outcomes. Delegates had the opportunity to assess the capabilities of the standard using the CAP-enabled Sahana broker software.

Click to view the workshop report available on the web and the slide deck .

Evidence points to the growing need for a CAP-enabled ITU-D Module (CAP-ITUM). The CAP-ITUM would foster the wider-scale adoption of the the CAP standard and the policies it offers. The ITU branded module would advance the member states, lagging in implementing CAP, with facilitating multi-agency all-hazards all-media warning, alerting, and situational-awareness capabilities, to effectively coordinate hazard events. Since the first release of CAP in 2005, only a handful of member states: North America, Australia, and Germany have adopted the standard. Sri Lanka, an early adopter, has carried out several research projects involving the standard but has not progressed beyond with institutionalizing it at a National level. Other member states have failed to realize the full potential of CAP beyond simply accepting as an interoperable XML schema.

Sahana Google Code-In Students work on CAP Broker

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.

Common Alerting Protocol messages over Radio Data System

In several blogs I've mentioned my work in relation to Common Alerting Protocol (CAP) a standard that is being absorbed by emergency communicators for exchanging situational reports in relation to natural and man-made threats. Past month I was in Sri Lanka, predominantly, attending to field work on the real-time biosurveillance program, my current ongoing project, which is using CAP for issuing health alerts (situational reports) to health workers. During this visit I was invited by CEL Lanka to review their home brewed Radio Data System (RDS) for issuing text alerts over FM radio waves.

The RDS for alerting comprises a special FM radio developed by CEL Lanka that can receive text to display as well as turn on an audible siren according to a priority level, a larger LCD display to be assemble in public spots such as bus stations, road side, trains, etc, and a software module to communicate with the encoder for generating text messages in Sinhala, Tamil, and English languages. This project had been funded by the Information Communication Technology Agency of Sri Lanka (ICTA) under a small grant. CEL Lanka has produced 40 of the LCD units to be deployed in location around the Island.

I recommended that the system incorporate CAP for value addition; more so for being CAP compliant to receive a CAP message and automatically feed the required data to the RDS text element. This way the system can be easily plugged in to any existing Disaster Communication Software system without too many changes such as a P2P CAP Broker. Similar to SMS alerts or Email alerts one can include RDS as another medium for receiving alerts.

CEL Lanka is interested in enabling the system with CAP. We will include the RDS as a plug in to the Sahana Messaging Module. Another similar project is the inclusion of a gateway to send and receive text over HF Radios being developed by Universiti Teknologi Malaysia (UTM). Respere Lanka developed the SMS/Email engine for issuing text alerts. Respere will come in as a partner to develop the web browser based GUI to trigger CAP alerts to be transported through the RDS.

Similar to SMS, RDS also has limitations on the number of characters that each packet can carry. Concatenation of packets pose the same problem as SMS pages; where packets/pages not arrive in the same sequence they are sent. These are some of the few challenges that lie ahead in delivering this component. Over the next few weeks I will be working on the software architecture and the CAP profile for including the RDS in to the Sahana Messaging Module. We intend to apply for a small grant to produce the remaining components.

P2P CAP Broker for Communicating Cyclones/Hurricanes

A proposal was submitted for an NSF grant on Communicating Hurricane Warnings. This a two country research collaboration between the iSchool @ UMD and LSF @ UCSC. I will work with LSF as a Principle Investigator in the capacity of an OR Analyst/Project Manager in managing and conducting the Sri Lankan research component. Dave Yates from the iSchool will conduct the parallel research in USA.

The research will develop a Peer-to-Peer Common Alerting Protocol (CAP) Broker for exchanging hurricane/cyclone information with stakeholders such as the Met dept, Broadcasters, First-Responders, Citizens, and other associates. The P2P CAP Broker will be a FOSS application amalgamated in to the Sahana suite of Disaster Management software modules. The intent of the P2P CAP Broker is to provide a plat form for stakeholders to network in the same way as a "social network" to exchange cyclone/hurricane information before, during, and after an incident.

A major component will be testing the CAP interoperability structure for communicating information in multiple languages; Sinhala/Tamil in Sri Lanka and English/Spanish in USA. The software will be accessible via mobile handhelds and laptop/desktop computers via the internet. The alerting component will work on SMS too. The National Weather Bureau (Met dept) could issue alerts to first-responders downstream and receive acknowledgments from alert recipients up stream. Users who are part of the network could also send situational reports upstream to the central authorities. The figure above shows the schematics of the proposed system.

The P2P CAP Broker was a recommendation made in the HazInfo research technical report. As we had encountered in the real life experiences as well as in the HazInfo research, it is usually the people and protocols that fail and not the technologies. Therefore, the proposed research of evaluating the P2P exchange of cyclone/hurricane information intends to measure the uncertainties caused due to technological and organizational complexities of this system through evidential analysis.

If the grant is approved work should begin in January 2009 and end in 2011. The first year will be dedicated to research and development of the ICT system and the second year for evaluation through mock-drills and the use during the cyclone/hurricane seasons in Sri Lanka and USA.