You must log in in order to see contact information. If you don't have an account, you can ask for one on this form.
IO-DA solution enhances situation assesment by providing different modelers.

On the one hand, the information about the situation is brought thanks to the use of dedicated modelers: · Partner modeler: This modeler allows the crisis manager to model stakeholders that can be mobilized in case of crisis situation and their capabilities. · Context modeler: The models obtained with this modeler present characteristics of the impacted systems, including goods, people, intrinsic risks and any other specific feature. · Objective modeler: This third modeler is dedicated to describe precisely the crisis situation. The obtained models contain mainly objectives to satisfy (as missions) which are basically based on effects to treat (like injured people to evacuate or fire to extinguish) or risks to prevent (like building collapse or tank explosion). This model could be seen as a map on a GIS. On the other hand, the IO-DA embeds an inference engine, which allows the user to apply different strategies to deduce, from the previous models, collaborative process models. Regarding deduction strategy, for the moment, only one simple strategy has been implemented as a set of business rules to deduce collaborative process models, but the current work is about implementing more complex strategies embedding doctrine and law principles.

Supported Use Cases


As a user, I would like to have the correct procedure to follow in order to solve the of a fire. 

Given the knowledge of the actors able to intervene (and what actions they are actually able to perform), of the context (geographic area, infrastructure etc), and when we receive objectives (like an alert: there is a fire there, then), we would like to have as an output of IODA the BPMN process of how to answer to the objective (here, how to stop the fire). 

B should send a file with the alert's details to IODA. Then IODA will use this information to provide the answer process.

Related CM functions

Shipwreck in baltic sea

A passenger ship sinks into the Baltic sea in between Swdish and Polish territory, dut to an engine fire.

The focuses on the arrival of the first victims at the Polish landing site: they to be taken in charge by medical staffs and transported to the relevant infrasctructures with regard to their medical state. In this context, IODA, which is built on a Model Drivern Engineering paradigm, illustrates how a coordination scheme, to support at best the cross-organizational collaboration that is required, can be automatically deduced from three types of knowledge: (i) the context, (ii) the potential partners' capabilities and (iii) the objectives of the collaboration (i.e. what needs to be solved in the ).

This knowledge is provided in two times:

  • aheand of the , by populating the knowledge based system with experts knowledge and procesudres
  • during the response: by humanly modeling the ' objectives that need to be tackled

Ahead of the crisis: Populate knowledge-base

Considering the decision-makers that will use the and their location, both context and partners models are predefined as they correspond either to experts knowedge (especially for the partners model) and geographical data (especially context).

Partners model
Partners model
Context model
Context model




The crisis occurs: Define objectives of the crisis

Once the crisis occurs, and the decision makers need to promptly define a cross-organizational coordination plan for everyone to efficiently act and execute their tasks in the right order, the IODA deduction can be used.

Concretely, the first step consists in providing a third model to the software: the objectives of the crisis response. This is basically a way to quickly define which are the risks and dangers and what their impacts on the context model's elements.

objectives model
Objectives model


Here it is, all has been promptly and quickly defined: the system knows: WHO is able to provide which services, WHERE the crisis is happening and the corresponding socio-geographical context and WHAT is happening.

One more last step before deducing automatically the coordination plan between all potentially involved actors in the response: based on their strong experience and expertise, the decision makers KEEP their ability to evaluate the priority over the objectives i.e. they sort all risks and dangers from the most urgent to the less ones.

Then IODA deduction service finally infers which are the capabilities that need to be executed (and consequently, by who thanks to the partners model), in which order (with regards to the later priorization). Basically, in our case, here is a deduced coordination process, proposed to the Polish decision-makers to evacuate victims that are waiting at the shipwreck landing site.

Coordination model to orchestrate
Detailed coordination model: it provide a BPMN-formated process that invokes all required partners tasks and their order (always parallelized when priorization allows).
Complete coordination model
The coordination process to evacuate the landing site invokes four partners' capabilities.


Related CM functions

  • 0
  • 1
  • 2
eu Portfolio of Solutions web site has been initially developed in the scope of DRIVER+ project. Today, the service is managed by AIT Austrian Institute of Technology GmbH., for the benefit of the European Management. PoS is endorsed and supported by the Disaster Competence Network Austria (DCNA) as well as by the STAMINA and TeamAware H2020 projects.