Open Access

Rain gauge simulator and first tests with a new mobile climate alert system in Brazil

Journal of the Brazilian Computer Society201622:2

DOI: 10.1186/s13173-016-0042-7

Received: 22 December 2015

Accepted: 11 May 2016

Published: 6 June 2016

Abstract

Background

Recent national developments in alert systems are the main motivation of this work. The aim is to provide an account on the development and first tests of a new Meteorological Alert System—MAS for mobile devices to deliver alert signals. The fundamentals encompass a summary description of the Brazilian government towards the installation and maintenance of a national wide climate sensor network where the new Meteorological Alert System can be integrated. The main challenges in installing and maintaining such a network in face of its continental scope are presented.

Methods

The method describes the emulation of rain precipitation, which requires (a) the development of a data model for rain gauges (called DCP, or Data Collection Platforms) and (b) a data interface with the existing network. After testing several rain simulation models, the DCP system is converted into a signal server to provide parametric regulated data. The emulator facilitates the creation of pluviometric surrogate data and therefore the test of extreme situations. The MAS system is completed by the development of a front-end mobile application where the alerts are received by end users. We discuss classes and metrics used to evaluate the emulator performance and its integration to the alert system. We describe the DCP data structures, the rain simulator functions, and its interface with the MAS.

Results

Rain gauge emulated data sets for several parametric conditions and test performance results of the mobile application integrated to the rain emulator are discussed. We present and discuss an interface to easily access the entire rain gauge network using mobile devices.

Conclusions

Alert acquisition by the end user is a complex sequence of commands and integrated hardware involving a considerable amount of numerical work in weather forecasting. Consequently, modeling the information flow, and performing tests of a mobile application, justifies our initiative as a set-up stage prior to massive dissemination of an alert system fed by real data.

Keywords

Alert system Climate sensor Disaster monitoring Rain emulator Georeferenced data system

Background

It is hard to estimate the value of information prior to a weather disaster or a significant risk situation caused by nature. Currently, advanced information is the only solution readily available against an imminent risk state. The term disaster implies a situation of increasing or fatal vulnerability while the word, as defined by [1], is “the characteristics of a person or group and their situation that influence their capacity to anticipate, cope with, resist, and recover from the impact of a natural hazard.” Information is however a simple word which encompasses several ideas such as validity, trustfulness, and accuracy. Such ideas are all important to the advanced recognition of a distressful incident often endangering countless lives and causing substantial economic and social damage. Another relevant requirement of a good warning system is easiness of access; otherwise, all benefits conveyed by such “highly precise, valid and trustful information system” are unreachable.

The idea of automatic meteorological alert systems exists since the availability of communication networks [27]. In particular, the demand for Disaster Alert Systems or DAS and, more specifically, Flood Alert System (or FAS, see [5] and [8]) have grown substantially both with population increase [9, 10] and the occurrence of climate change [11, 12]. The issuing of an (useful) alert is understandably a complex activity involving arrays of sensor networks and data on one side and much work in processing and analyzing data on the other, so as to have a minimum degree of reliability. Moreover, the issuing act is a decision problem [13] which naturally involves authority validation [14]. The planning, development, and implantation of a national FAS for the entire country require a network covering about 8 million square kilometers. As such, there are several advantages in planning the system by the use of computer simulations [15, 16]. This task may be undertaken by setting up a simulation environment where all sensor network components and issue subsystems are conveniently modeled [17] and their performance analyzed. In particular, long time reliability of remote sensors—whose link is only possible via cabled or wireless links—should be taken into account as a network performance parameter. For wireless sensors (devices whose physical layer involves radio links), the influence of climate is a crucial factor since it is known [18] that water can attenuate electromagnetic wave propagation. Therefore, the effectiveness of the final alert signal may be severely impaired when it is most needed: at the imminence of a disaster.

The project of planning and integrating a large network of remote sensor data to render trustful alerts is a formidable task. There are application opportunities for both theoretical and practical aspects of computer science and software development, from sensor choice to programming the end user mobile interface. Moreover, it involves legal aspects related to the responsibility of delivery and sustaining a continuous service of information that becomes vital with the ongoing threat of climate change. This paper also emphasizes the importance of software engineering in the Brazilian context [19].

Research design and methodology

With the occurrence of extreme events in 2008 and 2011, in the form of massive landslides in the regions of Itajaí and Mandaú rivers [20], respectively, the Brazilian government established a national plan (named National Plan for Risk Management and Disaster Response) and created the Brazilian Center for National Disaster Monitoring and Alerts or CEMADEN in a Portuguese acronym (www.cemaden.gov.br). CEMADEN determined three fundamental extreme situations to be handled [2123]: severe flood, landslides in potential areas, and severe drought. Such situations gave rise to planning, contracting, and installing a network of gauge stations (generically called DCP or Data Collecting Platforms, Fig. 1 (left)) of several types, whose data are integrated in order to deliver trustful information on real time about specific climate variables at a given location on the Brazilian territory. Nine hundred Brazilian municipalities are being monitored by CEMADEN network systems, which includes hydro-meteorological, pluviometric, and landslide DCPs, besides several meteorological radars. Data from this network is collected and managed by a special software (Stations Remote Management System or SGRP in Portuguese) which delivers current DCP status on accessible georeferenced maps. Currently, the network has over 3000 DCPs installed throughout the country (Fig. 1 right). On the user side, CEMADEN information is especially useful for national agencies such as the National Water Agency, the Brazilian Army, CENAD (National Centre for Disaster and Risk Management), the Civil Defense, research institutions, universities, and climate centers. Prior to alert delivery, the risk of a potential disaster is analyzed by CEMADEN team at a crisis room.
Fig. 1

DCP and network geographical coverage. (Left) Photo showing an autonomous DCP type unit called pluvio containing the rain gauge, solar panel, GSM/3G antenna, and the electronic control box mounted on an aluminium frame. A high-gain antenna provides GSM/GPRS link to a distant radio base station. (Right) 2015 CEMADEN network of pluviometric DCPs (red dots) installed on the Brazilian territory

Technically, an alert system using CEMADEN data is in fact a FAS with additional landslide signals [24] for restricted areas. DCPs are autonomous systems (Fig. 1 (left) shows one type) installed on both urban and rural areas which communicate via GSM/GPRS links [25]. DCP installation and maintenance are an ongoing process and involve detailed analysis of the target spot often recruiting specialized personnel and demanding transportation planning, since many DCPs should be located in remote areas like dense forests and other inhabited zones. Since GPRS links are privately owned and may suffer from link suppression for a variety of reasons [26, 27], efforts have been made by our group to find network alternatives. These may involve, for example, the use of satellite links (which, depending on the frequency used, is also prone to rain attenuation, see [28] and [27]) or alternative government-operated networks.

A block diagram of the DCP internal structure representing the common and main elements for two DCP types, called pluvio and acqua, is shown in Fig. 2. The difference between the two is that acqua DCP has an additional soil humidity sensor shown with dashed lines in this figure. As already mentioned, external communication is provided by a GPRS modem (RS232/RS445 interfaces, EGSM 900 and GSM 1800 bands, max. downlink rate 90 kbps, max. uplink rate ≈42 kbps) and an external antenna of two types, depending on the DCP location. In urban areas, a single monopole <2 dBi antenna gain is sufficient. Rural zones require higher gains and the same GPRS modem is connected to a >10 dBi Log-periodic antenna. The DCP data logger performs AD (analog-digital) conversion for all sensor units which include a tipping bucket rain gauge [29, 30] (200 ± 0.5 mm bucket diameter, 500-mm/h capacity and ±2 % or ±3 % accuracy in the 0–250-mm/h and 250–500-mm/h interval, respectively) and internal humidity, temperature, and control box lock sensors. Such internal data measurements registered at every 24-h period and sent for maintenance reasons. The power module has a battery bank (12 V/36 Ah), a solar panel (maximum power 20 W/17.4 V at 25 °C), and a charge control unit.
Fig. 2

DCP schematic diagram. Schematic representation of DCP pluvio and acqua (with a soil humidity sensor)

Regarding pluviometric DCPs, data are sent to SGRP via FTP regularly, depending on the weather, in the form a file using a protocol specified by CEMADEN. The file contains georeferenced information about the DCP spot (pluviometric temporal data and maintenance information). If there is no rain, files are dispatched hourly while the update rate falls to 10 min in case of severe rain. An internal buffer saves rain gauge countings and promptly delivers an updated file with all accumulated measures as soon as communication is restored after an event of link suppression. Therefore, although a single or groups of DCPs may be unreachable at a given moment during rain extremes, data are never lost but suffer a natural delay due to the intermittent status of the communication link. Present reports of DCP availability in time are 92 ± 4 % on average for all Brazilian states.

The National Plan defined several priority areas in the country based on an initial risk analysis for the choice of each site, depending on criteria such as presence of radio base stations less than 5 km away from intended DCP site, deficiency of local hydro-meteorological data, and existence of risk areas and population density. As shown in Fig. 3, 51 % of the Brazilian population (over 200 million inhabitants) are presently attended by the network (that is, live in an area monitored by one or several DCPs). From this total, 45 % is regarded as priority and less than 3 % are still living in unattended sites. In terms of city number, Fig. 3 (upper plot), 15 % of the cities are located in risk areas and therefore are monitored. The remaining 3 % (Fig. 3, lower plot) are still uncovered and are natural installation targets for the coming years. Finally, the National Plan intends to monitor all areas, even the non-priority ones.
Fig. 3

Status of the network coverage. Percent of the total population (over 200 million inhabitants) assisted by the network installation plan until 2014 according to monitoring and priority status

On the social level, there are several challenges of installing and supporting the variety of DCP types and their configurations across 8.5 million square kilometers. Data provided by ANATEL (Brazilian Telecommunication Agency, see also http://opensignal.com/ ) estimate that over 90 % of the Brazilian area are serviced by mobile connections, so natural choice for each DCP communication is the GSM/GPRS channels. CEMADEN network is therefore served by four major mobile carriers in the country: Vivo (Telefonica), the largest one responsible for 29 % of the Brazilian market share, TIM (Telecom Italia) with 27 %, CLARO (Amrica Movil) with 25 % and the remainder served by OI (CorpCo), a joint venture with Portugal Telecom. Thus, data communications employs packet data transport via GPRS (General Packet Radio Services) which is a packet-oriented mobile data service on the 2G and 3G GSM cellular global system [25]. A major advantage of GPRS is its simplified access to the packet data networks like the internet. The packet radio principle is employed by GPRS to send user data packets in a M2M way between GSM DCP stations and external data networks. These can be directly routed to the packet-switched networks from the automatic hydro-meteorological stations. As is well known, GPRS throughput and latency are variables that depend on the user number simultaneously sharing the service. The GSM/GPRS transponders installed in every DCPs provide data rates up to the third generation (3G). Although the feasibility of such communication system has been demonstrated, there are clearly limits for both quality of service delivered (QoS; national coverage area of the GSM/GPRS network, service call time) and sensitivity to climate change (service loss during heavy rainfall).

In order to test a platform, for a massively distributed FAS, the following section describes a DCP numerical model, which emulates CEMADEN-formatted file flow as a surrogate data generator, a simplified dispatch system, and DTR-ADS (DTR Alert Dissemination System) specially designed for the purpose of disseminating alerts to the population. In this sense, our works integrates with the already existing network resources, readily allowing alert dispatch.

Methods

Emulation of DCP data generation is justified by the need of debugging a DAS prior to system delivery to final usage and by the difficulty of testing the real system. Accordingly, the output of the emulation system is the input of the alert system. With such scheme, it is possible to push the DAS to extreme and improbable situations when all DCPs (amounting to thousand units) would signal critical events at the same time, i.e., generalized rain gauge above a certain threshold. This scheme allows to test the resulting performance of the message delivery system as a DAS component without using real data. Another interesting feature of a simulation environment is the possibility of integrating DCP data into clusters and testing the incidence of network delays upon the efficiency of the delivered message.

The construction of a DCP simulation environment follows the heuristic of a DCP data generation model calibrated to a real rain density distribution function. In other words, it is necessary to adjust the simulated features to the statistical properties of a local (georeferenced) distribution function of rain deviates for the overall results to replicate real data. DCP emulation involves five phases:
  1. 1.

    Construction of a DCP data class;

     
  2. 2.

    Definition of a suitable stochastic rain generator [3133];

     
  3. 3.

    Programming the class methods;

     
  4. 4.

    Definition, programming, and calibration of rainfall thresholds for alarm delivery;

     
  5. 5.

    Construction of an output interface (which in our case is integrations to the DAS system).

     

Network parameters can be added to the DAS interface as, for example, DCP-dependent link rates. Of particular importance is phase 4 where signals are triggered on the base of rainfall thresholds. In order to keep the model simple in a first approach, each DCP has its geographical position referenced as a simple attribute. Real alert signals may be created by integrating information over vast catchment areas in the cases where the network sensor density is below a certain value. Alert signals should ideally take into account soil features such as topology, porosity, and permeability, along with the need of solving hydrological models on real time [34]. For simplicity, our model allows the reproduction of real cases by proper calibrations of statistical rain distributions instead of using first principle modeling.

The DCP data model and the scheme of the DCP emulator are illustrated in Fig. 4 where each block in Fig. 4 a represents a data type (using C language for reference, [35]) as explained in Table 1. Figure 4 b shows a simple diagram of the DCP emulator file relationship. The file names and descriptions are read in Table 2. Once the class model is defined, a DCP collection can be easily created by using vector containers [36]. Rain volume plots or pluviographs (as output in Table 2) are generated by summing the total amount of rain tippings for a given DCP at assumed simulation time intervals. Each tipping has a quantized volume (typically 0.2 mm). The total volume is the integrated pluviograph volume within the interval.
Fig. 4

DCP model and file diagram. a Data diagram of the DCP class model showing input parameters and output variables. b File diagram for input and output data generated by the DCP emulator and rainfall threshold function for alert generation

Table 1

Type and variable descriptions used in Fig. 4 a

Variable

Type

Description

PCD-ID

string

Input: DCP identification number associated to an address

Table name

string

Input: DCP type

Lat

string

Input: DCP or alert zone latitude

Lon

string

Input: DCP or alert zone longitude

Radius

double

Input: DCP alert zone radius (in kilometers)

Initial date

Julian Date

Input: DCP initial working date in Julian dates

Simultime

double

Input: complete DCP simulation period

PercentCoverage

double

Input: percent of simulation time covered by rainfall

Beta

double

Simulation input parameter (see Eq. 1)

Gamma

double

Simulation input parameter (see Eq. 1)

FreqRain

double

Input: rain generation rate within the simulation period

ATimeout

double

Input: alert time-out period

CriticalVol

double

Input: critical volume triggering an alarm

BTimes

Julian Date

Output: tipping times as a vector of dates

Volume

double

Output: rain volume in millimeters

AlertTimes

Julian Date

Output: date of the DCP alert issuing

AlertType

int

Output: integer returning alert severity

TotalVolume

double

Output: total amount of rain

Table 2

File and function descriptions for the diagram in Figs. 4 b and 5

File name (Fig. 4 b)

Description

Dcp_data.dat

Input data for a collection of DCPs (see

 

Table 1)

DCP_config.dat

Input of simulation-dependent variable

 

and parameters

DCP_ID.dat

Output vector of tipping times in Julian

 

Date for a given DCP

DCP_hydro.dat

Integrated output pluviograph of a

 

given DCP

DCP_alert.dat

Sequence of issued alert types and times

 

for a given DCP

Function name (Fig. 5)

 

GeneratePrecipitation()

Responsible for fitting a stochastic model

 

to generate gauge tippings

WriteDCPTippings()

Collects tipping times in Julian dates for

 

a given DCP

CalculatePluviographs()

Integrates rain volumes within a given time

 

interval

WritePluviographs()

Write output of CalculatePluviographs()

GenerateAlerts()

Responsible for running the simulator logic

 

of alert generation

DispatchAlert()

Responsible for dispatching a sequence of

 

alerts to the user alert zone

Each DCP is the geographic center of an “alert zone” which defines the area where potential targets (DAS users) may be associated by their maximum radius distance from the DCP. As a consequence of model simplicity, the so defined alert defined is a circle of a predefined radius where a specific alert type may be issued.

The frequency of alert occurrences is a function of the stochastic model used to generate rain. A block diagram of the main DCP emulator functions is shown in Fig. 5 and their descriptions are given in Table 2. Rain gauge tippings are modeled by assuming a stochastic time distribution between successive tippings. In particular, we used Weilbull distribution [37]:
$$ W(x,\beta,\gamma)=\frac{\gamma}{\beta^{\gamma}}x^{\gamma -1}e^{-(x/\beta)^{\gamma}} $$
(1)
Fig. 5

DCP emulator functions and alert method diagram. Block diagram of the main DCP emulator functions and the integration with the DTR-ADS system

where β and γ are two positive parameters (see Table 1). The distributions of rain showers (say, their frequency in 1-month interval over a given DCP) as well as rain duration (how long a shower lasts) were generated by uniform distributions. Within each shower interval, however, the distribution of tipping time intervals was modeled by Eq. 1.

The logic of alert generation is represented by the block diagram of Fig. 6, which is a detailed view of the central block in Fig. 5 (function GenerateAlerts()). Potential alerts are monitored by iterating over all DCPs. An initial alert status subroutine sets up the status of all DCP alerts. Alert emulation exists in a time flow created by an external loop which updates the time using the variable tnow until tend. For each DCP, alert status is continuously monitored by comparing generated volumes with CriticalVol (Table 3). In fact, different critical volumes can be defined and mapped into alert color schemes. An alert expires in accordance to ATimeout (Table 3), which triggers a change in the alert status. Issued alert times are saved and sent to the alert server (Fig. 6). Delivering and canceling an alert requires a message dispatch: in the first case, to establish a risk state; and in the second, to release the affected zone. The simulation can run in an “accelerated mode” by updating tnow independently of the real-time flow, which is ideal to test several alert scenarios or different statistical models of rain emulation and their impact on the alert system.
Fig. 6

Alert generation and dispatch methods. Block diagram of the alert generation and dispatch methods

Table 3

DTR-ADS scores and standard deviation according to Nielsen methodology [53]

 

Usability

Utility

Satisfaction

Average

8.2

8.6

7.6

Median

7.4

7.2

7.6

Standart deviation

0.9

1.2

1.3

DTR-ADS integration

DTR-ADS application software represented on the bottom left of Fig. 5 was integrated to the emulator program in order to test the delivery of alert signals to mobile devices. In the currently installed DCP network, massive alert relies on radio frequency broadcasting to distribute messages. The popular use of cell phones gave rise to a plethora of applications which greatly improve public dissemination. In particular, it is possible to generate specific alerts, that is, warning messages targeting a specific region at delivery time [2]. Therefore, the only additional information required is location, which does not need to be fixed, since most modern cell phones are integrated to GPS units [38] or access their position using GPRS [39]. DTR-ADS is a cell phone delivery message system which implements an alert server, a mechanism for users to visualize the entire network map status, and a way to register their location and receive alerts. The emulation version associates a circular zone around each DCP. Every time an alert is issued to that specific alert radius, all pertinent users receive a warning either through a Short Message Service (SMS, [40]) or an interaction with the phone alert software as described in this section.

Android platform [4143] was chosen as the base operational system (OS) in accordance to the overall number of mobile devices per OS users in Brazil [44]. DTR-ADS was built using FOSS guidelines (Free and Open Source Software) [45] and their fundamental programming tools are Android Studio SDK [46], Java SDK [47], and WAMP (Windows, Apache, MySQL, and PHP, [48]). HTTP (HyperText Markup Language, [49]) was used as the data control and access protocol.

Three distinct user entities were conceived:
  1. 1.

    An “administrator” who can access all system functions and is responsible for its operability and maintenance;

     
  2. 2.

    A “monitor” or agent responsible for situation registration (a situation is the state of a potential alert issuing for a given region), monitoring, alert issuing, and canceling;

     
  3. 3.

    An “end user” or the final and public entity interested in the alert and associated to at least a target zone.

     
DTR-ADS code replicates internally some of the basic functions of an alert managing system: monitor, update, end, and remove a situation, where “situation” is the state of an alert prior to its issuing. For simplicity, the end user is responsible only for registration of his/her address and phone number. To a certain extent, the data structure described in the previous section is emulated in the situation class which contains data about alerts, DCP attributes like latitude, longitude, and radius. A database establishes connections using standard methods such as connect() and query(); a map class is used to display georeferenced data on Google maps [50] and, finally, a SMS class is applied to send SMS messages. These ingredients and their class representatives are schematically shown in Fig. 7. Conventional methods such as user registration and user removal are functions of the end user class. A location update function is necessary to report user location change and thus update the alert issuing system. Once an alert is received, the mobile alert system is activated (therefore the function “notify user”). The monitor class originally detects an alert situation and provides its registration to the system database. The update and removal of a situation are inputs for the situation message acknowledgement and validation function in the alert server class. This class is associated to the administrator user as described previously. The total number of affected users is determined and the alert is dispatched.
Fig. 7

ADS class diagram. ADS simplified class diagram for three distinct entities: end user, monitor, and alert server

Results and discussion

Here, we report the successful test of complete alert emulation with 10 DCPs. Figure 8 depicts three pluviograms of 20-day duration for different values of the pair (β,γ) in Eq. 1 and different values of FreqRain and PercentCoverage (see Table 1). This diagrams were created by a histogram function which converts tipping times sets into precipitation distributions according to a pre-selected time resolution, Δ t. For Fig. 8, all pluviograms used Δ t=30’. In general, the smaller the value of β, the denser will be the resulting distribution, which is also affected by parameters FreqRain and PercentCoverage. Tipping times are generated in “advance mode,” that is, first the entire tippings are created and then the saved sequence of each DCP is run at a preselected time rate to generate alerts. As a comparison with emulated results, Fig. 9 a shows a real rain frequency measure collected at a DCP installed at CTI from 6 December 2015 15:54:08 to 10 December 2015 12:00:00, corresponding to 4 days of precipitation record and Δ t=10’. For both real and emulated rain sequences, Fig. 9 b, c represents the tipping time histograms (as number of occurrences on the left axis) and the corresponding cumulative distribution (read on the right axis from 0 to 1.0). Figure 9 c is the histogram for the first 5 days of the emulated rain gauge series of Fig. 8 a. In the case of the CTI-DCP, the quantized tipping volume is 0.4 mm. In these plots, δ t is the scale of the time interval distribution.
Fig. 8

Emulated pluviograms. 20-day pluviograms for for three DCP emulations (Δ t=30’): a FreqRain = 5, PercentCoverage = 50 %, β=0.1; γ=0.5, total precipitation = 33.8 mm; b FreqRain = 10, PercentCoverage = 50 %, β=0.01; γ=1.0, total precipitation = 161.4 mm; c FreqRain = 5, PercentCoverage = 20 %, β=0.003; γ=0.5, total precipitation = 300.4 mm

Fig. 9

Comparison with real data. a Real pluviogram of a CTI-based DCP for 4 days starting on 6 December 2015 15:54 local time. b Histogram of tipping time distribution as a function of time interval (in minutes). As a comparison, the equivalent histogram distribution for the non-calibrated pluviogram of Fig. 8 a is shown in c (β=0.1; γ=0.5). The cumulative distributions (dots) are shown on the right axis for both b and c

Alerts are created using CURL library [51] as interface. Consequently, the ADS system is responsible for collecting all users belonging to a specific zone and issuing the alert to them only. Two CPU machines were used to emulate rain process and as alert server. As usual, a color scheme represents the alert zone on screen. Consequently, the monitor and administrator users can follow the onset of an alert on a given region and its disappearance after alert time-out. This is shown in Fig. 10 (right), for two zones with different radius. Figure 10 (left) is a shot of the end user interface. A map is presented for the user to select his/her address and enter his/her phone number. The end user is allowed to register several addresses under the same phone number. The ADS internal processes run as asynchronous subsystems performing distinct operations such as accepting simultaneous requests from different sources or processing user’s georeferenced data to deliver an alert using the concept of “critical section” [52]. Since the main objective of ADS is disseminate alerts, when receiving a new situation, unprocessed data changes are blocked. This feature is required to avoid echoing due to transmission with heavy routing through IP connection. Once alert data are processed, they are unblocked for new changes. To avoid excessive processing, the DCP simulator tests (running in accelerated mode) were implemented in a time interval (of typically 15 s) between alert creation and change of the data structure, which is replicated in the alert server.
Fig. 10

Displaying results in the mobile device. (Left) User page with map for address registration (http: //www.facti-sda.com.br/sda/paginas/cadastrarUsuario.php). (Right) Screen image of the ADS control interface showing two alert zones with a different radius over the region of CTI Renato Archer

CEMADEN interactive map ( http://www.cemaden.gov.br/mapainterativo/ ) is only available to desktop platforms. To surpass this restriction, an intermediary service was created to enable users to view the map on mobile Android platforms as shown in Fig. 11. The new “synthetic” interface integrates regions containing DCPs and, according to the zoom scale and distance of each DCP, provides a summary map that can be zoomed to the required level.
Fig. 11

CEMADEN map and synthetic version for mobile devices. Comparison on 17 December 2015 10:30 local time between (left) CEMADEN interactive map and (right) synthetic map for mobile devices over the city of Petrópolis showing the DCP distribution (automated pluviometers). The legends provide the daily accumulated precipitation in millimeter while the blue circle on the right indicates a region to be zoomed and depicting the DCP number in the area. The black circle marks an inactive DCP which corresponds to the grey circle on the left

As for the adequacy to the user, the DTR-ADS testing used four cell phone brands (with different versions of of Android OS installed) and involved the distribution of cell phones for several testers (< 10 individuals). Users were invited to register themselves at predefined physical locations. The integration of the DCP emulator and ADS was tested together with an evaluation of the ADS interface in three different mobile brands using Nielsen methodology [53, 54]. From 0 to 10, usability, utility, and satisfaction were scored as shown in Table 3. The metrics used in assessing satisfaction consist of asking users to execute each of the software functions—without knowledge of its objective—before filling out a questionnaire. A complete test sequence was also run including downloading, installing, validating, and executing the application on each of the three mobile devices.

Conclusions

The advantage of using a circular area and the scheme adopted for the emulator is apparent for treating landslide alerts [55], which does not involve rain gauges. Although a strong correlation between heavy rain and landslides has long been established [56, 57], the problem of landslide alert is much more complex since it also depends on geological processes.

This paper describes a meteorological network emulator system that simulates data from thousand sensors and their integration to a mobile alert system application designed to end users. Rain data, produced by a stochastic rain generator, emulates the average volumes expected for a given place. Rain gauge data structures follow a DCP modeling that associates a given alert to a circular zone region centered on the DCP position. The area of one alert zone may be modeled by using arbitrary shapes [58]. The resulting system is able to generate real-time alerts. It can test the effect of impairing factors on the overall performance of the communication process of a massive network of sensors.

Real data from CEMADEN DCP network can feed the alert system in this way by substituting outputs from the emulator by the gauge data associated to a specific radius centered on a real DCP. This procedure was implemented after the first emulator tests. Just as in the case of an emulated DCP, differential pluviometric volumes trigger flood alerts. In this model, each DCP is an alert source of pluviometric data. This is a simplified approach, since the real issuing of an alert is the result of a complex analysis involving decision taking and data processing. Nonetheless, the correct DCP risk degree can be set by changing the alert threshold for each sensor unit. Therefore, we have completed the development cycle as far as the alert interface is concerned. The mobile application can be improved by allowing users to provide real-time feedback such as images or describing the local status by sending messages. In fact, a simple questionnaire could be filled in by users after receiving an alert. In this way, the population would also understand the importance of actively participating in the alert system, which should not be limited to the automated network. Data collected by the population could be integrated, processed, and used to “tune” (or train) the alert dispatch system in a positive way so as to optimize its trustfulness and signal reliability (to access and confirm the performance of the dispatched signals, which is obviously impossible to be emulated by any automated method). The challenge of closing this positive cycle is big in Brazil, given the continental size and the variety of socio-economic contexts.

Abbreviations

AD, analog-digital; ADS, Alert Dissemination System; ANA, Agência Nacional de Águas (National Water Agency); CEMADEN, Centro Nacional de Monitoramento de Alertas e Desastres Naturais (Center for Natural Disaster Monitoring and Alerts); CENAD, Centro Nacional de Gerenciamento de Riscos e Desastres (National Centre for Disaster and Risk Management); CPU, central processing unit; CTI, Center for Technology of Information; CURL, client uniform resource locator; DAS, Disaster Alert System; DCP, Data Collecting Platform; EGSM, Extended Global System for Mobile Communications; FAS, Flood Alert System; FOSS, free and open source software; FTP, file transfer protocol; GPRS, General Packet Radio Services; GSM, Global System for Mobile Communications; HTTP, hypertext markup language; KML, keyhole markup language; MAS, Meteorological Alert System; RS, recommended standard; SDK, Software Development Kit; SGRP, Sistema de Gerencialmento Remoto de Plataforma (Stations Remote Management System); SMS, Short Message Service; WAMP, (Windows, Apache, MySQL, PHP).

Declarations

Acknowledgements

We are grateful to Dr. Carlos A. Nobre, Dra Regina C.S. Alvalá, from CEMADEN, Marcos A. Rodrigues, and Germano Beraldo from CTI for important discussions. This work is supported by the MCTI—the Brazilian Ministry of Science, Technology and Innovation. Special thanks to Silvestre R. de Aguiar Jr, from Coordenação Geral de Meteorologia, Climatologia e Hidrologia—SEPED/MCTI—Secretaria de Políticas e Programas de Pesquisa e Desenvolvimento.

Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License(http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Authors’ Affiliations

(1)
Fundação de Apoio à Capacitação de Tecnologia de Informação, Rodovia Dom Pedro I (SP-65)
(2)
Centro de Tecnologia da Informação Renato Archer, Rodovia Dom Pedro I (SP-65)

References

  1. Blaikie P, Cannon T, Davies I, Wisner B (2014) At risk: natural hazards, people’s vulnerability and disasters. Parr I, Chapter 1. Routledge, p 11.Google Scholar
  2. Permut AA, Permut AR, Permut RM (1970) Disaster Alert System. U.S. Patent Document n. 4,155,042 https://patents.google.com/patent/US4155042A. Accessed 29 May 2016.
  3. De Groeve T, Kugler ZG, Brakenridge GR (2006) Near real time flood alerting for the global disaster alert and coordination system In: Proceedings ISCRAM2007, 33–39. https://floodobservatory.colorado.edu/Publications/DeGroeveKuglerBrakenridge.pdf. Accessed 29 May 2016.
  4. Brázdil R, Pfister C, Wanner H, Von Storch H, Luterbacher J (2005) Historical climatology in Europe—the state of the art. Clim Chang 30(3): 363–430.View ArticleGoogle Scholar
  5. Thielen J, Bartholmes J, Ramos MH, De Roo A (2009) The European Flood Alert System—Part 1 concept and development. Hydrol Earth Syst Sci 13(2): 125–140.View ArticleGoogle Scholar
  6. Bartholmes JC, Thielen J, Ramos JMH, Gentilini MH (2009) The European Flood Alert System EFAS—Part 2 statistical skill assessment of probabilistic and deterministic operational forecasts. Hydrol Earth Syst Sci 13(2): 141–153.View ArticleGoogle Scholar
  7. Mileti DS, Sorensen JH (1990) Communication of emergency public warnings: a social science perspective and state-of-the-art assessment. Oak Ridge National Lab. Technical Report No. ORNL-6609, TN (USA). http://www.osti.gov/scitech/biblio/6137387. Accessed 29 May 2016.
  8. Keoduangsine S, Goodwin R (2012) An appropriate flood warning system in the context of developing countries. Int J Innov Manage Technol 3: 213–216.Google Scholar
  9. Meadows DH, Meadows DL, Randers J (1992) Beyond the limits: global collapse or a sustainable future. Earthscan Publications Ltd, London. ISBN 1-85383-131-X.Google Scholar
  10. Vörösmarty CJ, Green P, Salisbury J, Lammers RB (2000) Global water resources: vulnerability from climate change and population growth. Science 289(5477): 284–288.View ArticleGoogle Scholar
  11. Meehl GA, Stocker TF, Collins WD, Friedlingstein P, Gaye AT, Gregory JM, Kitoh A, Knutti JM, Murphy JM, Noda A, Raper SCB, Watterson IG, Weaver AJ, Zhao Z (2007) Global climate projections In: IPCC Fourth Assessment Report, Climate Change, 3495, 747–845.Google Scholar
  12. Houghton JT, Ding Y, Griggs DJ, Noguer M, Van Der Linden PJ, Dai X, Maskell K, Johnson CA (eds)2001. Climate change 2001: the scientific basis. Cambridge University Press, Cambridge UK. ISBN: 0521-80767-0.Google Scholar
  13. Ramos M, Bartholmes J, Thielen-Del Pozo J (2008) Development of decision support products based on ensemble forecasts in the European Flood Alert System. Atmos Sci Lett 8(4): 113–119.View ArticleGoogle Scholar
  14. Mcentire DA, Myers A (2004) Preparing communities for disasters: issues and processes for government readiness. Disaster Prev Manag Int J 13(2): 140–152.View ArticleGoogle Scholar
  15. Sorensen JH (200) Hazard warning systems: Review of 20 years of progress. Nat Hazards Rev 1(2): 119–125.Google Scholar
  16. He Y, Wetterhall F, Cloke HL, Pappenberger F, Wilson M, Freer J, Mcgregor G (2009) Tracking the uncertainty in flood alerts driven by grand ensemble weather predictions. Meteorol Appl 16(1): 91–101.View ArticleGoogle Scholar
  17. Pappenberger F, Thielen J, Del Medico M (2011) The impact of weather forecast improvements on large scale hydrology: analysing a decade of forecasts of the European Flood Alert System. Hydrol Process 25(7): 1091–1113.View ArticleGoogle Scholar
  18. Crane RK (2003) Propagation handbook for wireless communication system design. CRC press. Taylor and Francis Group, Boca Raton. ISBN-13: 978-0-203-50677.View ArticleGoogle Scholar
  19. Dias-Neto AC, Prikladnicki R, Barros MDO, Murta LG (2015) Software engineering research in Brazil from the perspective of young researchers: a panorama of the last decade. J Braz Comput Soc 21(1): 1–17.View ArticleGoogle Scholar
  20. Medeiros VS (2013) Análise estatística de eventos críticos de precipitação relacionados a desastres naturais em diferentes regiões do Brasil. Master thesis submitted to the University of São Paulo (Escola Politécnica). Ed. USP, São Paulo. http://www.teses.usp.br/teses/disponiveis/3/3147/tde-04102013-113054/en.php. Accessed 29 May 2016.
  21. Adger WN, Huq S, Conway D, Hulme M (2003) Adaptation to climate change in the developing world. Prog Dev Stud 3(3): 179–195.View ArticleGoogle Scholar
  22. Nobre C (2009) Brazil and climate change—the context In: Brazil and climate change: vulnerability, impacts and adaptation. Brasília, Brazil: Center for Strategic Studies and Management. ISBN: 978-85-60755-16-5.Google Scholar
  23. Pinho P, Finco S, Pinho C (2013) Overview of the Brazilian centre for natural disaster monitoring and alerts (CEMADEN) In: Proceedings of the Fifth International Conference on Management of Emergent Digital EcoSystems, 302–305.. ACE, New York, USA, doi:10.1145/2536146.2536193.View ArticleGoogle Scholar
  24. Alvalá RC, Camarinha PIM, Canavesi V (2013) Landslide susceptibility mapping in the coastal region in the state of São Paulo.Google Scholar
  25. Halonen T, Romero J, Melero J (eds)2004. GSM, GPRS and EDGE performance: evolution towards 3G/UMTS. John Wiley & Sons, Chichester, UK. ISBN: 0-470-86694-2.Google Scholar
  26. Messer H, Zinevich A, Alpert P (2006) Environmental monitoring by wireless communication networks. Science 312(5774): 713–713.View ArticleGoogle Scholar
  27. Leijnse H, Uijlenhoet R, Stricker JNM (2007) Rainfall measurement using radio links from cellular communication networks. Water Resour Res 42(3).Google Scholar
  28. Matricciani E (1997) Prediction of fade durations due to rain in satellite communication systems. Radio Sci 32(3): 935–941.View ArticleGoogle Scholar
  29. Habibi E, Krajewski WF, Kruger A (2001) Sampling errors of tipping-bucket rain gauge measurements. J Hydrol Eng 6(2): 159–166.View ArticleGoogle Scholar
  30. Wang J, Fisher BL, Wolff DB (2008) Estimating rain rates from tipping-bucket rain gauge measurements. J Atmos Ocean Technol 25(1): 43–56.View ArticleGoogle Scholar
  31. Haan CT, Allen DM, Stret JO (1976) A Markov chain model of daily rainfall. Water Resour Res 12(3): 443–449.View ArticleGoogle Scholar
  32. Richardson CW (1981) Stochastic simulation of daily precipitation, temperature, and solar radiation. Water Resour Res 17(1): 182–190.View ArticleGoogle Scholar
  33. Semenov MA, Barrow EM (1997) Use of a stochastic weather generator in the development of climate change scenarios. Clim Chang 35(4): 397–414.View ArticleGoogle Scholar
  34. Martina MLV, Todini E, Libralon A (2006) A Bayesian decision approach to rainfall thresholds based flood warning. Hydrol Earth Syst Sci 10(3): 413–426.View ArticleGoogle Scholar
  35. Ritchie DM (1993) The development of the c language. ACM SIGPLAN Not 28(3): 201–208.View ArticleGoogle Scholar
  36. Stroustrup B (1986) An overview of C++ In: ACM SIGPLAN Notices, 7–18.. ACM, New York, USA.Google Scholar
  37. Wilks DS (1989) Rainfall intensity, the Weibull distribution, and estimation of daily surface runoff. J Appl Meteorol 28(1): 52–58.View ArticleMathSciNetGoogle Scholar
  38. Foresman TW (ed)1998. The history of geographic information systems. Prentice Hall, New Jersey, USA. ISBN: 0138621454.Google Scholar
  39. Martin-Escalona I, Barcelo F, Paradells J (2004) Hybrid location systems: delivering non-standardized assistance data in GSM-GPRS networks. Eur Trans Telecommun 15(2): 111–116.View ArticleGoogle Scholar
  40. Phillips BD, Morrow BH (2007) Social science research needs: Focus on vulnerable populations, forecasting, and warnings. Nat Hazards Rev 8(3): 61–68.View ArticleGoogle Scholar
  41. Gandhewar N, Sheikh R (2010) Google Android: an emerging software platform for mobile devices. Int J Comput Sci Eng 1(1): 12–17.Google Scholar
  42. Hemalatha S, Bharanthi JM, Nagar E (2010) Advancement in mobile communication using Android. Int J Comput Appl 1(7): 95–98.Google Scholar
  43. Jindal G, Jain M (2012) A comparative study of mobile phone’s operating systems. Int J Comput Appl Inf Tech 1(3): 10–15.Google Scholar
  44. King P (2014) Q4 2014 Tablet operating system installed base by 88 Country Forecast 2010-201, Strategy Analytics. https://www.strategyanalytics.com/access-services/devices/tablets/tablets/market-data/report-detail/q4-2014-tablet-operating-system-installed-base-by-88-country-forecast-2010-2018?Related#.V0spePkrK00. Accessed 29 May 2016.
  45. Miller KW, Voas J, Costello T (2010) Free and open source software. IT Prof 12(6): 14–16.View ArticleGoogle Scholar
  46. Zapata BC (2013) Android studio application development. Packt Publishing Ltd, Birmingham, UK. ISBN: 978-1-78328-527-4.Google Scholar
  47. Horstmann CS, Cornell G (2002) Core Java 2: Volume I, Fundamentals. Seventh Edition. Sun Microsystem Press, Santa Clara, USA. ISBN: 0-13-148202-5.Google Scholar
  48. Agrawal S, Gupta RD (2014) Development and comparison of open source based Web GIS Frameworks on WAMP and Apache Tomcat Web Servers. Proc Int Arch Photogramm Remote Sens Spat Inf Sci 4: 1–5.View ArticleGoogle Scholar
  49. Berners-Lee T, Connolly D (1995) Hypertext markup language-2.0. http://www.hjp.at/doc/rfc/rfc1866.html. Accessed 29 May 2016.
  50. Gibson R, Erle S (2006) Google maps hacks. O’Reilly Media, Inc, Sebastopol, USA. ISBN: 0-596-10161-9.Google Scholar
  51. Salmanzadeh R (2002) Using libcurl in Visual Studio. Version 1.0. http://curl.haxx.se/libcurl/c/visual_studio.pdf. Accessed 29 May 2016.
  52. Raynal M (2012) Concurrent programming: algorithms, principles, and foundations. Springer Science & Business Media, London. ISBN: 978-3-642-32026-2.MATHGoogle Scholar
  53. Nielsen J, Budiu R (2012) Mobile usability. New Riders Press, Berkeley, CA. ISBN: 0-321-88448-5.Google Scholar
  54. Ji YG, Park JH, Lee C, yun MH (2006) A usability checklist for the usability evaluation of mobile phone user interface. Int J Hum Comput Interact 20(3): 207–231.View ArticleGoogle Scholar
  55. Muthu K, Petrou M (2007) Landslide-hazard mapping using an expert system and a GIS. IEEE Trans Geosci Remote Sens 45(2): 522–531.View ArticleGoogle Scholar
  56. Canuti P, Focardi P, Garzonio CA (1985) Correlation between rainfall and landslides. Bull Int Assoc Eng Geol-Bulletin de l’Association Internationale de Gé, ologie de l’Ingénieur32(1): 49–54.View ArticleGoogle Scholar
  57. Guidicini G, Iwasa OY (1977) Tentative correlation between rainfall and landslides in a humid tropical environment. Bull Int Assoc Eng Geol-Bulletin de l’Association Internationale de Gé, ologie de l’Ingénieur16(1): 13–20.View ArticleGoogle Scholar
  58. De Paor DG, Whitmeyer SJ (2011) Geological and geophysical modeling on virtual globes using KML, COLLADA, and Javascript. Comput Geosci 37(1): 100–110.View ArticleGoogle Scholar

Copyright

© Xavier et al. 2016