Case Study | Flood Alert

Home / Flood Alert

 
 

About the client

 
The project was developed for Consiliul judetean Caras Severin (Caras Severin County Council) as part of a European Union regional development project.
 
 

Overview

 
Flood Alert is a platform that monitors hydrological information in a predefined territory. The system includes an information management component that gathers and centralizes information from regional collecting station regarding water levels, precipitation levels, water temperature, air temperature, etc. Via a mobile component, an alert system informs deciding factors in case specific
critical parameters record significant fluctuations or deviates from optimal levels.
 
 

Challenge

 
The project has a broad target group and multiple data sets with potentially unlimited interests related to the incidents
and multiple parameters types to monitor. Thus, the Alert Manager component has to be very flexible in order to adapt its functions over time to different and diverse requirements that could be raised by those target users.
 
Also the incident definition and severity could be different from one target group to another. A mandatory behavior for the global system is to be pro-active and to inform – without a human intervention – persons and institutions with different interests/levels of responsibility if a given information is present into the solution data set. The system security is a key issue and this is why all system users have to be authenticated before logging in. The real time aspect is also extremely important because decisions have to be take in seconds. The right and accurate information have to be delivered to the right users as fast as it is available into the system.
 
 

Solution

 
The goal of the Flood Alert system is to react as soon as certain predefined events take place/happen and to send notifications to a list of interested target groups if such an event occurs. During the monitoring and simulation activities performed by a dedicated software application, certain measurement parameters and – based on them – simulated parameters will be collected.
 
The Alert Manager component will use these major data sets in order to create, configure and send alert messages (and to initiate actions flows) to specific previously defined users.
 
The main components of the system are:
 
Event Monitor – Server type component that – based on the events definition – starts a new event if the definition conditions is / are fulfilled;
 
Event Manager – Will manage the events raised by Event Monitor component and communicate with an Event Client component in order to send specific information for active events;
 
Event Client – Mobile and PC “fat client” – Communicate with the Event Manager. Receive event related information (data and status). Display relevant information in a drill-down manner.

The subsystem has to have a modular structure and architecture. Modularity in design and development but also in deployment are very important aspects due to the fact that, in time, the subsystem has to handle larger data sets and multiple stations as well. Also due to such a deployment architecture, the real time system behavior can be much more easily fulfilled.

The three leading mobile platforms were considered when building the application: Android, iOS, and Windows. Other operating systems could be targeted with minor changes in the application code and only specific, platform dependent sections will have to undergo an adaptation process.

The application design, which includes UI (User Interface) and UX (User Experience) principles and respects multiple paradigms used across all platforms to better integrate the required flows. These rules allow the user to easily use the application and insure that vital information is displayed at all times across the different flows available.
 
 

Conclusion

 
Mobile users such as mayoralty, water management authorities and emergency situation authorities will be notified in real time about events that will occur in detailed manner with many parameters related to what triggered an event.

Also notifications are sent gradually, based on real data in real time. Before the system that dispatch the event information is strongly oriented on human interaction and there were delays and misunderstandings due to sequential information management.
 
 

Ongoing

 
Raw data collection from measurement stations has to be very flexible due to the fact that additional measurement stations will be added in the future from possibility different manufacturers and with different measurement sensors. This way flexibility in defining and also parsing raw information is key for extended the system in the future.

Different data types, lengths, formats have to be supported. Also dynamic data formats have to be detected and parsed in order to find relevant information out of the raw data. The system will be extended in the future in order to incorporate all these features.