Crisis Management Case Study

ToBe Analysis

S-Cube framework

The structure of the S-Cube use case description framework is based on three main parts:

1. Business Goals (BG) and Domain Assumptions (DA): they describe objectives to be pursued (BG) and properties assumed to be true (DA). Each BG or DA is described through a specific table.
2. Domain description: it describes the laws and specificities of the sub-part of the world in which the use case occurs. Usually, this domain description is based on several elements:
   1. A glossary: listing and describing the concepts of the domain.
   2. Domain model(s): describing the relations between concepts of the domain (the ones from the glossary).
   3. Laws: describing specific characteristics of the concepts of the domain (the ones from the glossary).
   4. Strategic dependency diagram and context diagram: describing dependencies and relations between actors of the domain.
3. Scenario description: it is an operational description of the steps of the use case. It is described through tables (one per sub-scenario) containing actors concerned and textual description of the scenario. Furthermore, the sub-scenario might be also described with a model or a diagram.

Furthermore, we believe that an ontology could be built in order to ensure a large part of the domain description as described in section 2.3.5.1. Such an ontology could provide a list and a description of the concepts of the domain (glossary), the relations between these concepts (domain model) and the specific characteristics of these concepts (laws). Concerning the dependencies and relations between actors, a UML use case diagram will be used as described in section 2.3.5.2.

Finally, concerning the scenario description, the expected tables will be provided, completed with BPMN diagram to describe processes, as presented in section 2.3.6.

Source of the problem

The radiation leak in this scenario originates from the combination of two problems:

• The metal of the steam generator is very thin. Due to the wearing effect of time, a leak appeared in the steam generator. As a result, the water within the primary loop, contaminated, spreads through the secondary loop.

Consequences: The steam of the secondary loop is contaminated and the pressure within the secondary loop increases.

• The throttle valve, a safety device of the secondary loop, opens due to the increased pressure inside the secondary loop. It does not respond to the manual bypass of the safety loop, requiring its closure.

Consequences: The steam of the secondary loop, contaminated, escapes from the secondary loop to the atmosphere.

These problems are illustrated by Figure 7.

First problem: leak within the steam generator => contact between primary and secondary loopsThrottle valveSecond problem: throttle valve blocked open

Image source : http://www.nucleartourist.com/images/rcs-c2.jpg Figure 7: Schema of the nuclear plant

Crisis cell and actors

To resolve the crisis, many stakeholders are involved. The crisis cell, in charge of operation, is piloted by the prefect (representative of the national authority), outside the nuclear plant. Delegates of each actor are present in the crisis cell. Firemen, policemen, and any other actor involved in the response process has one representative in the crisis cell, to validate the feasibility of decisions, link with the field and ensure communication between actors. This crisis cell is distributed. Most of the decisions are made locally, where prefects and delegates are gathered, but decisions may also come from the national authority, local or national responsible of the nuclear plant or experts. (Cf. Figure 8). 

Figure 8: Distributed crisis cell and actors

Sequencing of activities

To simulate the response to a nuclear accident, a list of actions to be performed has been created. This table will serve as a basis for the first version of the scenario. Additional elements of complexity of the situation that better show the value added of PLAY system will be developed (see part 2.4 Workplan).

Legend of the table:

Choreography (flow between 2 or more business processes)

Continuous or repetitive task

Timing	Actor	Crisis cell	Sensor	Event type	Event nature	Action	Processes
12h					Leak within the steam generator => contact between primary and secondary loops
12h10	Nuclear Plant Teams (NP1)		pressure in the primary loop	Situation	Detection of the leak	to stop reactor (yet flows within primary and secondary loops continue)
12h11			throttle valve open /close sensor	Situation	Throttle valve opens
12h11	Nuclear Plant Teams (NP1)					to require the closure of the throttle valve
				Situation	throttle valve does not respond to closing order
12h11				Consequence	Risk of radioactive leakage in the atmosphere
12h11	Nuclear Plant Teams (NP1)					to alert responsible of nuclear plant
12h11	Nuclear Plant Teams (NP1)					to send a technician to check valve status and manually close the valve if necessary
12h11	Local responsible of the nuclear plant					to activate PUI
	Radiation Survey Network (NP2)			Situation	Confirmation of the leak	to confirm leak by measurements
	Local responsible of the nuclear plant					to call the representative of local authority (prefect)
	Representative of the local authority					to activate PPI in reflex mode	To manage
	Local responsible of the nuclear plant					to alert populations (siren)	To respond
12h18	Nuclear Plant Teams (NP1)			Situation	Throttle valve confirmed open by technician
	Local responsible of the nuclear plant	EDF local cell				to activate EDF local crisis management cell	To manage
	Local responsible of the nuclear plant					to call the representative of EDF national
	National responsible of the nuclear plant	EDF national cell				to activate EDF national cell	To manage
	Representative of the local authority					to call the representative of national authority
	Representative of the national authority	National authority cell				to activate national authority cell	To manage
13h	Local responsible of the nuclear plant					to contact media to inform that the PUI is activated	To manage
	Representative of the local authority					to alert field actors (firemen, police, army, office of infrastructure, radiation survey network, meteo france, Mobile emergency medical services, mayors)	To manage
12h20		Local authority cell				to define safety perimeter	To manage
12h25	Police (P)			Activity		to position safety perimeter	To respond
		EDF local cell				to keep representatives of local and national authority informed	To manage
12h30	Nuclear Plant Teams (NP1)			Situation	throttle valve blocked open, manual closure failed
every min	Radiation Survey Network (NP2)			Situation		to measure radioactivity level and post information	To support
every min	Meteo France (MF)			Situation		to measure wind force and direction and precipitations + to post information	To support
12h40					throttle valve finally closed
	Local responsible of the nuclear plant					to inform other cells that leak is stopped
	Representative of the local authority	Local authority cell				to receive, synthesize and centralise information of each member of the cell	To manage
	Representative of the local authority					to provide instructions to cell members and spread information received from national authorities	To manage
	All field actors					to inform local authorities about operations updates and difficulties.	To respond
		Local authority cell				to define circulation plan	To manage
	Police (P)			Activity		to implement circulation plan	To respond
	Police (P)			Activity		to block access within the safety perimeter (10km around plant)	To respond
	Radiation Survey Network (NP2)		radioactivity		radioactivity level measured at 10 mSv		To support
	Representative of the local authority					to contact scientific cell to info about high radioactivity measure	To manage
		Scientific cell				to advise local authority cell to tell population to ingest iodine pill and wait for a risk to achieve 50mSv to send evacuation order	To manage
14h	Representative of the local authority					to decide that populations should ingest iodine pills	To manage
14h10	Media					to inform populations that they should ingest iodine pills	To respond
	Mobil Emergency Medical Services (MEMS)			Activity		to distribute iodine pills to impacted population (for those, who did not already have pills)	To respond
	Impacted Population					to ingest iodine pills	To respond
	Radiation Survey Network (NP2)		radioactivity		radioactivity level measured at 20 mSv, increasing => risk to achieve 50mSv soon		To support
	Meteo France (MF)		wind, rain		wind : 5m/s, direction south westrain : 2mm/h		To support
		Scientific cell				to advice about evacuation perimeter and direction
14h30	Representative of the local authority					to decide to evacuate populations	To manage
		Local authority cell				to define evacuation perimeter	To manage
	Mobil Emergency Medical Services (MEMS)			Activity		to assist victims and support psychologically	To respond
	Media					to inform population that they have to evacuate	To respond
	Impacted Population					to make sure their accommodation is safe (switch off heating devices, etc.)	To respond
	Impacted Population					to evacuate by light vehicle or to go to the meeting point for bus evacuation	To respond
	Representative of the local authority			Resource		to requisition buses	To support
15h	Private Companies			Activity		to send buses to meeting point	To respond
15h20	Police (P)				Road works on the main road created a traffic jam	to inform local authority cell that there is a traffic jam on the main road	To respond
		Local authority cell				to modify circulation plan	To manage
15h55					Accident on the secondary road	to inform local authority cell that there is an accident	To respond
16h		Local authority cell				to send firemen to assist victims	To support
16h10		Local authority cell				to re-modify circulation plan	To manage
16h15	Police (P)			Activity		to implement third circulation plan	To respond
16h30	Firemen (F)			Activity		to assist and evacuate victims	To respond

Table 1: Sequencing of activities during the first hours of the crisis

Business goals and Domain Assumptions

Extracted from the edSIPOC model (As-Is description of the use case), the following Business Goals and Domain Assumptions have been selected for the To-Be model:

Table BG1. Business Goal NuclearUC-BG-01
Field	Description
UniqueID	NuclearUC-BG-01
Short Name	To plan and control relief process and means
Type	Business Goals.
Description	To execute Global Emergency Plan (PPI) To mobilize protection and relief resources To communicate with media and local authorities To animate crisis management cell
Rationale	Decisions have to be made to solve as fast as possible the nuclear accident in one hand, and to limit consequences of this accident on the other hand
Involved Stakeholders	Representative of the national authority Representative of the military authority Scientific cell Meteo France Firemen Police Mobile emergency medical service French army Office of infrastructure Media Mobile measurement station
Priority of accomplishment	Must have.

Table BG2. Business Goal NuclearUC-BG-02
Field	Description
UniqueID	NuclearUC-BG-02
Short Name	To protect population
Type	Business Goals.
Description	To alert / communicate To confine To distribute (iodine capsules) To evacuate To forbid
Rationale	To keep the number of victims as low as possible
Involved Stakeholders	Radio France Firemen Police Mobile Emergency medical services French Army Media
Priority of accomplishment	Must have.

Table BG3. Business Goal NuclearUC-BG-03
Field	Description
UniqueID	NuclearUC-BG-03
Short Name	To provide aid for employees and populations
Type	Business Goals.
Description	To decontaminate To extinguish fire / explosion To rescue people after an accident To support psychologically To find new accommodation
Rationale	To limit the consequences of the crisis
Involved Stakeholders	Firemen Police Mobile emergency medical service French Army
Priority of accomplishment	Must have.

Table BG4. Business Goal NuclearUC-BG-04
Field	Description
UniqueID	NuclearUC-BG-04
Short Name	To back repairing and relief operations
Type	Business Goals.
Description	To secure perimeter To make available resources / means
Rationale	To support all crisis response operations
Involved Stakeholders	Nuclear plant teams Representative of the national authority Radio France Firemen Mobile emergency medical service Hospitals Police Office of infrastructures
Priority of accomplishment	Must have.

Table BG5. Business Goal NuclearUC-BG-05
Field	Description
UniqueID	NuclearUC-BG-05
Short Name	To assess situation
Type	Business Goals.
Description	To measure radioactivity To measure weather characteristics (wind velocity/direction, rain, etc.)
Rationale	To assess the situation continuously
Involved Stakeholders	Nuclear Plant teams Meteo France Radiation survey network Firemen Measuring equipment Mobile measurement station
Priority of accomplishment	Must have.

Domain Assumption NuclearUC-DA-01
Field	Description
UniqueID	NuclearUC -DA-01
Short Name	Deal with public opinion
Type	Domain assumption
Description	Nuclear accidents attract media attention. The situation may become even more complex, in cases where public opinion is not properly informed.
Involved Stakeholders	Media Representative of the national authority
Supporting Material	Radio, TV, loudspeakers

Domain Assumption NuclearUC -02
Field	Description
UniqueID	NuclearUC -DA-02
Short Name	Service oriented application for all.
Type	Domain assumption
Description	Actors involved are heterogeneous and come with their own information systems. To ensure fast and effective communication, service oriented architecture is provided.
Involved Stakeholders	All

Domain Assumption NuclearUC -03
Field	Description
UniqueID	NuclearUC -DA-02
Short Name	Focus on management, operations and support outside the nuclear plant
Type	Domain assumption
Description	The repairing of the nuclear plant, managed by a separate crisis cell, is out of the scope of our study

Domain description

As explained in section 2.3, the domain description part of the adapted S-Cube model will be covered by (i) an ontology to describe concepts of the domain, relations between these concepts and characteristics of these concepts and (ii) a UML use case diagram to describe the actors and the relations between actors.

Ontology

Many definitions of an ontology have been given over past years (Gruber 1995, D8.1 InterOp 2004, Grimm et al. 2007): an ontology defines the basic terms and relations comprising the vocabulary of a topic area as well as the rules for combining terms, and relations to define extensions to the vocabulary (Neches et al. 1991). From this definition, an ontology includes not only the terms that are explicitly defined in it, but also the knowledge that can be inferred from it. More simply an ontology may be seen as a formal explicit specification of a shared conceptualisation for a domain of interest. This vision of ontology encompasses several interesting aspects which are:

A formal aspect: an ontology is expressed in a knowledge representation language that provides formal semantics.

An explicit aspect: the type of concepts used and the constraints on their use are explicitly defined.

A sharing aspect: This means there is some kind of agreement among people in a community or systems regarding the ontology.

A conceptualisation aspect: an ontology specifies knowledge in a conceptual way in terms of symbols representing concepts and their relations.

A domain specificity: the specifications in an ontology are limited to knowledge about a particular domain of interest. Ontology is referred to as a representation of knowledge that can be used and reused in order to facilitate the comprehension of concepts and relations as well as the communication between different domain actors.

In the PLAY project, this ontology was needed to represent, in a flexible and computable manner, the knowledge linked to domain and concepts of the use case (cf. S-Cube framework)

Figure 9: Ontology, number of individuals per classes and macro level view

This ontology in Figure 9 and Figure 10 is composed of three main parts: studied system, crisis characterization, and treatment system.

The studied system is defined as the sub-part of the world affected by the crisis. The Studied system components have been grouped in different categories that should be considered as the basic concepts of a domain specific language, such as goods, natural sites, people and civil society. Goods can be seen as man-made entities (roads, bridges, buildings, houses ...). Opposite to Natural sites, which are not man-made, such as rivers, forests... People concern all the groups of persons that may be impacted by the crisis (people from a city, group of travelers, employees of a company, ...). Civil society includes social entities like media, intellectuals, associations and organizations that act in the crisis area.

The studied system also includes Risks and Dangers. A danger is a particularity of the considered sub-part of the world that might engender some particular risk. For example, an area like Japan presents a characteristic of seismic instability (danger) responsible for earthquake (risk).

Once appeared, a Crisis is composed of four main components: (i) facts, (ii) events, (iii) Complexity factor(s) and (iv) Gravity factor(s).

Facts are what happen in the field. A complexity factor is a characteristic that impacts directly the nature of the crisis and can affect its type (for example, a sanitary crisis may evolve into a social crisis due to the "over-communication" through the media). A gravity factor is a characteristic that impacts directly the gravity of the crisis (for example, a strong wind could increase the gravity of a fire in a forest whereas rain could decrease it).

Events are of four natures:

• Events "situation" refer to measurements taken from the field (radiations, wind velocity and direction, rain), at a given place and time.
• Events "Resources" refer to the status of resources, i.e. their availability (time and space) and their relevance (skill, quantity)
• Events "Activity" refer to the status of activities (not applicable, waiting, work in progress, closed)
• Events "Consequence" is the noticeable concretization of one or several risks on the crisis studied. It may be the concretization of contamination risks if population is contaminated, or it may also be linked to transportation risks is an accident or a traffic jam occurs. Socio-psychological and fire/explosions consequences are also taken into account.

In order to solve (or to reduce) the crisis, a treatment system is defined with the aim to drive the crisis response in order to stabilize the studied system.

The treatment system is composed of Services, using Resources (human or material). Services are used to reduce a consequence, to prevent the concretization of risks or to lead the system to a specific state, defined by a condition, needed by another service. However a service can be forbidden by risks, consequences, other services or components of the studied system. For example, a risk of building collapse forbids the service of sending firemen inside.

There are two kinds of services: (i) Service of actor and (ii) Service of mediation. Service of actor is service provided by actor. Service of mediation can be a coordination service (between two services of actor) or an added value service such as a weather information service or an Orchestrator, which executing of the collaborative process.

Figure 10: Ontology

Use Case Diagram / Class Diagram

Figure 11 shows the general use case diagram for the Nuclear Crisis use case. Events are sent to and received from the PLAY system (represented by the upper actor on the diagram). Decisional actors, in the crisis cell, monitor and manage workflows, create new workflows or modify existing ones when needed. They also define priorities. Operational actors execute the requested activities and send back situations reports and diagnosis. Support and consultation actors send diagnosis and measurements.

Figure 11: UML Use Case Diagram

Scenario description

As explained in section 2.2, to resolve the nuclear crisis, we identified seven business processes, which we divided into three levels (see Figure 12):

1. Decisional
2. Operational
3. Support.

Figure 12: Nuclear Crisis Management

Business processes

As explained in section 2.3.4 (Domain Assumption NuclearUC-DA-03), from the seven business processes identified during the AsIs analysis, we kept only five for the ToBe analysis (see Figure 13, Figure 14 and Figure 15):

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)

Indeed, decisions and operations within the plant, to fix the problem, 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 previsions are sufficient).

Those business processes are described in detail in the following section.

Out of scope (see Domain Assumptions NuclearUC -DA-03) Figure 13: Decisional Workflow

Figure 14: Operational Workflow

Figure 15: Support Workflow

Sub-processes

From those five business process, we have detailed 16 sub-processes (see Figures 16, 17, 18, 19 and 20).

Each of these business processes is detailed according to S-Cube methodology in the following tables.

Table S1: Scenario NuclearUC_S1_decision1.2
Field	Description
UniqueID	NuclearUC_S1_decision1.2
Short name	To plan and control relief process and means
Involved Actors	Prefect (crisis cell) IRSN (scientific experts)
Detailed Operational Description	Activate crisis cell Alert field actors and create a crisis cell composed of delegates of each actor, and managed by the prefect Define and adapt safety perimeter Decide which area is or may be contaminated and ask actors to make sure that no one enters this zone Define preventive actions Create new or modify existing workflows and define priorities (Define the circulation plan and decide to implement it. Ask for measures, ask for advice, analyse the situation. Decide if population should ingest iodine, stay confined or evacuate) Define curative actions Plan, control and coordinate the assistance of victims Manage communication and media Choose and communicate relevant information to media
Additional Material	Figure 16 (overview) Figure 21 (BPMN)

Figure 16: To plan and control relief process and means (decisional level)

Table S2: Scenario NuclearUC_S2_operation2.2
Field	Description
UniqueID	NuclearUC_S2_operation2.2
Short name	To protect population
Involved Actors	Firemen Police Army Office of infrastructure Media
Detailed Operational Description	Alert population Use media and loudspeakers to diffuse information Position and maintain safety perimeter Make sure that the access to the contaminated area is restricted Provide preventive devices and action Distribute iodine capsules, implement circulation plan Evacuate population Ask population to evacuate with their light vehicle or to go to evacuation plan to be evacuated by buses.
Additional Material	Figure 17 (overview) Figure 22 (BPMN)

Figure 17: Protect population (operational level)

Table S3: Scenario NuclearUC_S4_operation2.4
Field	Description
UniqueID	NuclearUC_S4_operation2.4
Short name	To provide aid to population
Involved Actors	Firemen Hospitals MEMS
Detailed Operational Description	Provide aid to persons: Decontaminate affected population, assist victims and transfer them to hospital for additional treatment when needed. Treat dangerous situations: Support population psychologically
Additional Material	Figure 18 (overview) Figure 23 (BPMN)

Figure 18: Provide aid to employees and population (operational level)

Table S4: Scenario NuclearUC_S4_support3.2
Field	Description
UniqueID	NuclearUC_S4_support3.2
Short name	To back relief operations
Involved Actors	Prefect Office of infrastructures Logistics section of Firemen Logistics section of Police
Detailed Operational Description	Find relevant and available resources Provide relevant and available resources: Find relevant and available resources (material and/or human) needed for operations.
Additional Material	Figure 19 (overview) Figure 24 (BPMN)

Figure 19: Back relief operation (support level)

Table S5: Scenario NuclearUC_S5_support3.2
Field	Description
UniqueID	NuclearUC_S5_support3.2
Short name	To assess situation
Involved Actors	Meteo France Radiation survey network
Detailed Operational Description	Provide radioactivity measures Provide weather characteristics Provide situational reports Relevant measures are sent to crisis cell (wind force and direction, current and expected precipitations, radioactivity level of air, gas, dust, water, animals, plants, aliments, and ground.)
Additional Material	Figure 20 (overview) Figure 25 (BPMN)

Figure 20: Assess situation (support level)

BPMN

The final level of S-Cube scenario description concerns the processes definition. In our case of nuclear crisis management, the scenario is very complex and a lot of sub-processes are involved. As far as we planned to simulate this use case through a demonstration platform able to run (in a SOA context) the three levels of processes (strategic, operational and support), we definitely need to describe these processes and its sub-processes in a very detailed manner.

The demonstration platform that will be provided, it will be based on SOA principles and on the ESB PETALS. Such a technical infrastructure requires describing processes as workflows in a runnable language (for instance BPEL). 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). 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 projects specificities (event-based) and technical requirements of the demonstration platform to be provided (proximity between BPMN and workflow language).

Then, the following figures present different swim lanes (horizontal containers) representing the involved actors and the "clouds". Each pool embeds its own activities and flows, while exchanges between pools are represented through flows generating events. We assume that BPMN is finally the ultimate way to represent detailed processes of our nuclear crisis use-case, through a PLAY point of view (event-oriented) and in a manner perfectly adapted for our perspective of ESB-based demonstration platform.

Figure 21: To plan and control relief processes and means

Figure 22: To protect population

Figure 23: Provide aid to employees and population

Figure 24: To assess situation

Figure 25: To back relief operations