Discovering crisis models to help assess coordination plans

Abstract

Recently, we have witnessed an increasing number of crises, not only natural disasters but also man-made ones. Coordination among several stakeholders is the key factor to reduce the damage caused by a crisis. However, the plan for coordination can be expressed under various representations, including textual format—the most used one in reality but hard to analyze its efficiency. We consider in this paper a combination of process and organization aspects of a coordination plan. Process models (e.g Petri Net, Business Process Model and Notation) could be used to capture the processes of activities and messages exchanged between the actors involved in a crisis, while organization models (e.g. Role graph, agent-centred multi-agent system, organization centred multi-agent system) are used to highlight the roles, their interactions and the organizational structures. We then describe a proposal that allows performing an automatic transformation from process models to organization models. Our proposal is illustrated with a coordination plan for tsunami response, given by People Committee of Ho Chi Minh City (HCMC), Vietnam.

1 Introduction

Crisis situations such as natural disasters with environmental consequences impose the coordination of numerous stakeholders: firemen, medical organizations, police, etc. In the context of crisis resolution, coordination plans could be examined under different representations. The mostly used representation in reality is the textual format that has several drawbacks [1]. Its ambiguity makes the coordination among stakeholders difficult. Moreover, it cannot support the direct and autonomous analysis or simulation. Another possible representation of coordination is a process model, e.g. a Business Process Model and Notation diagram (BPMN) as shown in [1]. This diagram, built by analyzing an official textual plan, can support process simulation and analysis [2] due to process complexity, end-to-end process time, resources costs, etc.

Recently, we have witnessed an increasing interest in research aiming at modelling and simulating complex systems (such as Crisis Management) using multi-agent paradigm, i.e the micro aspect. Multi-agent system (MAS) could be separated by agent-centred multi-agent system (ACMAS), i.e. focusing on the individual aspect, and organization centred multi-agent system (OCMAS), i.e. focusing on the social aspect [11]. In our opinion, MAS currently lacks the means to design and visualize the whole system behaviour, i.e the macro aspect. Regarding software engineering, before the implementation, we must perform the design phase to have an overview of studied system. Thus, we argue that multi-agent paradigm should follow this way.

For that reason, the idea of combination between business process and multi-agent system has been raised to improve agent-based design [6] as well as to allow performing divers analysis based on the strong sides of both paradigms (e.g. control-flow complexity metric for process model [14], organizational structure for OCMAS [13], etc.). Process models could be considered as additional components of agent ones, since they can provide means to represent an aggregate view of an MAS behaviour. In addition, process models share several concepts with MAS. Therefore, we believe that the marriage of Process- and Agent models is suitable to design an efficient coordination in complex system [7], such as crisis management, by improving the quality of coordination plan. While stakeholders and their behaviours may be described by agents, the crisis resolution plan is amenable to a process representation.

The work presented in this paper follows a life cycle shown in Fig. 1 to transform from process models (Petri Net, BPMN) to organization models (Role graph, ACMAS and OCMAS). More precisely, we use the Agent-Group-Role (AGR) model proposed by [11] as an OCMAS representation and BDI-Agent as an ACMAS representation.

Fig. 1

Life cycle of mapping from process models (Petri Net, BPMN) to organization models (Role graph, ACMAS and OCMAS)

Our contribution in this paper consists in the definition of a mapping framework for coordination models in crisis response. We provide the guidelines of transformation among five complementary views (Petri Net, BPMN, Role graph, BDI-agent and AGR). Even if our work examines a concrete case (i.e. the tsunami response plan of Ho Chi Minh City, Vietnam), our approach can be applied to any coordination plan.

This paper is organized as follows. We first give two process representations (Petri Net and BPMN) detected from our tsunami response plan in Sect. 2. Section 3 will present the mappings from process models to organization models (Role graph, ACMAS and OCMAS). Then we provide related works about the process-agent transformation and organizational structure assessment in Sect. 4. Finally, we conclude our work with some perspectives.

2 Design of processes for crisis resolution

We propose a method to design process models of crisis resolution that have the following characteristics (cf. Fig. 2):

• 1. It is composed of four steps with possible iterations following the validation of stakeholders.

• 2. The identification of high-level objects take action in support of a meta-model of simple crises (cf. Fig. 2).

• 3. It is organized around scenarios that correspond to possible plan of crisis resolution.

• 4. It exploits a process mining technique called $\alpha$ -algorithm [5] to derive the process of crisis resolution (i.e. a Petri Net with special properties) from scenarios.

Fig. 2

A scenario-based life cycle for process design and validation from text

2.1 Identification of high-level objects from text

2.1.1 Principles

The designer must extract from text the top-level objects and the links existing between them. It should be based on the meta-model we propose in Fig. 3. This meta-model is simple enough allowing to extract essential concepts to describe the coordination of activities. There are in the literature more detailed models [3] but the usage may prove to be difficult because it is impossible in reality to dispose of all theoretical information they contain (risk probabilities, gravity factor, etc.).

Fig. 3

Meta-model to represent coordination of activities during crisis management

We prefer here to limit ourselves on high-level concepts, easily identified in the text and that allow derive models of simple processes giving an aggregated view of the plan. The designers, associated with the stakeholders, can then refine the process by proposing scenarios. Although, the analysis of text is supposed here manually but the techniques for automatic text analysis has actually emerged [4] and could be used with profits to extract the elements of our meta-model.

Our meta-model records the tasks and the roles and/or organizations who are in charge of these roles. An organization can contain others and a hierarchy relationship then exists between them. The tasks realize the objectives to reduce or resolve the risks (potential or proven). The tasks may have constraints between them (precedence or choice, etc.) and the causal links: the effect of a task (post-condition) may be exploited by another (pre-condition). The constraints and causal links are given in the Table 1. The tasks can take two forms (communication or action). In the second case, we record the receivers of the communication.

Table 1 Basic relations and constraints between tasks

2.1.2 Illustration of identifying organizations, tasks and their relationships from HCMC’s Plan

In fact, we have identified in this HCMC’s plan over thirty organizations and numerous duties for each one. For legibility reason, we gathered some organizations with similar responsibilities or missions in a more abstract organization. Sometimes organizations share a common role: for example police and military have the first-responder role and as such they have both the mission of evacuating people and informing and transferring injuries people to safe places. We will not detail here the different roles but only the tasks and the organizations.

The organization Local Administration represents actually four organizations: (1) Committee for Flood–Storm Prevention and Search–Rescue of HCMC, (2) People’s Committee of Districts, Communes and Towns, (3) Chairman of People’s Committee of Districts, Communes and Towns, and (4) Command Center of Program against Flooding of HCMC.

The organization Communication Unit gathers three organizations: (1) Department of Information and Communication, (2) Television station of HCMC, and (3) Radio Voice of HCMC.

The organization Military represents three organizations: (1) High command of HCMC, (2) Border Guard High Command of HCMC, and (3) Border Guard Forces.

The organization Police substitutes for two organizations: (1) Police of HCMC, and (2) Department of Police about Fire Prevention and Fire fighting of HCMC.

The organization Health and Red Cross gathers three organizations: (1) Department of Health, (2) Center for Preventive Medical, and (3) Red Cross of City.

And finally the organization Local Civil Defence Forces represents two organizations: (1) Local Civil Defence Forces and (2) Young Volunteers Force of HCMC.

As a result, during period of response and search–rescue, seven organizations are considered:

• O1: Institute of Geophysics (Vietnam Academy of Science and Technology)

• O2: Local administration

• O3: Military

• O4: Police

• O5: Local civil defence forces

• O6: Communication unit

• O7: Health and Red cross

We have translated the response plan from Vietnamese into English and produce a summary where we mention the organizations, their tasks and the relations among tasks: an assumed case study of tsunami response plan in HCMC.

Table 2 provides a synthesized view of the tasks and their corresponding performers, extracted from the above case study.

Table 2 Tasks and their corresponding performers (actors) in tsunami response plan

The constraints and causal relations between tasks can be identified in the text by temporal terms such as meanwhile, so that, after, finally, at the same time. We obtained the results reported in Table 3.

Table 3 Relations and constraints between tasks

2.2 Process discovering and representation by means of Petri nets

The constraints and causal relationships between tasks allow us to generate and then select scenarios’ response to the crisis. They are linear and then the objective is able to synthesize all of these scenarios in a single process capable of playing each scenario and explaining clearly the choices and the parallelism between tasks. We will use for this the $\alpha$-algorithm [5] which allows to deduce a Petri net from a log file.

2.2.1 Principle of process discovery via $\alpha$-algorithm

The log file includes different scenarios also called cases. In our context, we propose a log file in tabular form and with the following structure: (ScenarioId, Task, Performer, Receiver(s), Timestamps). Performer is the organization that performed the tasks while Receiver is the possible receiver of the task if the task is a communication. Table 4 illustrates the structure of a scenario contained in a log file.

Table 4 The structure of Scenario 1 (26 events) contained in an event log

The algorithm is based on the relation of succession between tasks that it infers three other relationships (see Table 5). The relationship of Direct Succession between tasks is more restrictive than the task before seen previously in Sect. 2.1.1 because it indicates a relation of succession without intermediate.

Table 5 Relations between tasks in the $\alpha$-algorithm

We now detail the different steps of $\alpha$-algorithm. Let W be a workflow log on T (a set of tasks). $\alpha (W)$ is constructed according to the Algorithm 1. The first instruction builds set of transitions from the tasks appearing in the log file W. The instructions 2 and 3 calculate $T_I$ and $T_O$, respectively. $T_I$ designates set of tasks starting a case (scenario). $T_O$ designates a set of tasks ending a case. The instruction 4 calculates the set $X_W$ of pairs of tasks (A, B) whose elements are in causal relationships. The tasks within A have a relationship of choice between them and it is the same within B. The instruction 5 calculates a minimum subset $Y_W$ of $X_W$. The instruction 6 calculates the places $P_W$ that connect pairs of set of transitions of $Y_W$. The instruction 7 calculates the arcs and finally instruction 8 returns the expected result $(P_W, T_W, F_W)$.

2.2.2 Application to Ho Chi Minh plan scenarios

We retain the following six scenarios to consider the crisis response plan of Ho Chi Minh City:

• 1. Scenario 1 (26 events): T1. T2. T3. T5. T4. T11. T8. T10. T9. T13. T7. T14. T12. T8. T6. T16. T17. T18. T22. T20. T19. T24. T20. T23. T21. T25.

• 2. Scenario 2 (26 events): T1. T2. T3. T4. T5. T9. T6. T7. T11. T8. T8. T12. T13. T14. T10. T16. T17. T18. T20. T23. T22. T21. T19. T20. T24. T25.

• 3. Scenario 3 (26 events): T1. T2. T3. T4. T5. T8. T8. T13. T14. T10. T6. T12. T11. T9. T7. T16. T17. T18. T20. T22. T21. T19. T24. T20. T23. T25.

• 4. Scenario 4 (26 events): T1. T2. T3. T5. T4. T8. T7. T9. T6. T11. T12. T13. T10. T14. T8’. T16. T17. T18. T21. T20. T23. T24. T20. T19. T22. T25.

• 5. Scenario 5 (26 events): T1. T2. T3. T4. T5. T7. T6. T12. T10. T8. T8’. T9. T13. T14. T11. T16. T17. T18. T20. T23. T19. T21. T24. T20. T22. T25.

• 6. Scenario 6 (26 events): T1. T2. T3. T5. T4. T7. T8. T13. T11. T12. T8. T6. T15. T10. T9. T16. T17. T18. T20. T21. T24. T19. T20. T22. T23. T25.

When applying $\alpha$-algorithm with above scenarios, we discover a Petri Net of Fig. 4 that we have redrawn to underline the different organizations involved in our tsunami response plan.

Fig. 4

Petri Net representation of Ho Chi Minh City tsunami response plan

In a reverse manner, from this Petri Net, we can generate all possible scenarios and then use as input cases (of an event log file) to verify the conformance of process. The technique to build a process corresponding to an event log is called Process Mining [5].

2.3 BPMN representation of a plan for stakeholder validation

BPMN is a standard notation, proposed by the Object Management Group (OMG), for modelling business processes. We consider here a core subset of BPMN elements as shown in Fig. 5.

Fig. 5

Core subset of BPMN elements

BPMN representation of plan is useful for validation by stakeholders since it integrates an organizational perspective not present in conventional Petri Nets. It is not only easy to read but also available to simulate and analyze the results. In our context, there are two ways to obtain a BPMN representation:

• 1. By mapping the Petri Net discovered from the scenarios onto a BPMN diagram and complete it by organizational elements.

• 2. The other possible way is to analyze the text and/or the scenarios and draw it directly.

We present in Fig. 6 the relations between the concepts of Petri Nets and BPMN (sequential, parallelism, synchronization, exclusive choice, or merge).

Fig. 6

Mapping Petri Net concepts onto BPMN concepts

Using this table, the concepts of Petri Net can be transformed easily into BPMN ones. We need the Petri Net formalism to verify formal theoretical properties (reachability of particular states, termination, liveness, etc.) and perform simulations. We also implemented the mapping from Petri Net to BPMN using ATL¹ technology on top of two meta-models. In fact, the source model of the mapping (cf. our Petri Net in Fig. 4) is expressed under a PNML² file containing two separate pages (i.e processes).

As the result of mapping, Fig. 7 shows the BPMN model representing HCMC’s tsunami response plan. This model obviously eases accountability and awareness. The BPMN model describes some adaptations to put also temporal constraints.

Fig. 7

BPMN representation for tsunami response plan

Eight stakeholders can be identified from our Petri Net with reference to the identification of high-level objects from text (cf. 2.1), depicted by two pools (corresponding to two pages of the PNML file) and six lanes with their flow of tasks and mutual interactions.

Some parallel structures between tasks are detected from our Petri Net according to mapping table in Fig. 6, e.g. [T3, T4, T5] corresponding to [X, Y, Z] respectively, [T4, T6, T7], [T5, T6, T7], [T4, T7, T8], [T5, T7, T8], etc. We notice that the Military, Police and Health and Red Cross organizations are supposed to perform their tasks in parallel. In this case, each organization should be distributed over the parallel tasks according to a given policy (proportional distribution, distribution according to the importance given to each task, ...).

In addition, an exclusive choice structure is detected from our Petri Net (cf. Fig. 4) regarding to the relationships of T13, T14 and T15. The Health and Red Cross organization has to choose to carry out only one task among two possible ones.

We can identify, in the process model, eight participants represented by rectangular boxes, called Swimlane Objects (aka: Swimlanes). Besides, to visualize coordination process, we use the activity notation (like T1: Detect tsunami risk), represented by a rounded-corner rectangle. These activities are connected by the Connectors such as Sequence Flow and Message Flow, and the Flow Objects like Start Event, Intermediate Event, End Event. Moreover, the control structures help to coordinate the different activities, such as parallelism (diamond including $``+''$) or alternatives (diamond with $``\times ''$).

When the same task is done by two different actors, it is duplicated instead of creating an abstract actor including both actors. In our BPMN diagram (cf. Fig. 7), for example, we express the task Evacuate people realized by two actors (Military and Police) by two tasks T8 and T8’, respectively. Indeed each actor has its own view of tasks, links with partners or situation of extra-works. Moreover, three tasks T8, T9 and T10 are performed in parallel by Military and they require probably more resources and high responsibility. Our BPMN model is, therefore, considered as a shared artefact that could be used for negotiation of resources or improve coordination for similar tasks done by different organizations.

3 Mapping from process models to organization models

The coordination among stakeholders, in general, can be represented by several formats such as text, process diagram, conventional graph, etc. Each of them expresses some aspects of the coordination plan but they differ from one another in terms of abstraction level, precision and expressive power. Combining various representations helps us to have an overall view of the crisis management. The advantages of each representation is given in Table 6.

Table 6 Advantages of some representations of a coordination plan

3.1 Deriving Role graph

The Role graph aims at analyzing the properties of the organization involved in crisis plan, notably its robustness, flexibility and efficiency as done in [2]. The process model thus can be used to build a Role graph corresponding to our tsunami respond plan. This type of representation describes the roles and the relationships between them. Following the typology introduced by Grossi et al. [13], we can distinguish three types of relations: power which corresponds to task delegation; coordination which represents flow of information among actors; control relation between actors: actor A controls actor B if A monitors agent B activities. Regarding the mapping rules, the roles correspond to the name of lanes (or pools without lane) in a process. For the relationships between roles, we met a difficult problem. Because the lanes’ relationships are not defined clearly in a BPMN diagram. Hence, we propose three patterns to detect three types of relation by analyzing the semantics of BPMN Connectors (Sequence Flow, Message Flow) as follows:

• Power relation: if we detect that a pool/lane A has only one-direction message/sequence flows to another pool/lane B, we could assume that there is a power relation from A to B. For example, as depicted in Fig. 8, the lane A connects with lane B by two sequences flows and there is no flow in the opposite direction. Thus, we could conclude that the role A has a power relation with the role B.

• Coordination relation: if we identify a pool/lane A has bidirectional message/sequence flows to another pool/lane B, we could assume that there is a coordination relation between A and B, as illustrated in Fig. 9.

• Control relation: if we detect that a pool/lane A has bidirectional message/sequence flows for all tasks of another pool/lane B, we could assume that A controls B, as illustrated in Fig. 10.

Fig. 8

Pattern of Power relation between two actors

Fig. 9

Pattern of Coordination relation between two actors

Fig. 10

Pattern of Control relation between two actors

We provide here in this paper only one approach to derive the Role graph based on BPMN patterns. In addition, Artefact elements could be used to describe directly (by text) the Power, Coordination or Control relations. However, it cannot assure that when designing a process model, the users will supply this relation information.

Based on three proposed patterns, we analyze our BPMN diagram to build its corresponding Role graph. Seven roles are detected: IG for the pool Institute of Geophysics, LA for the lane Local Administration, LCDF for the lane Local Civil Defence Forces, CU for the lane Communication Unit, M for the lane Military, P for the lane Police and HR for the lane Health and Red Cross. Moreover, the pool Institute of Geophysics sends two message flows to the lane Local Administration and there is no flow in opposite direction (Fig. 11). Therefore, we create a Power Relation from Institute of Geophysics to Local Administration.

Fig. 11

Relation between the pool Institute of Geophysics and the lane Local Administration

The lane Local Administration has bidirectional sequence flows for all tasks of lane Local Civil Defence Forces (Fig. 12), Communication Unit, Military, Police and Health and Red Cross. Therefore, we create Control Relations from Local Administration to Local Civil Defence Forces, Communication Unit, Military, Police and Health and Red Cross.

Fig. 12

Relation between the lane Local administration and lane Local civil defence forces

As the result, the derived Role graph based on three above patterns is depicted in Fig. 13, each circle corresponds to a role. The role IG has Power relation with the role LA. While the role LA has five Control relations with the roles P, M, HR, CU, LCDF. We detect no Coordination relation from our BPMN diagram.

Fig. 13

Role graph corresponding to our BPMN diagram

3.2 Deriving BDI-agent

This transformation is based on the work in [10] with some extensions. A BDI-Agent is defined as a tuple $\Delta$ $=$ (id,  P,  G,  I,  B). Deriving BDI-Agent from a process model contains nine steps, corresponding to nine rules presented in [10], with the aid of additional information.

• 1. Step 1: Each pool is considered as an agent ($\Delta$)

• 2. Step 2: The plan (P) for agent is initiated

• 3. Step 3: The input list of process (P.In) is completed with start events

• 4. Step 4: The output list of process (P.Out) is completed with end events

• 5. Step 5: The embedded sub-process activities are transferred to another plans of agent ($P'$)

• 6. Step 6: The independent sub-process activities are mapped to goals of agents (G)

• 7. Step 7: The elements with Send and Receive messages are appended to plan’s script (P.Script)

• 8. Step 8: The data flows (additional information of pools) are mapped to the belief of agents (B)

• 9. Step 9: The control flows (gateways) are considered to orchestrate the structure of agents’ plan with AND, OR, XOR structure

Table 7 shows the result of mapping from Business Process to BDI-Agent model containing nine steps and additional data. Finally, two BDI-type agents are detected with their attributes (Plan, Belief).

Table 7 Mapping from business process to BDI-agent for tsunami response plan

3.3 Deriving AGR model

An organization centred multi-agent system (OCMAS) view, as proposed by Ferber et al. [11], eases macro-simulation regarding the organization and also micro-simulation if agent behaviors are specified. In [11], the authors have introduced a meta-model Agent/Group/Role, called AGR where: “(1) an Agent is an active communicating entity which plays several roles within several groups; (2) a Group is defined as atomic sets of agent aggregation, each agent is part of one or more groups; (3) a Role is an abstract representation of agent function, service or identification within a group and role has some attributes such as constraints (obligations, requirements, skills), benefits (abilities, authorization, profits) or responsibilities$''$. Based on the proposition of Ferber et al., we define $AGR = (A,G,R)$, as follows:

• A is a collection of agent. Each agent is tuple (NameA, T, Rs, Gs) where NameA is its identifier; T is its type (reactive or intentional agents); Rs is the list of roles this agent can play; Gs is the list of groups to which this agent may belong.

• G is a collection of groups. Each group is couple (NameG, Rs) where NameG is its identifier; Rs is the list of roles involved in this group.

• R is set of roles where a role is tuple (NameR, C, B, D, Pc, I) where NameR is its identifier; C is the list of constraints (obligations, requirements, skills); B is the list of benefits (abilities, authorization, profits); D is the list of duties or responsibilities; Pc is the pattern of communication or interaction; I is the list of useful information.

To complete the process-agent mapping, we also define some notations, as follows: x.send(y, m) means agent x sends message m to agent y; x.Start means agent x initiates his state and/or work; x.Do(act) means agent x performs the activity act; x.Wait(time) means agent x has to wait for a time; x.End means agent x terminates his work.

We consider a lane or a pool without lane as a role. A group constitutes a context of interaction for agents. Hence, we consider two cases: (1) each pool with more than one lane becomes a group; (2) for each message flow between two pools A and B, we create also a new group where the role A and B can be played. Regarding agents, they are not given by the BPMN diagram but by some additional information (comments) giving the number of occurrences of each roles. Thus, we just have to create as much agent by role as indicated in the additional document.

Our mapping from process model to AGR model consists five steps, as follows.

• 1. In step 1, we identify the roles and groups extracted from BPMN diagram. Let us illustrate this step through our tsunami response case study. We have the first pool $O^{P}(1)$ where $O^{P}(1).name = ``$ Institute of Geophysics $''$ and it has no lane; therefore, we consider it as a role R(1). On the contrary, for the second pool $O^{P}(2)$ where $O^{P}(2).name = ``$ Ho Chi Minh City $''$, it has six lanes: $O^{L}(1)$ ($O^{L}(1).name = ``$ Local Administration $''$), $O^{L}(2)$ ($O^{L}(2).name = ``$ Local Civil Defence Forces $''$), $O^{L}(3)$ ($O^{L}(3).name = ``$ Communication Unit $''$), $O^{L}(4)$ ($O^{L}(4).name = ``$ Military $''$), $O^{L}(5)$ ($O^{L}(5).name = ``$ Police $''$) and $O^{L}(6)$ ($O^{L}(6).name = ``$ Health & Red Cross $''$). Thus, we transfer them, respectively, to six roles R(2), R(3), R(4), R(5), R(6) and R(7). All these six roles belong to group G(1).

• 2. In step 2, we obtain the information extracted from the Artefact elements to identify roles’ properties.

• 3. In step 3, by analyzing additional data, we identify the agents’ attributes such as their type, the number of agents playing a role, the number of agents belonging to a group, etc.

• 4. In step 4, we identify the communication or interaction protocols between groups and create new possible groups by analyzing message flows. In our case study, we create a new group G(2) based on the message flows between two roles R(1) and R(2).

• 5. Finally, in step 5, we identify the roles’ activities by following sequence flows.

As the result, we have two groups and seven roles with their attributes and interactions, as shown in Table 8 (see Appendix). R(2) is the only role which belongs to two groups.

4 Related works

In [11], authors highlight the software engineering benefits of differentiating agent aspect (the Agent-Centred Multi-Agent System or ACMAS) from social aspect (the Organization-Centred Multi-Agent System or OCMAS). They presented the essential drawbacks which cannot be solved with ACMAS. Instead of using ACMAS, Ferber et al. attempt to view complex system under the eye of organizational structure. They propose the Agent/Group/Role meta-model (AGR) as a means to combine efficiently these two aspects in a uniform framework. In our work, we use this meta-model as the destination of the process-agent mapping.

In [10], Endern et al. described the mapping from BPMN to agents using an agent-centred approach (ACMAS). The agents are represented according to the Believe-Desire-Intention (BDI) type, which is in our opinion not fully compliant with BPMN model where the notion of goal and intention are not given. Authors consider that sub-processes determine goals which in our point of view is a strong assumption. They also do not count on the lane concept during the mapping. In our approach, we do not use an ACMAS approach since we believe that an organizational view (OCMAS) [11] is more compliant with BPMN.

In [6, 7], the authors presented a model to text transformation (M2T), from BPMN model to a specific agent-oriented language (JADE). This work is too much specific so that we cannot extend it to other languages. On the contrary, we follow a model to model approach (M2M). Thus, the destination model (AGR) can be implemented by any agent-based language.

In [8, 9], Onggo introduced a BPMN pattern used to represent agent-based models. He developed specific BPMN diagrams to describe activities of agents according to an ACMAS approach. In our work, we can use an arbitrary BPMN diagram and map it to the corresponding agent model, based on an OCMAS approach.

In [12], the authors described the mapping from BPMN models to Alvis language to formally verify these models. However, the transformation which focuses on the activities forgets the organizational structure.

Concerning the organization assessment, Grossi et al. in [13] proposed a set of equations to evaluate organizational structure based on the Role graph with three dimensions: power, coordination and control. Comparing the results with standard values, we can determine the robustness, flexibility and efficiency of our organization. All these metrics can be performed in our Graph Role as we have demonstrated it in [2].

In [14], the author presented a metric to measure control-flow complexity of a workflow or a process. He also suggested other metrics such as Activity Complexity, Data-Flow Complexity, and Resource Complexity. These metrics, combined with the equations of Role graph [2, 13], can help us determine the quality of a coordination plan according to two points of view: process and organization.

5 Conclusion

In this paper, we have introduced an approach to map from process models (Petri Net, BPMN) to organization models (Role graph, ACMAS, OCMAS). Combining several views of the same plan enables the authorities to benefit from the advantages of each representation. This work is the first step towards a visualization and assessment platform for Crisis Management. In a future research, we will continue on developing the assessment part of the different models, illustrated in this paper, using a set of static and dynamic metrics.

Appendix: Mapping table

See Table 8.

Table 8 Mapping process model to AGR model for tsunami response plan