ITU X.1303 International Warning Standard:
Lessons from an Asian Implementation

Nuwan Waidyanatha*, Biplov Bhandari and Lutz Frommberger

Sahana Software Foundation, 350 S Figueroa St. STE 437, Los Angeles, CA 90071, USA

E-mail:{nuwan; biplov; lutz}@sahanafoundation.org

*Corresponding Author

Received 7 February 2017;
Accepted 8 March 2017;

Abstract

The International Telecommunication Union (ITU) Standardization Sector recommends implementing the ITU-T X.1303 Common Alerting Protocol (CAP) early warning standard [1]. The Sahana Alerting and Messaging Broker (SAMBRO) software adopts CAP and similar policies and procedures recommended for Mexico by Christian [2]. SAMBRO was operationalized in Myanmar, Maldives, and the Philippines. The strategies for implementing CAP, customizing SAMBRO, and incorporating Information Communication Technologies (ICTs) to meet the individual country requirements, are the primary discussion in this paper. This informative paper presents itself as a case study for CAP Practitioners and Researchers to make use in improving warning interoperability.

Keywords

Warning
Interoperability
Standard
Information Communi- cation Technology

1 Introduction

UNISDR [3] emphasizes early warning to be a major element of disaster risk reduction. It prevents loss of life and reduces the economic and material impact of disasters. A key objective of people-centered early warning systems is to empower individuals and communities threatened by hazards to act in sufficient time and in an appropriate manner to reduce the possibility of personal injury, loss of life and damage to property and the environment.

Disasters are a major problem worldwide and a serious threat to sustainable development. The rapid and often unplanned expansion of human settlements, especially in cities, is exposing more people and economic assets to the risk of disasters and the effects of climate change [4]. Coastal cities are made vulnerable by the low-lying land that are often built upon and as such are susceptible to flood, storm surge, tsunami, and sea-level rise [5]. Many coastal cities in Asia and the Pacific region are found in tropical areas with hot and humid climates. They reside in low-lying land and mountainous areas, both of which heighten their vulnerability to extreme events.

As a consequence of climate change, the world is facing an increasing threat of extreme events. Especially in developing countries, this heavily affects equal access to opportunities and development and is a main reason for poverty. As a result the Sustainable Development Goals (SDGs) emphasis on the need to reduce poverty and inequalities. It also emphasizes on strengthening climate actions and sustainable economies, communities and cities [6]. Early warning systems that provide actionable information to everyone are critical to fighting the consequences of climate change contributing to the factors that influence the SDGs.

Disaster Risk Management interventions such as alerting/early warning, evacuation planning, and environment management are important for addressing the challenges faced by communities at risk [7]. In this regard, the project titled “CAP on a Map” was designed to improve the institutional responsiveness to coastal hazards in Maldives, Myanmar, and the Philippines. It would augment the capabilities of the National Disaster Management Organizations (NDMOs), National Warning Centers (NWCs), line-agencies and other relevant stakeholders in disaster management to interchange and share early warning information.

A prevailing challenge is for NDMOs, NWCs, line-agencies and relevant stakeholders to coordinate and interchange alerts and warnings. To overcome this dilemma, the CAP on a Map project learned from the Canadian experience of introducing a Multi-Agency Situational Awareness platform [8] for coordinating alerts and warnings and the CAP content standard for interchanging warning messages across disparate systems. These are the underpinning design concepts of the Sahana Alerting and Messaging Broker (SAMBRO). In this paper we discuss the lessons learned in implementing the CAP warning standard in Maldives, Myanmar, and the Philippines.

2 Technology

The emphasis of this paper is on the CAP standard. However, to operationalize the standard it requires a software that inherits the properties of CAP. Therefore, we briefly introduce the CAP version 1.2 standard and the SAMBRO software tool that supports the use of CAP. Thereafter, provide insights as to how one would implement such a system for national operations.

2.1 Common Alerting Protocol

CAP has been approved by the Organization for the Advancement of Structured Information Standards (OASIS) and aims to provide a single and standardized input for alerting and warning systems [9]. The standard is also recommended by the ITU [1] documented as X.1303bis. The World Meteorological Organization (WMO) [10] and the International Federation of Red Cross/Crescent (IFRC) are key advocates of the standard. Google Crisis Response offers to publish NWC generated CAP feeds through their products including Google Public Alerts. Federation of Internet Alerting is a consortium of online advertising agencies that have extended the service of rendering alerts on their online ad-spaces. Meteoalarm and Accuweather are other rendering and distribution agents, among several, online services that help Nations publicize CAP messages. At present twenty three countries are identified to produce CAP-enabled warnings through Real Simple Syndication (RSS) feeds.

The X.1303 standard, is broadly recognized internationally as the key standard to achieve the goal of all hazards, all-media public alerting. It is essentially a XML document that inherits the interoperability aspects of the XML technology. Figure 1 shows the CAP Document Object Model. The data structure consists of a main node <alert>¹ and its sub nodes <info>, <area>, and <resources>. In this paper we refer to the nodes as blocks or blocks of data elements. Each of the blocks are composed of several other data elements. The OASIS [9] document defines each of these elements with respect to semantic interoperability. We briefly introduce the roles of the four blocks.

Figure 1 CAP data model and elements [9].

2.1.1 Alert block

The <alert> block carries qualifying elements that provide basic information about the current message. It informs the receiving machine or individual the purpose, originating or relaying source, message status, and a unique identifier for the current message and links to any other, related messages. An <alert> block will include at least one <info> block.

2.1.2 Info block

The <info> block provide categorical and textual descriptions of the addressed hazard event. It has the data elements to provide appropriate response instructions and various other details: hazard duration (e.g. effective, onset, and expire times), technical parameters (e.g. indicate hazard event telemetries), contact information (e.g. phone number), links to additional information sources (e.g. websites). The urgency (time available to prepare), severity (intensity of impact) and certainty (confidence in the observation or prediction), describes an anticipated or actual event that may relate to a classification of the warning priorities. Multiple <info> blocks are mainly used to provide information in multiple languages. Multiple <info> blocks may also describe differing parameters for different probability or intensity “bands”).

2.1.3 Area block

The <area> block describes a geographic area to which the <info> block in which it appears applies. Textual and coded descriptions such as geocodes are supported, but the preferred representations use geospatial shapes (polygons and circles) and an altitude or altitude range, expressed in standard World Geodetic System’s latitude/longitude/altitude terms in accordance with a specified geospatial datum.

2.1.4 Reference block

The <resource> segment provides an optional reference to additional information related to the <info> segment within which it appears in the form of a digital asset such as an document, image or audio file.

2.2 Sahana Alerting Broker

Sahana a community that supports the development and deployment of various open source disaster management software. Prutsalis and De Silva [11] discuss the evolution and impact of Sahana. SAMBRO is a specialized solution built using the Sahana disaster management software framework. Careem et al. [12], Waidyanatha et al. [13] and Perera et al. [14] discuss the design and features of SAMBRO version 1.0 and its use in various projects. Present SAMBRO version 2.0 release builds on a decade of action research carried out in Asia.

SAMBRO was recently revised with newer features to accommodate the situational-awareness information needs for Myanmar, Maldives, and the Philippines. These changes are discussed by Bhandari et al. [15]. Essentially the software, comprising a web-based interface and a smart-phone application (or “mobile-app”), offers interfaces for publishing, subscribing, and visualizing CAP-based alerts. The SAMBRO tool, using CAP as the interoperable standard, is instrumental to providing situational-awareness information for all disaster and emergency decision-support and management practitioners. Figure 2 illustrates the CAP message exchange communications flow to receiving CAP messages in to the SAMBRO alert hub and disseminating over various system and end user devices.

Figure 2 Exchange of full and partial CAP message over various systems.

The SAMBRO Web2Py web-based application offers a GIS map-based Common Operating Picture with an overview of “What is happening and Where and When”; key to situational-awareness. The warnings can be filtered to move into the area of interest. Each warning has its own CAP message that presents associated alerting qualifiers, detailed information relating to warning, any instructions, descriptions and many more. Moreover, SAMBRO serves as an National Alert Hub where by it aggregates all CAP feeds from all National Alerting Authorities, presents them on a Common Alerting Picture along with a National CAP feed for external systems, and allows for NDMOs to relay those messages to targeted public or private recipients.

The accompanying SAMBRO mobile-app runs on both Android and iOS smart-phones. It was developed with the Cordova-based PhoneGap framework with HTML, CSS and JavaScript; allowing the mobile-app to be independent of the operating system. It supports Android, iOS or Windows operating system. The mobile-app adopts Google Cloud Messaging (GCM) for pushing messages in real-time onto the phones and activating an audible siren alarm. This requires a dedicated Internet connection. Future version is looking at transporting the information over SMS.

3 Methodology

Wells and Williams [16] emphasize the intricacies of applying a waterfall method with well-defined elicitation and documentation of complete requirements, followed by an architectural and high-level design development and inspection. Given the dilemma of introducing CAP to novices, unexposed to the content standard but are engaged in early warning, it was cumbersome to follow a plan-driven method. We anticipating that such a planned approach could become frustrating to the users and the implementers. As a result, we identified four related areas of study and practice within the broad field of information system design: (1) user-centered design [17]; (2) rapid prototyping [18, 19]; (3) agile software design (SCRUM); and (4) action research [20, 21]. Bhandari et al. [15] extensively discuss the application of these four study areas in the “CAP-on-a-Map” project.

By applying the Scrum technique, a light-weight process framework for agile development, we initially collected user stories by involving the Stakeholders. The users modeled those stories as work-flows and information needs. Through a series of scrum sprints, we implemented pieces of CAP and customized the software for the client to experience each part and determine what to do next. The sprints were categorized into identifying, defining, and exercising: (a) alert subscribers and publishers, (b) event types, (c) warning classifications (or warning priorities), (d) predefine alert area polygons, (e) predefined alert messages (or alert templates), and (f) authoring, approving and dissemination. As suggested by Chau et al. [18], we iterated the process of testing and revising until the users agreed on the CAP and SAMBRO.

According to Hearn & Foth [19], “action research not only aims to understand the problem, it aims to provoke change through actionable outcomes.” It is also known by other related terms such as participatory action research, collaborative inquiry, emancipatory research, or action learning [20]. As part of the action research evaluation framework we applied a popular goal oriented Norman’s Gulf of Execution human computer interaction method that was outlined by Kitajima and Polson [22] and further strengthened by Vermeulen [23]. It is designed to assist with determining the usability of a system based on the user’s experience. Invited participants, at the National and Local layers, from the three countries, took part in live-exercise to self-assess the implementation. It is through these actions that we learned the outcomes discussed in the next section of the paper.

4 Discussion

The SAMBRO tool serving as means for publishing and subscribing to CAP compliant messages, was implemented and made operational in Maldives, Myanmar, and the Philippines. In general CAP provides a flexible data structure conforming to any early warning messaging requirements. The subsequent sections that discuss the various challenges and advantages inherent in CAP focus on implementing, controlling, and disseminating CAP warnings. Given that we live in an interconnected world where systems rely on the information integrity of other systems, lessons discussed could serve in strengthening and modernizing the CAP standard with latest trends and use of ICT in early warning.

4.1 Metadata

The trained CAP and SAMBRO Implementers worked with their NDMOs, NWCs, line-agencies and relevant stakeholders to define the metadata to ready the system. The activities involved defining the event types, warning classification, predefined alerting areas, CAP message templates, and user permissions.

4.1.1 Event type

Our experience has been for early warning messaging to be hazard event centric. A hazard event, in the context of early warning, constitutes an impacting geographic area, a time interval, a level of risk, and the hazard. Each NDMOs, NWCs, line-agencies and relevant stakeholders define their work-flows and standard operating procedures based on the hazard event. Cyclone, Flood, Earthquake, Mass Movement, Civil Unrest, are examples of event types. They are the high level category of the hazard event. SAMBRO adopts a set of rules for each event type, such as filtering the set of relevant CAP message templates, warning classifications, predefined alert areas, and message recipients. It also applies to SAMBRO when it works as an Alert Hub for receiving CAP messages from other systems and rendering them.

The CAP data structure provides a <category>, <event>, and <eventCode> within the <info> block that is relevant to encoding the hazard event specific information. The category (or event category) element is essentially a code denoting the subject of the message. It is for message recipients to filter the message for applying various logic for decision-making or rendering. It does not provide any value during the process of authoring of a message. The <eventCode> is a system specific code that identifies the <event>. These codes are defined by the authoring entity and is not universal for a receiving system to understand.

At present CAP <event> (or event type) is a free text element. Each country has its own definition of event specific values. For example, Myanmar likes to call Cyclone while Philippines calls it a Tropical Storm, even though they are the same phenomenon. The OASIS Emergency Management Technical Committee is assembling a list of <event> values and common practices for populating the <event>. Moi et al. [24] recommend the adoption of SAME (Specific Area Message Encoding) codes for “event type” and possibly “event codes” because it is compatible with CAP. It would also require that the values are indicated in each country’s language to be used in the language specific <info> block.

There is a need for an ontology, supporting CAP, to harmonize these terms. Otherwise, it is difficult for systems to exercise knowledge-based computations, especially for Alert Hubs to process, filter, and render warnings of similar category.

4.1.2 Warning classifications

CAP <urgency>, <severity>, and <certainty> are mandatory in the event specific content of the <info> block [9]. The three elements are used to indicate the relative priority (or warning class as termed in SAMBRO) through assignment of indexed values. Each country has their own definition of event specific relative priorities. For tropical storm or tropical cyclone warnings Myanmar uses a set of color codes (yellow, orange, brown, red, and green) that relates to the distance to the coast, Philippines uses their Public Storm Warning Signal numbers (1–5) that relates to the wind speed and expected time of arrival, and Maldives maps a set of color codes (white, yellow, red, and green) that relates to the Indian Ocean Topical Cyclone Intensity Scale defined mean wind speed and expected rain fall data (number of centimeters and duration). These warning classification would, once again, vary for different hydrological, seismological, health, fire, chemical nuclear biological, and other hazards.

Implementers had to map the individual warning classifications to the <urgency>, <severity>, and <certainty>. In most cases, the users insisted that these be preset in the predefined CAP message templates. In the case of Myanmar, since the warning classification for cyclone does not contain the intensity, it was impossible to set the <severity> to one of the indexed values: “extreme”, “severe”, “moderate”, or “minor” but could be set to “unknown”. Thereafter, the user would change the value to an appropriate level of <severity> based on the known intensity.

The SAMBRO software had to make a provisional check as to whether the value was changed from “unknown” to another. Best practices recommends avoiding the presentation of the value “unknown” in a warning message as it may lead to confusion as to perceiving the event to be of not an eminent future threat. CAP standard developers are considering removing this value but SAMBRO will continue to make use of it to address cases related to the discussed work-flow but would not present in any message.

It is recommended that Alerting Authorities, mainly NDMOs and NWCs issue an “all-clear” message when the hazard event is no longer a threat; for example, when the tropical cyclone has died or has changed its trajectory and is no longer a threat. CAP recommends setting the <responseType> value to “AllClear” and any follow on action to be described in the <instruction> [9].

Each country defines the all-clear message as part of their warning classification. For such Myanmar and Maldives uses the color code green but Philippines does not have an associated Signal number. The <urgency> can be set to “past” and the <certainty> to “unlikely”. However, there is no appropriate value to indicate the <severity>. Setting it to “unknown” would be confusing and “minor” makes no sense when the threat has ended. It might be appropriate for the CAP standard developers to consider an additional value such as “null”.

Another characteristic of the warning classification is that the <responseType>, <description> and <instructions> also differ and there is a one-to-one correspondence between a defined warning class and these three values. For example, when the heavy rains have begun and the river level is rising, the <responseType> is set to the indexed value: “prepare”. The strategy to make use of this variation was for the Implementers to create individual CAP message templates for each stage during the event state transition that also relates to the event specific warning class. Our observation is that a warning class can be defined by a color code, enumerated ranking, <description>, <instruction>, <urgency>, <severity>, and <certainty>.

4.1.3 Alerting area

The <area> block carries details of the targeted alert area. While the, human readable, <areaDesc> (or area description) is mandatory, all other WGS84 compliant quantified datum are optional. One such important element is the <polygon> or use of <circle> to define the alerting area boundaries. It makes use of latitude and longitude data that is essential for map displays. “CAP on a Map” is a strong and simple way of presenting the risk and the potential impact of a hazard event. Moreover, SAMBRO color codes those polygon or circles based on the warning classification metadata. This is quite effective to draw the attention and classify the priority of alerts for classifying the situational-awareness and enhancing the decision-making. SAMBRO offers procedures for Implementers to predefine alert area polygons based on the risk and impact of hazard events. This simplifies the task of an alert author.

Compared to the, often <polygon> payload, the <geocode> is a less data intensive method for representing the shape file of a geospatial area or location. We learned that geocodes are quite versatile for Island Nations like Maldives and the Philippines. They make it easy for alert Authors to demarcate a jurisdiction opposed to attempting to draw a polygon on a map, where they might miss or wrongfully include Islands that are invisible to the naked eye. The single geocode can represent an entire shape file (or collection of polygons). Philippines, for example, communicates the geocodes to demarcate the affective alert administrative jurisdiction, in a CAP message, but not the polygons. Geocodes are country specific. They are defined and maintained by the respective National Authorities. In the absence of polygon data, it is impossible for external systems to render the CAP message on a map.

Use of geospatial data is a common practice, now a days, and is also becoming a norm for presenting geographic information. Therefore, CAP standard developers might consider making latitude and longitude data mandatory. To overcome the Implementer’s option to use geocodes and not polygons should be addressed in the standard. There are two options: 1) the rendering agent maintains a copy of the geocode and shape file database or 2) the alert originator populate the polygon data along with the geocode. Preference of option 1) over option 2) imposes less pressure on the alert message payload and relatively a significantly lesser load on the communications networks, especially when alerts need to be disseminated to multiple recipients. Option 2) makes the CAP message complete and removes any ambiguity that may arise from the reliability of the rendering system maintaining copy of the geocode database.

4.2 Messaging Controls

The access control, within SAMBRO, can be controlled at the software module levels, particular table levels, functional levels, and/or individual record level. This is a much needed use-case for the warning, as there are many data which are only shared at organization level or between some closed user groups and not to public. There is a need for CAP to consider new and emerging privacy and security laws, in Europe for example. They require that individuals or organizations that make use of content (in this case alerts), originated by another be discarded based on a mutual agreed policy. Such controls or policies are nonexistent within the CAP messaging structure. CAP standard developers might consider examining the National, Regional, and International laws governing information use and exchange. One option might be to set a rule that any CAP message taken from another source should be deleted from consuming database based on the date and time set in the <expire> of CAP message.

4.2.1 Trusting the source

A question raised in all three countries was “how would the recipients trust the alerts received from SAMBRO?” The SAMBRO CAP messaging adopts the WMO Administrative Procedures for Register of Alerting Authorities using Object Identifiers (OIDs) [10]. The CAP OID is represented in the CAP <identifier> indicating the originating Country and Alerting Authority. However, it is not an encrypted nor a secured unique identifier that prevents anyone else from forging to disguise as a registered Alerting Authority; compromising the trust.

We practiced a complementary redundancy technique by re-directing the message recipient to a trusted website (i.e. known URL) with the full CAP message. For example, an email, carrying the WMO CAP OID and a message summary, alerts the recipient and provides the trusted website URL in the email body directing to the full CAP message. The process of redirecting is not required if the recipient is directly receiving alerts through the trust source’s CAP RSS feed or Email address.

4.2.2 Sender and approver

The process, in Myanmar and Philippines, requires that prior to an Editor issuing a message it must be vetted and approved by a supervising officer. This is to reduce the chance of disseminating partial information or misinforming. Maldives, on the other hand, entrusts the duty officer to author and transmit the alert without a second stage approval. We have found cases of missing information and inappropriately crafted warning messages when the approval process is neglected.

Publishers (or Editors) are authorized users who author CAP warning messages in consent of their seniors who approve the message dissemination. We implement a process in which the Editor must login using their own email address that is then included in the CAP required <sender>. CAP does not have an additional data element to indicate the credentials of the message Approver. It was uncertain whether we indicate the Approver or Editor’s credentials as the sender data <sender>. The unique <sender> identifier doesn’t allow for spaces or commas to include both the Editor and Approver. A workaround is by considering a CAP <parameter> with a <valueName /> sahana:approver to hold the additional <sender> information.

SAMBRO maintains a separate log of the person approving the message. However, storing it in the CAP message itself makes it complete rather than maintaining a separate log of the Edit and Approval event. On the contrary, there is no evidence of the receiving person or system making use of this information for any additional processing or decision-support. If at all it may only be used during a postmortem audit for digital forensics.

4.2.3 Relaying warnings

It is common practice, inherent in the three countries, for NDMOs to relay “alerts” received from NWCs as public or closed user group “warnings”. Typically, each country has a clique of focal persons from the in-line and stakeholder organizations (e.g. police, fire, disaster management, health, etc.) who form a closed user a group. The Maldives National Disaster Management Center and the Philippines National Disaster Risk Reduction and Management Council are the mandated Authorities for warning dissemination. As members of the closed user group, they would receive bulletins (or alerts) from meteorology, hydrology, seismology, health, transportation, and various other Organizations. Thereafter, they would verify and decide to relay to the Media and other Organizations with the intent of warning the public. Myanmar is an exception, where the Department of Meteorology and Hydrology is mandated with detection/monitoring as well as the dissemination of public and private warnings through mainstream media and new-age technology.

CAP makes it easy to implement a warning message relay work-flow with SAMBRO. When a NWC issues a bulletin (alert), the NDMO simply clicks a “relay” button in SAMBRO to initiate the relay process. It would copy the CAP-content from the NWC bulletin and, additionally, include the <sender>, <identifier>, and <sent> (in that order), from the NWC bulletin, in the <reference> of the new relay CAP message [9]. The relaying Organization may change the CAP content of the original message before disseminating the warning. Relaying Authorities in the Philippines and Myanmar required attaching a hand signed PDF document in the dissemination message. SAMBRO made use of a template to automatically produce the PDF document using data from the CAP message. It would be printed, signed, and then uploaded to the <resource> block of the CAP message.

4.3 Dissemination

The single entry of a CAP message enables simultaneous communication of alerts over many different alerting systems, thus increasing effectiveness while simplifying the alerting task. Short Message Service (SMS), Email, File Transfer Protocol (FTP), RSS/Atom, GCM, Websites (i.e. HTTP/HTTPS), and social media like Facebook, twitter are commonly used channels by SAMBRO. We use a simple Extensible Style-sheet Transformation (XSLT) to produce the various text outputs for constructing the content for all media channels.

When disseminating alert content, we learned that the <status> and <web> information are very important. The <status> qualifies whether a message is actual, exercise, test, system, or draft (fixed index values). One should always use the appropriate <status> value and should emphasis and visibly display the value. Otherwise, an intended “test” message may be perceived as an “actual” message misinforming the recipients causing unnecessary panic and resulting in inappropriate response actions. Moreover, recipients would lose trust in the Alerting Authority. The URL embedded in the <web> can be used to redirect the message recipient to a dynamically published full CAP alert on the trusted website as previously discussed in Subsection 4.2.1.

4.3.1 Short messaging

In a short message, such as SMS and Twitter, the CAP <headline> is the recommended but it is an optional element in the CAP standard. Although the text length is unrestricted, it is recommended [9] that the <headline> to be 160 characters long. However, Twitter and some SMS carriers restrict the string length to 140 characters. Given that a short message does not communicate the entire alert message, it is important that the recipient be directed to the complete message. Therefore, we include the web URL, presenting the complete message, in the SMS and Twitter messages. From our experience, dynamically constructing a string using the <msgType>, <event>, <web> and the SAMBRO specific warning priority <parameter> values have been effective; mores so than the recommended <headline> datum.

4.3.2 Email

The email body can carry a human readable message of substantial length including all essential information in a CAP message. Additionally, we transmit the CAP XML file as an email attachment, to those who subscribe for it. Dynamically generating an eye catching and meaningful email subject line was a challenge. The RFC-2822 Internet Message Format² confines the subject line of an email to a 78 characters length.

The Implementers, the three countries, were keen that the email subject carry their institutional name, the warning priority, and the event information typically found in the CAP <status>, <senderName>, <parameter> with a specific <valueName> “sahana:warning priority”, and <headline>. Once a again the <status> was important to recipients, at a first glance, determine the applicability of the message. For example the status was an “exercise” message and the recipient was not part of the exercise, then they could comfortably ignore. The concatenation of these values often exceeded the 78 character limitation. Finally, the Implementers consent to using the <senderName> and <event> to be construct the email subject. However, the first line of the email body would indicated the <status> and the <headline>.

4.3.3 Internet news feeds

The OASIS in their “example practices” guide [25] provides instructions for public dissemination of CAP messages over web feeds (also termed as Internet news feeds). The recommended RSS/Atom feed conforms to the XML 1.0 standard and easily links to the CAP XML full content. It is the preferred choice among most CAP message interchange systems. National Oceanic and Atmospheric Administration, Google Crisis Response, the Federation of Internet Alerting, and Accuweather are some of the key Organizations making use of the CAP Internet feeds (labeled as “other CAP receiving systems” in Figure 2). SAMBRO, serving as a National Alert Hub, is capable of publishing RSS feeds as well as receiving RSS feeds from National Alerting Authorities to render the warning content. Philippines is an example where PAGASA uses their own CAP authoring tool publish their CAP messages through their RSS feed (labeled as “external CAP publishers” in Figure 2). The feed is consumed by SAMBRO to display those alerts for enhancing situational-awareness information.

Although a single CAP message allows for event information to be shared in multiple languages, a single RSS or Atom feed has provision to assign only one language. The RSS <language> defines the language the content is associated with³. Any element in an Atom payload may contain a xml:lang attribute to indicate the natural language for the element⁴. When applied at the top level it applies to all sibling Atom XML nodes. Therefore, It is difficult to directly determine the language of the CAP message from the content of an RSS or Atom feed.

A CAP message carrying multiple languages could not display a summary of the RSS or Atom feed, for all relevant languages, in a simple generic RSS or Atom feed reader. Employing RSS or Atom for CAP feeds, in its current structure of using multiple <info> blocks for each language in a CAP message would require a CAP specific RSS/Atom reader to retrieve the CAP XML file, then parse it and present the separate languages as individual summaries. An alternative, suggested by practitioners it to develop a CAP news feed for each language and let the receiver chose their language feed of choice. However, the CAP version 1.2 standard does not standardize this requirement and the Implementers may chose either or.

4.4 Smart-Phone Application

The SAMBRO mobile-app was designed to achieve three purposes: 1) redundant channel for receiving mobile alerts, 2) a device with a wake-up feature, and 3) for local authorities to issue limited jurisdictional local alerts. SAMBRO incorporates SMS as an alerting channel. Bhandari et al. [15] discuss the bureaucratic barriers for Philippines and Myanmar to acquire a Bulk SMS package from a local Mobile Service Operator to push the SMS. Not all Myanmarese, in the last-mile townships, had an email account to receive email alerts either. In the absence of SMS, the SAMBRO mobile-app served as a redundant and alternative to receiving alerts on their mobile hand helds.

We integrated GCM for pushing real-time alerts on to the mobile-app. At the same time, the push message would also turn on an audible siren alarm to get the attention of the intended recipients. Emergency First-responders questioned as to how they might be aware of the alert that was received on their device? When the device was not within reach or when intended recipients were asleep, the audible siren would get their attention.

The SAMBRO specific CAP <parameter> with <valueName> “sahana:warning priority”, based on a level of urgency would trigger the audible siren. Additionally, the message would display the same “sahana:warning priority”, <headline>, <event>, <description>, <effective> date, and the alerting area <polygon> on a map. These data elements were adequate for the recipients to perceive the importance and relevance of the alert. The SAMBRO mobile-app presented a button, for each alert, to direct them to the complete CAP message on the web.

With the changing patterns in the climate and the changes in the risks, there is a growing need for decentralizing the alerting functions. A local authority, such as the Myanmar Department of Irrigation and Dam Safety personnel in the Townships have their own standard operating procedures defined by their local risk profile. When they are alerted of heavy rains up stream, as a vulnerable community down stream, they would alert the Township Community Response Teams to activate their procedures. Relying on or burdening the National Authority to issue such local alerts is inefficient. Empowering local Authorities to issue local alerts was important.

5 Conclusion

The CAP standard was flexible in adapting to the warning procedures and work-flows of Myanmar, Maldives, and the Philippines. However, the standard falls short in defining the policies and procedures for implementing, as we have discussed in this paper. CAP adoption in the Asia and the Pacific is slow but gaining momentum as early warning systems mature. The authors, through their experience in the Myanmar, Maldives, and the Philippines, have realized the challenges in operationalizing CAP and the software that wraps the standard to adapt to the National warning procedures and work-flows. The lessons discussed in the paper are valuable for future implementers of CAP in the region. ITU, OASIS, and other CAP standard developers might consider some of the lessons for improving the CAP for becoming a versatile standard to address all ICT constraints and needs.

Acknowledgement

This work was made possible through the United Nations Economic and Social Commission for Asia and the Pacific Trust Fund for Tsunami, Disaster, and Climate Preparedness (No. 2014-35). This work could not have been possible without the cooperation of the Governments of Maldives, Myanmar, and the Philippines. The Authors also wish to express gratitude to the project partner: the Asian Institute of Technology in Thailand.

References

[1] International Telecommunication Union [ITU] (2014). Series X: Data Networks, Open System Communications and Security, Secure applications and services – Emergency communications, Recommendation ITU-T X.1303 bis.

[2] Christian, E. (2016). Towards a CAP-enabled National Alert System: Some Notes for the Government of Mexico, 01 July 2016.

[3] UNISDR – United Nations. (2016). “Developing early warning systems: a check list,” in Proceedings of the EWC-III – Third International Conference on Early Warning, Bonn.

[4] WEF – World Economic Forum (2015). City Limits: The Risks of Rapid and Unplanned Urbanization in Developing Countries. 10th Edition of the Global Risks Report.

[5] Nicholls, R. J., Wong, P. P., Burkett, V. R., Codignotto, J. O., Hay, J. E., McLean, R. F., et al. (2007). Coastal Systems and Low-Lying Areas. Climate Change 2007: Impacts, Adaptation and Vulnerability. Contribution of Working Group II to the Fourth Assessment Report of the Intergovernmental Panel on Climate Change. (Cambridge: Cambridge University Press), 315–356.

[6] Griggs, D., Stafford-Smith, M., Gaffney, O., Rockström, J., Öhman, M. C., Shyamsundar, P., et al. (2013). Policy: Sustainable Development Goals for People and Planet. London: Nature, Macmillan Publishers Limited, 305–307.

[7] Smith, S., and Bunker, D. (2009). “Disaster management and community warning systems: Inter-Organisational Collaboration and ICT Innovation,” in Proceedings of the Pacific Asia Conference on Information Systems (PASIC), Hyderabad.

[8] Pagotto, J., and O’Donnell, D. (2012). “Canada’s multi-agency situational awareness system – keeping it simple,” in Proceedings of the 9th International ISCRAM Conference, Vancouver, BC.

[9] Organization for the Advancement of Structure Information Standards [OASIS] (2010). Common Alerting Protocol Version 1.2, ed. J. Westfall. Burlington, MA: OASIS.

[10] Dubuisson, O., and Christian, E. (2010). Administrative Procedures for Registering WMO Alerting Identifiers, WMO/TD No. 1556, Public Weather Services, World Meteorological Organization.

[11] Prustalis, M., and De Silva, C. (2010). “The Sahana Free and Open Source Disaster Management System in Haiti”, in ICT for Disaster Risk Reduction, United Nations Asian and Pacific Training Center for Information and Communication Technology for Development (UN-APCICT/ESCAP), 110–124.

[12] Careem, M., Pradeeper, D., Kaluarachchchi, M., Gow, G., Sampath, C., Ganesan, M., et al. (2010). “Sahana alerting software for real-time biosurveillance in India and Sri Lanka,” in Proceedings of the 1st IEEE International Conference on Computer and Information Applications (ICCIA), Tianjin, 37–373.

[13] Waidyanatha, N., Gow, G., and Anderson, P. (2007). “Common alerting protocol message broker for last-mile hazard warnings in Sri Lanka: An essential component,” in Proceedings of the 2nd International Information Systems for Crisis Response and Management (ISCRAM), Harbin, 59–65.

[14] Perera, K., Wilfred, T., Waidyanatha, N., and Silva, M. (2011). “Automation Complexities in Integrating Voice and Text for Emergency Communications in Sri Lanka,” in Proceedings of the Annual Technical Conference, University of Moratuwa, Moratuwa.

[15] Bhandari, B., Marthafifsa, A. B., Hazarika, M. K., Boon, F., Frommberger, L., and Waidyanatha, N. (2016). “Intricacies of implementing an ITU-T X.1303 cross-agency situational-awareness platform,” in Proceedings of the ITU Kaleidoscope Conference, Nanjing, 13–17.

[16] Wells, D. and Williams, L. (Eds). (2002). “Extreme programming and agile methods-XP/agile universe 2002”, in Proceedings of the Second XP Universe and First Agile Universe Conference Chicago, 4–7.

[17] Abras, C. D., Preece, M.-K. J. (Eds). (2005). “User-centered design”, in Berkshire Encyclopedia of Human-Computer Interaction: When Science Fiction Becomes Science Fact, Vol. 2, (Thousand Oaks, CA: Sage Publications), 763–768.

[18] Najjar, L. J. (1990). Rapid Prototyping (TR 52.0020). Atlanta, GA: IBM Corporation.

[19] Chau, C.-K., Leong, K.-F., and Lim, C.-S. (2003). Rapid Prototyping Principles and Applications. 2nd Edn. Singapore: World Scientific Publications.

[20] Hearn, G., and Foth, M. (2005). “Action research in the design of new media and ICT systems”, in Topical Issues in Communications and Media Research, ed. K. Kwansah-Aidoo (New York, NY: Nova Science), 79–94.

[21] Brien, R. O’. (2001). “An overview of the methodological approach of action research”, in Teoria e Prática da Pesquisa Ação [Theory and Practice of Action Research], ed. R. Richardson (João Pessoa: Universidade Federal da Paraíba).

[22] Kitajima, M., and Polson, P. (1995). Measuring the gulf of evaluation in display-based HCI, A position. Paper Presented at the Workshop on Cognitive Architecture and HCI in CHI’95, Denver.

[23] Vermeulen, J., Luyten, K., van den Hoven, E., Coninx, K. (2013). “Crossing the bridge over norman’s gulf of execution: revealing feedforward’s true identity,” Proceedings of the Special Interest Group on Computer-Human Interaction (SIGCHI) Conference on Human Factors in Computing Systems, New York, NY.

[24] Moi, M., Rodehutskors, N., and Koch, R. (2016). An ontology for the use of quality evaluated social media data in emergencies, International Association for Development of Intern Society (IADIS). J. Int. 14, 38–57.

[25] OASIS – Organization for the Advancement of Structure Information Standards. (2014). Example Practices: CAP Feeds Version 1.0. eds Y. Chen and A. Mancuso Burlington, MA: OASIS.

Biographies

Nuwan Waidyanatha is a Sahana Software Foundation Board Director and a LIRNEasia Senior Research Fellow. He has strong credentials in emergency communication systems; especially, with the development and deployment of early warning and first response systems. He recently finished leading the design, development, and implementation of the Sahana Alert and Messaging Broker in Myanmar, Maldives, and the Philippines. For over a decade, Nuwan has been conducting emergency communication related action research and pilot implementations in the Asia Pacific Region; emphasizing on low-cost technologies, communication standards, and human computer interfaces. He has served the International Telecommunication Union, and LIRNEasia, on short term assignments, evaluating national emergency communications and recommending improvements in India, Timor-Leste, and Nepal. He applies his Mathematics, Operations Research, Computer Engineering, and Systems Theory Masters and Bachelors education in his work, along with a Social Practices touch.

Biplov Bhandari is a social and humanitarian technology practitioner, working in community engagement and empowerment. He currently works as Research Associate at Asian Institute of Technology, Thailand. As a member of the Sahana Software Foundation, Biplov works in the capacity of a Software Developer. In this regard, he was instrumental to the development, implementation and evaluation of the Location-based Sahana Early Warning System in Myanmar, Maldives, and the Philippines. Other affiliations involve membership with the International Coordination Council at AstaJa Research and Development Center. He has received several awards for his work, including the Young Author Recognition and Best Paper at ITU Kaleidescope 2016 and the International Space Apps Challenge Kathmandu 2014. Biplov received his B. Eng degree in Computer Science (2014), Kathmandu University, Nepal.

Lutz Frommberger is a freelancing scientist and ICT consultant associated with Sahana Software Foundation. He is an expert on cognitively adequate user interfaces and mobile development, with considerable experience in disaster communication systems. He received a diploma in computer science from University of Karlsruhe (now KIT), Germany, in 2002, and a Ph.D. from the University of Bremen, Germany, in 2009. Lutz has a large research record in artificial intelligence, machine learning, cognitive robotics, and geographic information processing. Until 2015, he has been leading the Capacity Lab at the Cognitive Systems Group at University of Bremen where he, among other projects, led the development of the mobile disaster alerting and reporting tool “mobile4D” applied in Lao PDR.

¹ Any word enclosed between the angle brackets, as such <element>, refer to a specific CAP element.

² Request for Comments 2822 Subsection 2.1.1 explains the limitations on email text line lengths; consulted 2017-01-03 on the web: http://www.faqs.org/rfcs/rfc2822.html

³ RSS 2.0 at Harvard Law discusses the technical specifications and structure; consulted 2017-03-03 on the web: https://cyber.harvard.edu/rss/rss.html

⁴ Atom Syndication Format; consulted 2017-02-03 on the web: https://tools.ietf.org/html/rfc4287