|
|
|
ISyCri
is a project funded by the french Research Agency (ANR for Agence
Nationale de la Recherche). It deals with information systems
interoperability and coordination in the context of crisis
management.
Objectives
In a crisis context (natural disaster, crash, conflict, industrial accident etc.), different actors from different organizations (medical units, police, NGO, etc.) have to work simultaneously in a hurry. Their cooperation and their ability to coordinate their actions is an essential means to reach their common goal: crisis reduction. The point of ISyCri project is to provide partner organizations involved in the crisis management cell a Mediation Information Systems (MIS) able to merge their respective heterogeneous and autonomous Information Systems (IS) into a global System of Systems (SoS).
This MIS, as the linking support between ISs have to meet the two mains requirements: (i) providing a fast and efficient link between ISs (in order to ensure responsiveness) and (ii) following the unavoidable evolutions of the crisis by remaining adapted and rightly dedicated to the – possibly changing – group of involved partners working on the crisis (in order to ensure flexibility). Thus the MIS design should deliver an agile result (agile can be seen as the result of responsiveness and flexible).
In order to meet those objectives, the ISyCri project plans to set up a global crisis metamodel. The exploitation of this metamodel is based on two ontologies: the first one allows the crisis cell to characterize the situation and the available resources, while the second one is dedicated to deduce (from the knowledge gathered in the first one) the collaborative reaction processes (that will be used to design the collaborative workflow, orchestrated by the MIS). Exploiting that situational knowledge, a Model-Driven Enginering (MDE) approach dive into abstraction layers (using model transformation rules and tools) in order, first to design logical and technological models of the MIS (dedicated to the previous “business” situation model) and second, to deploy the PEtALS ESB, embedding the good services and orchestrating the good collaborative workflow (with possible interruptions and reorientations).
Global principle of ISyCri project
We believe that integration of partners is a crucial step on the way of success in crisis reduction. Our point is to propose to solve this issue of integration of partners by the means of ISs interoperability. According to InterOp , Interoperability is the ability of a system or a product to work with other systems or products without special effort from the customer or user. For us, Interoperability can be seen as the collaborative maturity level (of organizations) adapted to integration, which can be seen as the ultimate collaboration level (of network).
Ensuring partners’ ISs interoperability is not a trivial issue. We believe it is rational to tackle this topic on the base of existing partners’ ISs (another approach could propose to rebuild partners’ ISs). The goal of ISyCri is to provide a method of MIS design. The two crucial needs of responsiveness and flexibility (i.e. agility) must be covered.
Starting from the characterization of the situation, the crisis ontology gives a model (which could be enriched and validated) of a deduced collaborative process: the CIM. A model transformation mechanism use this CIM to build (in UML or a specific DSL) the logical view of the MIS: the PIM. Concurrently, the ESB targeted technologic platform is modeled: the PM. A projection (logic to technology) provides a MIS computable model: the PSM. Furthermore, this design method must include the way to support agility (such as loops in the method).
Contents of ISyCri project
Obtaining such a MIS design framework implies to divide the whole ISyCri project into several tasks which provide the needed elements to support the MIS design method itself. Those tasks can be listed as follow:
Objectives
In a crisis context (natural disaster, crash, conflict, industrial accident etc.), different actors from different organizations (medical units, police, NGO, etc.) have to work simultaneously in a hurry. Their cooperation and their ability to coordinate their actions is an essential means to reach their common goal: crisis reduction. The point of ISyCri project is to provide partner organizations involved in the crisis management cell a Mediation Information Systems (MIS) able to merge their respective heterogeneous and autonomous Information Systems (IS) into a global System of Systems (SoS).
This MIS, as the linking support between ISs have to meet the two mains requirements: (i) providing a fast and efficient link between ISs (in order to ensure responsiveness) and (ii) following the unavoidable evolutions of the crisis by remaining adapted and rightly dedicated to the – possibly changing – group of involved partners working on the crisis (in order to ensure flexibility). Thus the MIS design should deliver an agile result (agile can be seen as the result of responsiveness and flexible).
In order to meet those objectives, the ISyCri project plans to set up a global crisis metamodel. The exploitation of this metamodel is based on two ontologies: the first one allows the crisis cell to characterize the situation and the available resources, while the second one is dedicated to deduce (from the knowledge gathered in the first one) the collaborative reaction processes (that will be used to design the collaborative workflow, orchestrated by the MIS). Exploiting that situational knowledge, a Model-Driven Enginering (MDE) approach dive into abstraction layers (using model transformation rules and tools) in order, first to design logical and technological models of the MIS (dedicated to the previous “business” situation model) and second, to deploy the PEtALS ESB, embedding the good services and orchestrating the good collaborative workflow (with possible interruptions and reorientations).
Global principle of ISyCri project
We believe that integration of partners is a crucial step on the way of success in crisis reduction. Our point is to propose to solve this issue of integration of partners by the means of ISs interoperability. According to InterOp , Interoperability is the ability of a system or a product to work with other systems or products without special effort from the customer or user. For us, Interoperability can be seen as the collaborative maturity level (of organizations) adapted to integration, which can be seen as the ultimate collaboration level (of network).
Ensuring partners’ ISs interoperability is not a trivial issue. We believe it is rational to tackle this topic on the base of existing partners’ ISs (another approach could propose to rebuild partners’ ISs). The goal of ISyCri is to provide a method of MIS design. The two crucial needs of responsiveness and flexibility (i.e. agility) must be covered.
Starting from the characterization of the situation, the crisis ontology gives a model (which could be enriched and validated) of a deduced collaborative process: the CIM. A model transformation mechanism use this CIM to build (in UML or a specific DSL) the logical view of the MIS: the PIM. Concurrently, the ESB targeted technologic platform is modeled: the PM. A projection (logic to technology) provides a MIS computable model: the PSM. Furthermore, this design method must include the way to support agility (such as loops in the method).
Contents of ISyCri project
Obtaining such a MIS design framework implies to divide the whole ISyCri project into several tasks which provide the needed elements to support the MIS design method itself. Those tasks can be listed as follow:
1.
Ontology building: It is crucial to build, first, a crisis ontology.
This ontology should be organized with two parts: the studied system
(including people, natural site, goods, etc.) and the crisis
characterization (containing elements of crisis identification, such as
type, gravity, trigger, etc.). Second, it is necessary to build a
response ontology. This ontology should represent the treatment system
deployed to reduce the crisis as well as the collaborative process
executed. By linking semantically these two ontologies we aim at
building a global crisis ontology providing a way to deduce adequate
collaborative processes from crisis descriptions. The obtained
process(es) should obviously be completed and/or validated
by experts (crisis expert or member of the collaborative network) in
order to become the CIM.
2. Logical modeling of MIS: Extracting the embedded knowledge from collaborative process(es) model (CIM) in order to design the logical model (PIM) can be seen as a model transformation task. We already have some results on this field (in industrial collaboration situations) which can easily be extended in crisis context. This work is especially focused on SOA approach.
3. Technical Modeling of architecture and projection from logical view to technological view: We believe ESB can be a pertinent candidate for an adequate technological platform. It is essential to study and to model the structure of such a tool in order to provide the PM. Furthermore, mechanisms of projection of logical view (PIM) onto this technical view (PM) should also be established.
4. Study of the dynamic part: The keystone of the added-value of the ISyCri project is the ability of the MIS to follow changes of the crisis situation. This capacity can be carried by several levels: the process engine could be flexible enough to support evolutions of the dynamical model of the network. This is flexibility at the implementation level. We can also imagine to bring flexibility at any MDA levels (PSM, Projection, PIM, CIM). An iterative approach can be an idea to bring a “loop” in the design process (on precise looping criteria). This study remains obviously a critical task of the ISyCri project.
5. Experimentation: Such a task is a generic part of this kind of project. It will be based on specific use-cases in order to check the described principles.
The five tasks listed below correspond to the four work packages of ISyCri project:
2. Logical modeling of MIS: Extracting the embedded knowledge from collaborative process(es) model (CIM) in order to design the logical model (PIM) can be seen as a model transformation task. We already have some results on this field (in industrial collaboration situations) which can easily be extended in crisis context. This work is especially focused on SOA approach.
3. Technical Modeling of architecture and projection from logical view to technological view: We believe ESB can be a pertinent candidate for an adequate technological platform. It is essential to study and to model the structure of such a tool in order to provide the PM. Furthermore, mechanisms of projection of logical view (PIM) onto this technical view (PM) should also be established.
4. Study of the dynamic part: The keystone of the added-value of the ISyCri project is the ability of the MIS to follow changes of the crisis situation. This capacity can be carried by several levels: the process engine could be flexible enough to support evolutions of the dynamical model of the network. This is flexibility at the implementation level. We can also imagine to bring flexibility at any MDA levels (PSM, Projection, PIM, CIM). An iterative approach can be an idea to bring a “loop” in the design process (on precise looping criteria). This study remains obviously a critical task of the ISyCri project.
5. Experimentation: Such a task is a generic part of this kind of project. It will be based on specific use-cases in order to check the described principles.
The five tasks listed below correspond to the four work packages of ISyCri project:
1. Work Package 1: Crisis characterisation and ontology-based collaborative process design (task 1).
2. Work Package 2: Technological architecture (task 2 and 3). Task 2 is included in work package 3 because of the results we already obtained.
3. Work Package 3: Providing flexibility of the MIS (task 4).
4. Work Package 4: Experimentation (task 5).
2. Work Package 2: Technological architecture (task 2 and 3). Task 2 is included in work package 3 because of the results we already obtained.
3. Work Package 3: Providing flexibility of the MIS (task 4).
4. Work Package 4: Experimentation (task 5).
