Before a simulation cycle commences some preliminary

Before a simulation cycle commences, some preliminary activities are performed such as: establishing key
parameters (e.g., maximum number of simulation cycles, timeouts, water level thresholds), connecting with the
flood sub-simulator, sharing with it the initial topology of the world, and adding connecting peers. Once a

simulation cycle terminates, the controller updates the time-step and starts the next cycle. Notice that, due to the
modularity of the above architecture, it is reasonably easy to add as many disaster sub-simulators (e.g., landslides,
earthquake, volcanic eruption, etc.) as needed;
The Flood-SubSimulator
The flood sub-simulator goal is to simulate a flood in town of Trento (Italy). The equation defined in its core OKC is
based on flooding levels and flooding timings deduced from a work presented in (Alkema, Cavallin, De Amicis and
Zanchi, 2001). This study is based on the digital terrain model of the river Adige valley, on historical hydrological
data of the flood experienced in Trento in 1966, on the localization of ruptures of the river Adige's dikes and on
floodplain topography changes from year 1966 to year 2000.
To the purpose of our test-bed the territory is divided into flooded areas: each area is characterised by the maximum
water height reached during the inundation and the time when this level was touched. We digitalised these flooded
areas from (Alkema et al., 2001) analysis assuming that the time required to reach the maximum flood level was
always one hour. We then stored this digitalised data in different tables in a geographical database. Each table has a
field representing x,y coordinates of digitalized points. At simulation time, only the data of the interested area are
joined in a single table using an Open Geospatial Consortium standard spatial SQL query.
The flood sub-simulator has been developed in Java and it is fully integrated into the OpenKnowledge kernel. The
main component is an OK peer that subscribes to two interaction models. The first interaction model is enacted at
the beginning of the simulation. It shares the topology (e.g., point of interests and roads) of the world between the
controller and the flood sub-simulator peers and stores, in the controller local knowledge, the connection state of the
sub-simulator. The second interaction model is used by the controller at every time step, in order to get from the
flood sub-simulator flood level changes registered at nodes in the topology.
The Visualiser
This component enables the GUI used to visualise the simulation. In particular, the GUI shows the information
provided by the controller through the “visualiser” interaction model. At every time-step, the visualiser receives the
changes and updates its history according to the new information. The update results in a change on the GUI. Figure
6 shows the appearance of the GUI in two simulated scenarios.