{center}
{flash:file=Architecture^soceda_architecture.swf|width=581px|height=486px}
{center}
h1. Goals
The nuclear use case will be run through a simulation environment, which will stimulate the event-processing platform with virtual events coming from web-services playing the role of involved partners (police, army, meteorological service, radiation survey networks, etc.). EMAC will lead that use case and represent the interface to the real end users.
h1. Approach
A nuclear accident may occur in a nuclear plant or during the carriage of radioactive material. These industrial plant or those hazardous material transports may expose people to ionizing radiations according to large quantity of radioactive substance accidentally released in the atmosphere, or critical accident with strong nuclear radiation due to an uncontrolled fission (which may also include a large radioactive substance release similar to previous point).
The scenario is proposed according to four steps:
# *{_}Alert step{_}*: The plant security system (and maybe the radiation survey network) detects a potential problem and send an alert event (critical accident due to an uncontrolled fission with a large radioactive substance release). The Local responsible of the nuclear plant diagnoses that it is a crisis situation and send the events to convoke or mobilize the required actors.
# *{_}Deployment step{_}*: Actors arrive on the expected places (site, management cell) and start to deploy and make an inventory of resources. Meteorological network and radiation survey network keep on sending their measures as events.
# *{_}Reaction step{_}*: Actors on site provide their first diagnostics (as events), while the mobilized scientific cell provides its first advices (as events) based on weather and radiation measurements. The management cell creates the decision workflow (in order to respect hierarchy and expertise) and determines some priority build and start to run on the crisis field.
# *{_}Continuous step{_}*: The situation evolves and the three workflows have to remain adapted to the situation. This objective may be reached according to two levels:
#* *Micro level*: Each actor send continuously its events and receive the (possibly complex) events it is concerned by (for instance, the scientific cell listen to the meteorological and radiation events, while logistic of firemen listen to road network events). Each workflow (strategic, operational and support) may so evolve continuously at a micro level according to these events.
#* *Macro level*: Some complex events conjunction may require some strong changes in the workflows (for instance, a panic movement among people of the nearest city or a sudden change in the weather which may impact critical ground water). In this case, the management cell should use the management system of the platform to control situation and the consequences on the workflows.
h1. Scenario description
h2. Iterative principle of demo
This part provides some explanations concerning the two steps of the demo dedicated to cover all the identified objectives (suggested objectives are: orchestration, choreography, agility in orchestration, agility in choreography, scalability).
Though it is not easy to imagine this context as a strongly computed environment where services could easily send their events to the clouds, many elements make this use case a relevant illustration for Internet of Services:
* The simulation platform enable to run independent internal business processes _(orchestration)_,
* The simulation platform links various processes, which are running on separate ESB _(choreography)_,
* It can takes into account changes in a single process _(agility in orchestration)_,
* It can take into account the interaction between processes and modify each impacted process if needed _(agility in choreography)_. Those changes are driven by events,
* High volumes of heterogeneous information is exchanged _(scalability)_.
h1. BPMN 2.0 process
61 BPMN 2.0 process are defined in the nuclear crisis use case. These processes are divided in 18 groups (similar types):
* 6 groups at decisional level,
* 9 groups at operational level,
* 3 groups au support level.
Below, an excerpt of these processes are presented:
* Example of decisional process
!decision.png|border=1!
* Example of operational process
* Example of support process
{flash:file=Architecture^soceda_architecture.swf|width=581px|height=486px}
{center}
h1. Goals
The nuclear use case will be run through a simulation environment, which will stimulate the event-processing platform with virtual events coming from web-services playing the role of involved partners (police, army, meteorological service, radiation survey networks, etc.). EMAC will lead that use case and represent the interface to the real end users.
h1. Approach
A nuclear accident may occur in a nuclear plant or during the carriage of radioactive material. These industrial plant or those hazardous material transports may expose people to ionizing radiations according to large quantity of radioactive substance accidentally released in the atmosphere, or critical accident with strong nuclear radiation due to an uncontrolled fission (which may also include a large radioactive substance release similar to previous point).
The scenario is proposed according to four steps:
# *{_}Alert step{_}*: The plant security system (and maybe the radiation survey network) detects a potential problem and send an alert event (critical accident due to an uncontrolled fission with a large radioactive substance release). The Local responsible of the nuclear plant diagnoses that it is a crisis situation and send the events to convoke or mobilize the required actors.
# *{_}Deployment step{_}*: Actors arrive on the expected places (site, management cell) and start to deploy and make an inventory of resources. Meteorological network and radiation survey network keep on sending their measures as events.
# *{_}Reaction step{_}*: Actors on site provide their first diagnostics (as events), while the mobilized scientific cell provides its first advices (as events) based on weather and radiation measurements. The management cell creates the decision workflow (in order to respect hierarchy and expertise) and determines some priority build and start to run on the crisis field.
# *{_}Continuous step{_}*: The situation evolves and the three workflows have to remain adapted to the situation. This objective may be reached according to two levels:
#* *Micro level*: Each actor send continuously its events and receive the (possibly complex) events it is concerned by (for instance, the scientific cell listen to the meteorological and radiation events, while logistic of firemen listen to road network events). Each workflow (strategic, operational and support) may so evolve continuously at a micro level according to these events.
#* *Macro level*: Some complex events conjunction may require some strong changes in the workflows (for instance, a panic movement among people of the nearest city or a sudden change in the weather which may impact critical ground water). In this case, the management cell should use the management system of the platform to control situation and the consequences on the workflows.
h1. Scenario description
h2. Iterative principle of demo
This part provides some explanations concerning the two steps of the demo dedicated to cover all the identified objectives (suggested objectives are: orchestration, choreography, agility in orchestration, agility in choreography, scalability).
Though it is not easy to imagine this context as a strongly computed environment where services could easily send their events to the clouds, many elements make this use case a relevant illustration for Internet of Services:
* The simulation platform enable to run independent internal business processes _(orchestration)_,
* The simulation platform links various processes, which are running on separate ESB _(choreography)_,
* It can takes into account changes in a single process _(agility in orchestration)_,
* It can take into account the interaction between processes and modify each impacted process if needed _(agility in choreography)_. Those changes are driven by events,
* High volumes of heterogeneous information is exchanged _(scalability)_.
h1. BPMN 2.0 process
61 BPMN 2.0 process are defined in the nuclear crisis use case. These processes are divided in 18 groups (similar types):
* 6 groups at decisional level,
* 9 groups at operational level,
* 3 groups au support level.
Below, an excerpt of these processes are presented:
* Example of decisional process
!decision.png|border=1!
* Example of operational process
* Example of support process