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
Shipwreck in baltic sea
A passenger ship sinks into the Baltic sea in between Swdish and Polish territory, dut to an engine fire.
The use case 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 response, 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).
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.
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.