1 Introduction
2 Design of processes for crisis resolution
2.1 Identification of high-level objects from text
2.1.1 Principles
(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
-
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
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 |
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
2.2.1 Principle of process discovery via \(\alpha \)-algorithm
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 |
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\)
|
2.2.2 Application to Ho Chi Minh plan scenarios
2.3 BPMN representation of a plan for stakeholder validation
3 Mapping from process models to organization models
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
-
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.
3.2 Deriving BDI-agent
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
-
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.