Advertisement

Vietnam Journal of Computer Science

, Volume 4, Issue 2, pp 97–110 | Cite as

Discovering crisis models to help assess coordination plans

A case study of tsunami response plan given by Ho Chi Minh City, Vietnam
  • Nguyen-Tuan-Thanh Le
  • Chihab Hanachi
  • Serge Stinckwich
  • Tuong-Vinh Ho
Open Access
Regular Paper
  • 1.2k Downloads

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.

Keywords

Coordination representation Business process modelling Multi-agent system Organization-centred multi-agent system Role graph Mapping process to multi-agent system Crisis management 

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. 1.

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

     
  2. 2.

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

     
  3. 3.

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

     
  4. 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

(C1) Before (A, B)

Means A should occur before B

(C2) Choice (A, B)

Means we have the exclusive choice between performing A or B

 

A decision procedure is supposed to exist to perform the choice

(C3) Fill (T1, p, T2)

T1 produces p that is used by T2, and T1 should occur before T2

 

P is a post-condition of T1 and pre-condition of T2

(C4) Parallel (T1, T2)

T1 could be performed in parallel with T2

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

Tasks

Org.

T1: Detect the risk of tsunami

O1

T2: Inform tsunami warning

O1

T3: Receive tsunami warning

O2

T4: Mobilize forces, materials, facilities

O2

T5: Direct evacuation task

O2

T6: Inform people using portable speakers

O5

T7: Broadcast tsunami info

O6

T8: Evacuate people

O3

T8’: Help to evacuate people

O4

T9: Fire signal to warn the ships

O3

T10: Inform the fishermen to safe places

O3

T11: Protect people’s property

O4

T12: Ensure the order and safety

O4

T13: Mobilize doctors, nurses, rescue teams, facilities, equipments

O7

T14: Perform the first aid

O7

T15: Call ambulance for serious cases

O7

T16: Inform end of tsunami

O1

T17: Receive end of tsunami

O2

T18: Direct to overcome the consequences

O2

T19: Recover communication system

O6

T20: Identify damages

O3

T21: Search distress fishermen

O3

T20’: Help to identify damages

O4

T22: Ensure the public order and safety

O4

T23: Support health services, disease prevention

O7

T24: Verify ADN sample of anonymous victims

O7

T25: Close tsunami response

O2

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

T1 before T2

T2 before T3

T3 before T4, T5

T4 \(\parallel \) T5

T6, T7, T8, T9, T10, T8’, T11,

T12, T13, T14, T15 after T5

T6 \(\parallel \) T7 \(\parallel \) T8 \(\parallel \) T9 \(\parallel \) T10 \(\parallel \)

T8’ \(\parallel \) T11 \(\parallel \) T12 \(\parallel \) T13

T14, T15 after T13

T14 or T5

T2 before T16

T16 before T17

T6, T7, T8, T9, T10, T8’, T11,

T12, T13, T14, T15 before T17

T17 before T18

T19, T20, T21, T20’, T22,

T23, T24 after T18

T19 \(\parallel \) T20 \(\parallel \) T21 \(\parallel \) T20’ \(\parallel \)

T22 \(\parallel \) T23 \(\parallel \) T24

T19, T20, T21, T20, T22,

T23, T24 before T25

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

Sid

Task

Performer

Timestamps

1

T1

Inst. of Geo.

2016-02-25 16:04:20

1

T2

Inst. of Geo.

2016-02-25 17:04:20

1

T3

Local Admin.

2016-02-25 18:04:20

1

T5

Local Admin.

2016-02-25 19:04:20

1

T4

Local Admin.

2016-02-25 20:04:20

1

T11

Police

2016-02-25 21:04:20

1

T8

Military

2016-02-25 22:04:20

1

T10

Military

2016-02-25 23:04:20

1

T9

Military

2016-02-26 00:04:20

1

T13

Health and Red Cross

2016-02-26 01:04:20

1

T7

Communication Unit

2016-02-26 02:04:20

1

T14

Health and Red Cross

2016-02-26 03:04:20

1

T12

Police

2016-02-26 04:04:20

1

T8’

Police

2016-02-26 05:04:20

1

T6

Local Civil D. F.

2016-02-26 06:04:20

1

T16

Inst. of Geo.

2016-02-26 07:04:20

1

T17

Local Admin.

2016-02-26 08:04:20

1

T18

Local Admin.

2016-02-26 09:04:20

1

T22

Police

2016-02-26 10:04:20

1

T20

Military

2016-02-26 11:04:20

1

T19

Communication Unit

2016-02-26 12:04:20

1

T24

Health and Red Cross

2016-02-26 13:04:20

1

T20’

Police

2016-02-26 14:04:20

1

T23

Health and Red Cross

2016-02-26 15:04:20

1

T21

Military

2016-02-26 16:04:20

1

T25

Local Admin.

2016-02-26 17:04:20

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

Direct succession

\(x > y\) iff for some case x is directly followed by y

Direct causality

\(x \rightarrow y\) iff \(x > y\) and not \(y > x\)

Parallel

\(x \parallel y\) iff \(x > y\) and \(y > x\)

Choice

\(x \ne y\) iff not \(x > y\) and not \(y > x\)

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 (AB) 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. 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. 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. 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. 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. 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. 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. 1.

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

     
  2. 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 ATL1 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 PNML2 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

Models

Views and advantages

Petri Net

A directed bipartite graph based on tokens supporting formal semantics and analysis and possibility of macro-simulation

BPMN

An understandable and aggregate representation of stakeholders’ behavior and possibility of analysis and process simulation

Role graph

Focusing on dependency between the roles and enables analysis robustness, flexibility and efficiency of organization structure [2]

BDI-Agent Model

An typical ACMAS representation and possible micro-simulation [10]

AGR

A OCMAS representation and possible macro and micro- simulation

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 \) \(=\) (idPGIB). Deriving BDI-Agent from a process model contains nine steps, corresponding to nine rules presented in [10], with the aid of additional information.
  1. 1.

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

     
  2. 2.

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

     
  3. 3.

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

     
  4. 4.

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

     
  5. 5.

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

     
  6. 6.

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

     
  7. 7.

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

     
  8. 8.

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

     
  9. 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

 

BPMN

BDI-Agent

Step 1

\(O^{P}(1)\)

\(\Delta (1) = (O^{P}(1).name, \) \(P\{\}, G\{\}, I\{\}, B\{\})\)

 

\(O^{P}(2)\)

\(\Delta (2) = (O^{P}(2).name, \) \(P\{\}, G\{\}, I\{\}, B\{\})\)

Step 2

\(Pr(1)=O^{P}(1).process \)

\(\Delta (1).P = (Pr(1).id, In\{\}, Out\{\}, Script\{\}) \)

 

\(Pr(2)= O^{P}(2).process\)

\(\Delta (2).P = (Pr(2).id, In\{\}, Out\{\}, Script\{\}\)

Step 3

Start event \(\Downarrow \) P.In

\(\Delta (1).P.In += (O^{E}_{S}(1).name, O^{E}_{S}(1).type)\)

  

\(\Delta (2).P.In += (O^{E}_{S}(2).name, O^{E}_{S}(2).type)\)

Step 4

End event \(\Downarrow \) P.Out

\(\Delta (1).P.Out += (O^{E}_{E}(1).name, O^{E}_{E}(1).type)\)

  

\(\Delta (2).P.Out += (O^{E}_{E}(2).name, O^{E}_{E}(2).type)\)

Step 5

Embedded activity \(O^{A}_{Sub}\) \(\rightarrow \) P.Script invoke

X

Step 6

Independent activity \(O^{A}_{Sub}\) \(\rightarrow \) P.Script addGoal

X

Step 7

\(O^{A}_{At}\) send message \(\rightarrow P.Script\) send

 
 

\( O^{E}_{I,M}(1)\)

\(M(1)=(``msg_1'', O^{P}(1),\) \(O^{L}(1), [msg\_reg1])\)

  

\(\Delta (1).P.Script \leftarrow \) \(\{send(M(1)\}\)

 

\(O^{E}_{I,M}(2)\)

\(M(2)=(``msg_2'', O^{P}(1), \) \(O^{L}(1), [msg\_reg2])\)

  

\(\Delta (1).P.Script \leftarrow \) \(\{send(M(2)\}\)

 

\(O^{E}_{S,M}(1)\)

\(\Delta (2).P.Script \leftarrow \) \(\{receive(M(1)\}\)

 

\(O^{E}_{I,M}(3)\)

\(\Delta (2).P.Script \leftarrow \) \(\{receive(M(2)\}\)

Step 8

O properties \( \rightarrow B\)

 

Data flow

\(O^{P}(1)\) properties

\(\Delta (1).B \leftarrow \) \(\{O^{P}(1).reg, O^{P}(1).ans\}\)

 

\(O^{P}(2)\) properties

\(\Delta (2).B \leftarrow \) \(\{O^{P}(2).reg, O^{P}(2).ans\}\)

Step 9

  

Control flow

  

Element

Properties

Assignment

\(O^{P}(1)\)

reg: String,

 
 

ans: String

 

\(O^{E}_{S,M}(1)\)

msg_reg: String

 

\(O^{E}_{S,M}(2)\)

msg_reg: String

 

\(O^{P}(2)\)

reg: String,

 
 

ans: String

 

\(O^{E}_{S,M}(1)\)

msg_ans: String

 

\(O^{E}_{S,M}(3)\)

msg_ans: String

 

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 (NameGRs) 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(ym) 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. 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. 2.

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

     
  3. 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. 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. 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.

Footnotes

  1. 1.

    ATL Transformation Language.

  2. 2.

    Petri Net Markup Language.

References

  1. 1.
    Le, N.N.T., Hanachi, C., Stinckwich, S., Vinh, H.T.: Representing, simulating and analysing Ho Chi Minh City tsunami plan by means of process models. In: ISCRAM Vietnam (Information Systems for Crisis Response and Management) (2013)Google Scholar
  2. 2.
    Le, N.N.T., Hanachi, C., Stinckwich, S., Vinh, H.T.: Combining process simulation and agent organizational structure evaluation in order to analyze disaster response plans. In: 9th International KES Conference on Agents and Multi-Agent Systems—Technologies and Applications (2015)Google Scholar
  3. 3.
    Bénaben, F., Hanachi, C., Lauras, M., Couget, P., Chapurlat, V.: A metamodel and its ontology to guide crisis characterization and its collaborative management. In: Proceedings of the 5th International Conference ISCRAM (2008)Google Scholar
  4. 4.
    Viorica Epure, E., Martin-Rodilla, P., Hug, C., Deneckere, R., Salinesi, C.: Automatic process model discovery from textual methodologies. In: Research Challenges in Information Science (RCIS), IEEE 9th International Conference (2015)Google Scholar
  5. 5.
    Van der Aalst, W.M.P.: Process mining: discovery, conformance and enhancement of business processes. In: Springer Publishing Company Incorporated, ISBN 978-3-642-19345-3 (2011)Google Scholar
  6. 6.
    Küster, T., Lützenberger, M., Heßler, A., Hirsch, B.: Integrating process modelling into multi-agent system engineering. In: Multiagent and Grid Systems, vol. 8, no. 1, pp. 105–124. IOS Press, Amsterdam (2012)Google Scholar
  7. 7.
    Küster, T., Heßler, A., Albayrak, S.: Towards process-oriented modelling and creation of multi-agent systems. In: Engineering Multi-Agent Systems, pp. 163–180. Springer, New York (2014)Google Scholar
  8. 8.
    Onggo, B.S.S.: BPMN pattern for agent-based simulation model representation. In: Winter Simulation Conference (WSC), pp. 1–10. IEEE (2012)Google Scholar
  9. 9.
    Onggo, B.S.S.: Agent-based simulation model representation using BPMN. In: Formal Languages for Computer Simulation: Transdisciplinary Models and Applications, pp. 378–399 (2013)Google Scholar
  10. 10.
    Endert, H., Küster, T., Hirsch, B., Albayrak, S.: Mapping BPMN to agents: an analysis. In: Agents, Web-Services, and Ontologies Integrated Methodologies, pp. 43–58 (2007)Google Scholar
  11. 11.
    Ferber, J., Gutknecht, O., Michel, F.: From agents to organizations: an organizational view of multi-agent systems. In: Agent-Oriented Software Engineering IV: 4th International Workshop, AOSE 2003, Melbourne, Australia, pp. 214–230. Springer, Berlin, Heidelberg (2004)Google Scholar
  12. 12.
    Szpyrka, M., Nalepa, G. J., Ligȩza, A., Kluza, K.: Proposal of formal verification of selected BPMN models with Alvis modeling language. In: Intelligent Distributed Computing V: Proceedings of the 5th International Symposium on Intelligent Distributed Computing - IDC 2011, Delft, the Netherlands, pp. 249–255. Springer, Berlin, Heidelberg (2012)Google Scholar
  13. 13.
    Grossi, D., Dignum, F., Dignum, V., Dastani, M., Royakkers, L.: Structural aspects of the evaluation of agent organizations. In: Coordination, Organizations, Institutions, and Norms in Agent Systems II, pp. 3–18. Springer-Verlag, New york (2007)Google Scholar
  14. 14.
    Cardoso, J.: Business process control-flow complexity: metric, evaluation, and validation. In: International Journal of Web Services Research (IJWSR), vol. 5, no. 2, pp. 49–76. IGI Global, USA (2008)Google Scholar

Copyright information

© The Author(s) 2016

Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Authors and Affiliations

  1. 1.IRIT LaboratoryUniversity Paul Sabatier Toulouse IIIToulouseFrance
  2. 2.University of Science and Technology of HanoiHanoiVietnam
  3. 3.IRIT LaboratoryUniversity Toulouse Capitole IToulouseFrance
  4. 4.IRD, UMI 209, UMMISCO, IRD France NordBondyFrance
  5. 5.Sorbonne Universités, Univ. Paris 06, UMI 209, UMMISCOParisFrance
  6. 6.Université de Caen Basse-NormandieCaenFrance
  7. 7.Institute Francophone InternationalVietnam National UniversityHanoiVietnam

Personalised recommendations