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 [2–7]. 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 [21–23]: 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
figure 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

Full size image

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
figure 2

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

Full size image

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
figure 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

Full size image

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 [31–33];

  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
figure 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

Full size image
Table 1 Type and variable descriptions used in Fig. 4 a
Full size table
Table 2 File and function descriptions for the diagram in Figs. 4 b and 5
Full size table

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
figure 5

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

Full size image

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
figure 6

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

Full size image
Table 3 DTR-ADS scores and standard deviation according to Nielsen methodology [53]
Full size table

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 [41–43] 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
figure 7

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

Full size image

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
figure 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

Full size image
Fig. 9
figure 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

Full size image

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
figure 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

Full size image

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
figure 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

Full size image

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).