Smart levee monitoring and flood decision support system: reference architecture and urgent computing management Bartosz Baliś, Tomasz Bartynski, Marian Bubak, Daniel Harezlak, Marek Kasztelnik, Maciej Malawski, Piotr Nowakowski, Maciej Pawlik, Bartosz Wilk AGH University of Science and Technology Department of Computer Science Kraków, Poland ICCS 2015, Reykjavik, Iceland

Agenda Motivation ISMOP project: IT system for smart levee monitoring and flood decision support Holistic approach to urgent computing management I will present the broader context of this research which is the ISMOP project.

Motivation Predict levee failures using smart levees Typical flood scenario in Lesser Poland region: flood threat due to passing water wave High water levels lasting up to several weeks Need for urgent computing in large-scale scenarios

Levee monitoring: traditional approach Piezometer: an instrument for measuring the pressure of a liquid or gas, or something related to pressure (such as the compressibility of liquid). Piezometers are often placed in boreholes to monitor the pressure or depth of groundwater.

Smart levees Sensor monitor temperature pore pressure

Data analysis (1): anomaly detection trend anomaly

Data analysis (2): threat estimation via numerical modeling Prediction of levee response to certaing water levels in current external conditions Numerical models require geotechnical and geophysical levee examination

ISMOP project overview ISMOP: an IT system for smart levee monitoring and flood decision support Construction of an experimental levee Design and installation of sensors Innovative telemetry system Model- and data-driven modeling of levee behavior Monitoring and decision support system We are addressing such flood threat scenarios in the research project ISMOP (TODO: NCBIR)

ISMOP experimental smart levee Size: 200mx50mx4m, 4 types of material 1200 sensors (temperature and pore pressure) Two optic fibre sensors

Controlled flooding experiments

Urgent computing scenario Assess flood threat risk for large area (50+ km) of levees Compute results by a specified deadline Provide levee health maps for all levee sections The urgent computing scenario occurs when we have to deal with a larger scale The water wave can be quite long (50, 100km) Even though we’re doing research on a small experimental levee, we’re designing the system to scale… We divide the levees into logical sections. We assume in each there are sensors.

ISMOP IT system for smart levee monitoring and flood decision support

Decision support workflow Multiple tiers of data analysis, activated as alert level rises Anomaly detection: 1st indication about a potential problem Threat estimation: more in-depth analysis of anomalous sections in order to assess threat of levee failure (e.g. levee breach simulations) Risk assessment: estimate impact of levee breach (e.g. simulations of inundation, crowd behavior)

Decision support workflow: implementation

Holistic approach to urgent computing management System reconfiguration loop Isolated approach Holistic approach

System management SLA (service-level agreement): requried level of quality of service the system has to deliver SLAs become optimization objectives SLAs vary depending on system mode Normal mode: conserve energy, save costs Urgent mode: high performance, high accuracy of data measurement and analysis, deadlines

IT system for smart levees: reference architecture and objective functions OPC (Operating Cost) SLT (System Lifetime) EE (Energy Efficiency) DPI (Data Processing Interval) DPT (Data Processing Time) DAT (Data Access Time) DTI (Data Transmission Interval) DMI (Data Measurement Interval)

Configurable properties

Service profiles in normal and urgent modes Service profile defines: SLAs: functional constraints imposed upon the objective functions Trade-offs: which objectives should be preferred?

Objective functions models Based on experimental research and literature review, we have created approximate models of three objective functions: Function q1: OPC (Operating Cost) Function q2: EE (Energy Efficiency) Function q3: TML (Timeliness – aggregated measure of system performance and responsiveness) where qi: (s,c)  [0,1] s: system configuration (a vector of configuration options for all system components) c: system context (e.g. weather conditions) 0: minimal possible value, 1: maximal possible value

Decision support workflow: implementation

Holistic urgent computing management: algorithm

Results Pareto-optimal solutions, normal mode

Results Pareto-optimal solutions, urgent mode

Conclusion Holistic urgent computing management leads to more optimized system configuration than the isolated approach Future work: Evaluate public cloud services for urgent computing