# Gathering, Structuring and Modeling Business Process Knowledge of the Response to a Nuclear Crisis: Towards a Simulation Platform for Better Coordination

Aurelie Charles, Matthieu Lauras, Anne-Marie Barthe-Delanoë, Frederick

Benaben

► To cite this version:

Aurelie Charles, Matthieu Lauras, Anne-Marie Barthe-Delanoë, Frederick Benaben. Gathering, Structuring and Modeling Business Process Knowledge of the Response to a Nuclear Crisis: Towards a Simulation Platform for Better Coordination. 12th Working Conference on Virtual Enterprises (PROVE), Oct 2011, São Paulo, Brazil. pp.486-493, 10.1007/978-3-642-23330-2_53. hal-01570556

HAL Id: hal-01570556

https://inria.hal.science/hal-01570556

Submitted on 31 Jul 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Gathering, Structuring and Modeling Business Process Knowledge of the Response to a Nuclear Crisis: Towards a Simulation Platform for Better Coordination

Aurélie Charles¹, Matthieu Lauras¹, Anne-Marie Barthe¹ Frédérick Bénaben¹

¹ Université de Toulouse, Mines Albi, route de Teillet, 81013 Albi cedex, France
{aurelie.charles, matthieu.lauras, anne-marie.barthe, benaben}@mines-albi.fr

**Abstract.** This paper illustrates how nuclear crisis are managed in France. It proposes IT solutions dedicated to event management that could help to resolve such a crisis by facilitating coordination between actors and increasing situational awareness. This study has been conducted as part of the European project PLAY. Requirements have been collected from different stakeholders through reviews of the literature, internal reports and websites, and interviews. Our proposal consists in the construction of a simulation tool to validate the complex-event processing architecture and the associated platform. The aim is to show the potential added value from the PLAY platform in the context of the response to a nuclear crisis.

**Keywords:** Complex-event processing, distributed systems, crisis management, modeling, collaboration

## 1 Introduction

A large quantity of radioactive substance is accidentally released in the atmosphere, due to a critical accident in a French nuclear plant. To resolve this crisis, a lot of heterogeneous actors may be involved. The services provided by these actors are also diverse and varied, ranging from psychological assistance to traffic duty. This heterogeneity is probably the main cause of the difficulty to manage such a crisis situation. But there are many other difficulties to cope with. For instance, there are a lot of critical dependencies between the actions of these heterogeneous actors. A decision to evacuate will depend on the actual level of radioactivity measured, but also on weather forecasts and assessments of the situation in the nuclear plant. Collaborative processes describe the chronology of activities but also how activities might be pre-condition or post-condition for each other's. Besides, crisis situations are obviously the kind of context where agility, especially reactivity and flexibility, is one critical point. It is crucial that workflows and actions remain perfectly adapted to the situation and its possible changes. Japan's last disaster provides many examples of the vital importance of timely and accurate diffusion of information between actors, but also toward population.
To help to resolve such a crisis, our research work consists in developing IT solutions that could facilitate coordination between actors. We have chosen to develop a simulation tool that should be used with the complex-event processing architecture and the associated platform designed and built within the framework of the ongoing European project PLAY [14]. The main benefit of using the platform built for PLAY is that the management of the crisis would be facilitated by the increased situational awareness provided by the platform. In addition to that, the platform would ensure a timely and adequate diffusion of information to relevant actors. All these characteristics make this nuclear use case an accurate illustration for Internet of Services, although it is not easy to imagine this context as a strongly computed environment where services could easily send their events to the clouds.

To reach this goal, we have developed a two-step approach. The first step is to gather knowledge about the current situation and to propose a structured analysis of the situation, as it would be if PLAY platform was used to facilitate the management of the crisis (process description and analysis). The second step is to build a tool to simulate various collaborative workflows, actors' behavior, and event production.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Nuclear Crisis Use Case, Actors and Events</figcaption></figure>

This article develops this approach in order to turn the whole “natural language” use case description into a set of relevant, representative and usable business process models containing the numerous pieces of information, interactions and events to take into account in such a situation. In order to build a simulation tool dedicated to run the nuclear crisis example use case, we have to identify and characterize all the involved services and the events generated by these services from heterogeneous partners. At this condition, we will be able to experiment the elastic and reliable architecture for dynamic complex event driven interaction of the PLAY proposal.

Concretely, the purpose of this part of the research work is to collect data and identify the processes of realization, in order to identify specific requirements for each of them. Specifically, this analysis will identify the strengths and weaknesses of the
current situation in order to successfully acquire end-user requirements. But as many stakeholders are involved in the crisis management process (see. Figure 1), discussions with IRSN, France's public service expert in nuclear and radiation risks as well as with Nuclear plants technical experts or field actors such as firemen are undergoing. A review of the literature, available reports and websites has also complemented those discussions. See [11] [4] [2] [5] among others.

## 2. The Nuclear Crisis Cell: a Need for a Interoperable IT Platform

To resolve the crisis, many stakeholders are involved. The crisis cell, in charge of operation, is managed by the prefect (representative of the national authority), outside the nuclear plant. Inside the nuclear plant, the company in charge of the plant is managing operations. Delegates of each actor are present in the crisis cell. Firemen, policemen, and any other actor involved in the response processes has one representative in the crisis cell, to validate the feasibility of decisions, link with the field and ensure communication between actors. Consequently, this crisis cell is distributed. Most of the decisions are made locally, where prefect and delegates are gathered, but decisions may also come from the national authority, local or national responsible of the nuclear plant or experts. (See. figure 2).

<figure><img src="image_3.png" /><figcaption>Fig. 2. Distributed crisis cell and actors</figcaption></figure>

This distributed cell, combined with the lack of a proper IT system to ensure timely and accurate exchange of information often results in delays or inconsistency at many levels. No one has a clear awareness of the situation or a precise knowledge of all latest information. For example, mid-March 2011 in Japan, many dysfunctions regarding communication of information have been deplored. "Employees confirmed
a second blaze at the reactor, but it took another 35 minutes for them to inform a fire station in nearby Tomiokamachi" [13]. "Complicating matters, a lack of phone service meant that they had little input from upper management" [3]. Japan's prime minister deplored that "though there was a direct broadcast of explosions on national TVs, it took [TEPCO, the electric power company] more than an hour to inform the government." [8] A few days later, communication had not improved. For example, it took nine hours between the publication of an sky-high level of 134 iodine, which created panic among international experts, and the communication of corrected values, without any information on the new number, except that it was "under the limit" nor any explanation on why the first figure was wrong. [1]

**3. Step 1: Gathering and Structuring Knowledge**

We have chosen to follow a Business Process Modeling approach to implement our research work. Consequently, in this first step, our objective consists in transforming the three classical levels of business processes that exist in any system (decisional, operational and support processes) in workflows in order to support the agility of both orchestration (internal business processes) and choreography (interactions between actors) of the coordination.

Concretely, to resolve the nuclear crisis described in introduction, seven sub-processes have been identified and divided into the three levels evoked before (see figure 1).

1. Strategic level - To manage nuclear crisis: This first level is dedicated to present the decisional part of the process cartography. It concerns decision taking during the crisis management.

2. Operational level - To resolve nuclear accident and its consequences: This second level deals with the concrete operational part of the process cartography. It concerns mainly the actions performed on the crisis site.

3. Support level - To support nuclear crisis response: This last level concerns the supporting activities dedicated to provide means to other processes and to ensure logistic aspects of the crisis management.

From the seven business processes identified during the global analysis, we decided to focus our attention only on the five that concentrate the main coordination problems. Concretely, those business processes concern activities that occur outside the nuclear plant. Moreover, decisions and operations within the plant are not managed by the same authority than the rest of the crisis. They also depend on the nuclear plant itself, and the technology it uses. Furthermore, those operations are really technical, not always available, and does not affect the rest of operations (radioactive measurements and provisions are sufficient).

Those business processes are as follow:

1.2 To plan and control relief process and means (Decisional)

2.2 To protect population (Operational)

2.3 To provide aid to employees and population (Operational)
3.2 To back relief operations (Support)

3.3 To assess situation (Support)

From these five business processes, we detailed sixteen sub-processes, as described in figure 3.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Low-level structure: 16 sub-processes identified</figcaption></figure>

4. Step 2: Supplying the Simulation Platform with Events

In our case of nuclear crisis management, the scenario is very complex and as explained before, a lot of sub-processes are involved. We plan to simulate this use case through a demonstration platform able (i) to run all these sub-processes in a Service Oriented Architecture (SOA) context, and (ii) to simulate the CEP platform.

Implementing a real exercise implying all the expected actors, services and events is not an easy task. The simulation tool compensates this difficulty and enables the validation of the complex-event processing architecture. We suppose that a business service matches with a single technical operation (i.e. a single operation of a WebService).
The demonstration platform provided will be based on SOA principles [10] and on the ESB PETALS [7]. Such a technical infrastructure requires describing processes as workflows in a runnable language (for instance BPEL, Business Process Execution Language [6]). In order to make that task easier and to ensure coherence into the whole approach, all the sub-processes will be described with BPMN language (Business Process Modeling Notation) [9][12]. Furthermore, this language is not only strongly aligned with computer implementation of workflows but also structurally event-oriented (events are represented through circles and can be typed). BPMN is so perfectly at the intersection between PLAY project specificities (event-based) and technical requirements of the demonstration platform to be provided (proximity between BPMN and workflow language). Figure 4 shows one of the BPMN built for this project.

<figure><img src="image_5.png" /><figcaption>Fig. 4. One example of BPMN – To protect population</figcaption></figure>

## 6. Motivations

Three main elements make this use case a relevant illustration for Internet of Services, although it is not easy to imagine this context as a strongly computed environment where services could easily send their events to the clouds:
* The heterogeneity of actors is taken into account. Actors involved operate with their own information system, which may already use web services, but may also be fairly basic.

* High volumes of heterogeneous information is exchanged

* Changes in orchestration (internal business processes) or in choreography (interactions between processes) are possible. and driven by events

With its complex-event processing architecture, European project PLAY can contribute significantly. The management of the crisis would indeed be facilitated by the increased situational awareness provided by PLAY's platform for event processing. In addition to that, PLAY would ensure a timely and adequate diffusion of information to relevant actors.

**Acknowledgements.** This study is part of a project, PLAY, supported by the European Commission through the Seventh Framework Programme. We would like to thank all the partners for their involvement.

## 8. References

1. Ané, C. Tepco accumule les erreurs de communication. LeMonde.fr. http://www.lemonde.fr/japon/article/2011/03/28/tepco-accumule-les-erreurs-de-communication_1499820_1492975.html. (2011)

2. ASN. Les situations d'urgence - Autorité de sûreté nucléaire. http://www.asn.fr/index.php/S-informer/Dossiers/Les-situations-d-urgence.

3. Belson, K. Panic and Heroism Greeted Crisis at Japan Nuclear Plant. The New York Times (2011) http://www.nytimes.com/2011/03/31/world/asia/31workers.html?_r=1&src=recg.

4. IRSN. CODIR-PA Présentation de deux scénarios d'accident affectant une centrale nucléaire française. (2007)

5. IRSN. IRSN - Expert in nuclear and radiological risk. http://www.irsn.fr/EN/Pages/home.aspx.

6. Jurič, M.B., Mathew, B., et Sarang, P. Business Process Execution Language for Web Services. Packt Publishing Ltd. (2006)

7. Konstantas, D., Bourrières, J.-P., et Léonard, M. Interoperability of enterprise software and applications. Springer. (2006).

8. Mesmer, P. Tepco, une entreprise trop sûre d'elle-même. LeMonde.fr (2011) http://www.lemonde.fr/japon/article/2011/03/16/tepco-une-entreprise-trop-sure-d-elle-meme_1493754_1492975.html.

9. OMG. BPMN. http://www.omg.org/spec/BPMN/2.0/PDF/.

10. Touzi, J., Benaben, F., Pingaud, H., et Lorré, J.P. A model-driven approach for collaborative service-oriented architecture design. International Journal of Production Economics 121, 1, 5-20. (2009)

11. Trémeur, M. et Lencznar, V.-A. Communes et agglomérations face aux risques naturels et technologiques. Editions du Papyrus, (2006)

12. White, S.A. et Miers, D. BPMN Modeling and Reference Guide: Understanding and Using BPMN. Future Strategies Inc. (2008)