The following is a synopsis of the OGC document Sensor Web Enablement Application for Debris Flow Monitoring System in Taiwan.
Debris flows are a major issue in Taiwan. A debris flow is a fast moving mass of unconsolidated, saturated debris that looks like flowing concrete. They differentiate from a mudflow by terms of the viscosity of the flow. Flows can carry debris ranging in size from clay particles to very large boulders. A debris flow can be extremely destructive to life and property.
There are two reasons for the occurrence of debris flow after a strong earthquake. One is that the land collapses after earthquake and the soil gets mixed with groundwater or surface runoff. The second reason is that many crevices are formed in the earth surface after earthquake and hence, when the groundwater level increases or surface runoff concentrates, the land collapses and debris flow occurs.
Since 2002, the Soil and Water Conservation Bureau, which is responsible for the conservation and administrative management of hillside in Taiwan, has been cooperated with Feng Chia University. Together, they have successively carried out the establishment and maintenance of 13 fixed debris flow monitoring stations over the island and 2 mobile debris flow monitoring stations.
The advanced monitoring instruments include rain gauges, wire sensors, geophones, and CCD cameras. A rain gauge is used to record on-site rainfall. At the moment, the warning model for the debris flow alert uses rainfall intensity and accumulated precipitation as warning indexes to determine whether rainfall has reached the threshold and thereby the application provides timely red and yellow alerts to high risk areas where debris flows are likely to occur. As a debris flow moves down the channel, the flow will then break wire sensors placed in the spillway of diversion dams, hence indicating the occurrence of debris flow. Further, when a debris flow occurs, the geophone can detect the ground vibration generated by the collision between boulders and channel bed. The result of wavelet transform analysis can then serve as references to determine the occurrence of debris flow. Finally through the CCD camera, the hydrological process of debris flow can be vividly recorded.
The physical architecture of the sensor networks used in the Taiwan debris flow application is as follows:

The application was designed and developed to incorporate a variety of standards from the OGC and OASIS.
| Standard Name | Version | Organization |
| Sensor Model Language | 1.0.0 | OGC |
| Observations and Measurements | 1.0 | OGC |
| Sensor Observation Service | 0.1.4 | OGC |
| Sensor Planning Service | 1.0 | OGC |
| Sensor Alert Service | 0.9.0 | OGC |
| Web Notification Service | 0.1.0 | OGC |
| Web Map Service | 1.3.0 | OGC |
| Web Feature Service | 1.1 | OGC |
| OGC KML | 2.2.0 | OGC |
| WS-BPEL | 2.0 | OASIS |
| WS-Trust | 1.3 | OASIS |
| WS-Security | 1.0 | OASIS |
Below is the high level abstract architecture for the debris flow monitoring system.
The OGC SPS interface standard is used to task sensors, controlling their sample rates, sample times, what observation information to return, and checking whether they are operating correctly. According to the task that is submitted to the SPS enabled application, the Debris Flow Monitoring System will controls the relevant sensors and their observing framework.
The OGC SOS interface standard provides a standard interface for requesting and receiving one or more observations, or data collection. The Debris Flow Monitoring System collects observation data from sensors which are then further processed in a variety of models. The response from an SOS is an Observations and Measurements payload.
The OGC SAS candidate standard is used to support subscription, publication, and transmission of alerts. The Debris Flow Monitoring System modeling application is used to decide whether debris flow will happen. If the answer is “Yes”, it will send an alert via the SAS enabled alerting application.
The debris flow monitoring system uses the OGC Sensor (SWE) standards. This enhancement has changed the way of collecting, fusing, and providing the debris flow data. Before implementation of the OGC sensor standards, observation data was burned to CD or utilized E-mail way to the user. In the future the user will use the SOS to retrieve the information data via debris flow monitoring system and receive alerts.
This post is Part 1 of 5 in a series of reports on the recent annual conference of the International Association of Emergency Managers (IAEM) held November 1-4 in San Antonio, Texas.
In the alerts and warning arena, FEMA was there demonstrating the capabilities of its Integrated Public Alert and Warning System (IPAWS) Open Platform for Emergency Networks (OPEN). IPAWS-OPEN is based on the Common Alerting Protocol (CAP), which has been adopted as an international standard by the Organization for the Advancement of Structured Information Standards (OASIS). OASIS also had a large display at the IAEM show, and was conducting alerting interoperability demonstrations among the many OASIS vendors’ equipment as well as sending those alerts via the IPAWS-OPEN infrastructure to the Emergency Alert System (EAS) equipment in the FEMA display nearby. Those alerts were also available to other IPAWS-OPEN-compatible vendors on the exhibit floor and the alerts were going out on a Twitter feed as well. FEMA’s Assistant Administrator of the National Continuity Programs (NCP) Directorate, Damon Penn, and FEMA’s Deputy Director of the IPAWS Program Management Office, Wade Witmer, conducted a one hour session on IPAWS on November 1. Session highlights included:
- In 2011, FEMA plans to begin educating and training state and local officials to use IPAWS.
- FEMA is working with Internet Service Providers, such as Microsoft and Google, to deliver IPAWS alerts.
- CMAS tests are underway to deliver IPAWS alerts to cell phones; the tests are going well and the nationwide launch may come sooner than planned.
OASIS also presented and focused on Emergency Data Exchange Language (EDXL) Standards, including CAP and others. The takeaway seemed to be that if an emergency manager buys alert and warning software or systems, he or she needs to be certain it is CAP-compliant for future-proof interoperability with other alert origination, dissemination and reception systems.
Future reports in this series will detail the social media and public/private partnership discussions conducted at the IAEM Conference.
In order for alert and warning messages to be interoperable among the various stakeholders, we all need to be talking the same “language”. One organization promoting this standardization in emergency alerting is OASIS, the Organization for the Advancement of Structured Information Standards. OASIS is developing a family of standards it calls the Emergency Data eXchange Language, or EDXL. One EDXL standard that AWARE readers may be familiar with is CAP, the Common Alerting Protocol. Other EDXL standards deal with hospital availability, resource messaging, situation reporting (sit-reps), and the distribution and security of emergency messages.
OASIS recently presented a webinar called EDXL101, which explains the features of the various EDXL standards. This webinar has been archived and is now available for viewing. During the live presentation, over 100 people logged in to watch it. Anyone with an interest in alerts and warnings will find this webinar valuable. It is especially helpful for developers looking to incorporate these protocols in an alert and warning product line. Implementers and originators of emergency alerts will also get a good overview of the protocols available and how they might be used. Interoperability is an important priority in the alerts and warnings field, and EDXL101 is an excellent opportunity to learn the latest on where emerging standards are currently at. The archived EDXL101 webinar and slide set can be viewed at: www.oasis-open.org/events/webinars/

This post is Part 1 of 3 in a series of reports on the recent annual conference of the International Association of Emergency Managers (IAEM) held November 13-16 in Clark County, Nevada. See also 

