CONSTRUCTING DEVS MODELS BASED ON EXPERTS’ KNOWLEDGE:
Application to STMicroelectronics’ Large Scale Manufacturing Processes
Pamela Viale∗,∗∗ , Claudia Frydman∗ , Jacques Pinaton∗∗
∗ Laboratoire des Sciences de l’Information et des Systèmes (LSIS), Marseille, France
∗∗ STMicroelectronics, Rousset, France
{pamela.viale, claudia.frydman}@lsis.org, jacques.pinaton@st.com
Keywords: Workflows, Experts’ Knowledge, Processes
Abstract
STMicroelectronics has a spirit of innovation in the devel-
opment of chips, continuously modifying its production pro-
cesses for improving performance. This is why it is interested
in creating ’generic models’ of their manufacturing processes
and keeping them updated in spite of the high number of mod-
ifications demanded. It is specially interested in capitalizing
experts’ knowledge. In this article we explain ideas for con-
structing models for STMicroelectronics manufacturing pro-
cesses using experts’ definitions. The importance of our ap-
proach resides in the construction of models that constitute a
step forwards to the implementation of an alarm control sys-
tem over processes modifications.
Experts’ Translator Experts’ Translator Experts’
Database Workflows DEVS Models
(STEP 1)
Database
(STEP 2)
Database
Figure 1: Experts’ Models Construction
1. INTRODUCTION
STMicroelectronics counts today with more than a thou-
sand different manufacturing processes defined and main-
tained by their experts. However, there are actually more than
fifty modifications demanded every week. The complexity of
these processes (approximately five hundreds tasks) and the
high volume of modifications demanded, turn the activity of
modifying these processes into a difficult and error prone ac-
tivity. STMicroelectronics does not count with any tool to
identify risky modifications and errors are detected during
production.
This is why the enterprise is interested in implementing
an alarm system over modifications. The idea is then to con-
struct ’generic models’ for their processes and use these mod-
els as reference for deciding the risk associated to a mod-
ification. Nowadays, there is a software that reports every
day processes modifications. The idea is to add to this tool
these ’generic models’. Modifications that are already con-
sidered as options in the models would then be less risky that
those modifications introducing new ideas. The idea is to add
193
alarms on this already existent tool, to alert about risky mod-
ifications based on the models we construct.
We use the term ’generic models’ for referencing models
containing all options of a process. For constructing these
models, we decided to work in parallel over two different
sources of data, construct models from each source of data,
and then compare and merge these models for obtaining a fi-
nal and more general model, our ’generic model’.
One of the sources considered are the databases containing
logs of executions of processes. The idea is to discover mod-
els using some process mining methods. Models obtained
should be then converted into DEVS models. However, this
part of our work is out of the scope of this article (see [Viale
et al., 2010a] and [Viale et al., 2010b] if interested).
The second source of information considered is experts’
knowledge. The steps needed for constructing models from
experts’ knowledge can be appreciated in Figure 1. It requires
two steps: STEP 1) interpreting experts definitions and trans-
lating them into workflows; STEP 2) translating workflows
obtained into DEVS Models. In the article we will present the
ideas for making these convertions, based on ideas published
in [Zacharewicz, 2006].
We decided to use DEVS formalism as the ’common’ for-
malism for being able to compare and merge the models from
the two different sources. DEVS formalism is appropiate to
demostrate properties over processes and some ideas has also
been published that can be helpful for our work. Works on
how to compare DEVS models can be found in [Giambiasi,
2009]. The reason why we decided to construct these ’generic
models’ using both sources of information is due to the fact
that the actual activities that occur during a process execu-
tion might contain exceptions to what is defined by experts
or might be just a subset of experts’ definitions. In fact, pro-
cesses defined by STMicroelectronics’ experts contain more
options than the ones really used in production. It would be
interesting to discover which options are not used and analise
why. Merging both sources of information would help to learn
how the real process works.
In Section 2. we introduce STMicroelectronics’ vocabu-
lary. In Section 3. we explain how to convert STMicroelec-
tronics’ processes into workflows (STEP 1 of Figure 1). Fi-
nally, in Section 4. we present ideas for translating workflows
into DEVS models (STEP 2 on the same Figure).
2. STMICROELECTRONICS’ PROCESSES
A manufacturing process is called ’Production Route’ in
STMicroelectronics’ vocabulary. Each of these production
routes is composed of a sequence of ’Operations’. Each op-
eration is a sequence of ’Steps’ and ’Events’. In fact, a step
is always associated to an event. A step is just an increasing
number used to order the events in an operation. An event is
a desired treatment over the manufactured object. Associated
to each event there are ’Entities’. An entity is a machine that
is qualified, i.e. that has been tested and validated for the de-
sired treatment. Depending on the event to perform and the
entity chosen, there is a ’Recipe’ associated. A recipe is a list
of machine instructions that are given to the entity chosen to
perform the desired treatment. There may be different recipes
associated to a same event. The reason is that there exists dif-
ferent machines in STMicroelectronics that are used for per-
forming same treatments. So, the list of machine instructions
are not the same if the machines are not equal.
When executing the different operations that compose a
production route some measures are taken to be sure that
production respects experts’ specifications. As a result of
these measures, it is possible to identify problems. Sometimes
problems are not possible to correct and the object must be
taken out of the production. And some other times problems
can be corrected. The moment in the production when errors
can be recoved are also specified by experts. Special actions
that can be done to correct errors are specified in what ex-
perts’ call ’Rework Routes’. These rework routes are defined
as any other production route as a sequence of operations,
steps, events, etc.
2.1. Production Route Example
Experts’ specifications are saved in the databases of the su-
pervision system of production (’Experts’ Database’ in Fig-
ure 1). However, whether they want to analyse or whether
they would like to modify these routes, experts make an ex-
traction of these specifications in a table format. The exam-
ples we show in this section are real examples from STMicro-
electronics (name routes and labels have been slightly modi-
fied due to confidential reasons). In Table 1 we show an ex-
tract of the production process called ’H90SHXXF’. In this
extract we can also appreciate that the route proposed is as-
sociated to a rework route called ’RWKYYR’. In Table 2 we
show the description of this rework route.
We explain first how to read the production route
’H90SHXXF’ of Table 1. If we consider first the two columns
named OPERATION and OPERATION DESCRIPTION we
can see that ’H90SHXXF’ route is composed of four Oper-
ations: 1010 (Description: Laser Marking), 1015 (Descrip-
tion: Clean Zero level oxid), 1120 (Description: Initial Ox-
idation) and 1180 (Description: Nitride Deposition). If we
consider Operation 1010, and we consider columns named
194
STEP, EVENT and EVENT DESCRIPTION we can see
that is composed of a sequence of three Steps: 3010 asso-
ciated to Event PRPMKKLL (Description: Laser Marking),
3511 associated to Event PRMCCW (Description: Sorter
Lecture arr et face avant) and 8611 associated to Event
PRMDD01D (Description: D0 Laser Measurement). We can
see that for Event PRPMKKLL (in Operation 1010, Step
3010) the Recipe associated to the two qualified entities LS01
and LS02 is Recipe MLAS (columns ENTITY and RECIPE).
If we pay attention to Table 1 we can see that there are four
columns that are not always filled in. These columns are used
when in the corresponding operation there is a rework autho-
rized. The column REWORK ROUTE indicates the name of
the rework route to be used, REWORK OPER indicates the
operation in the rework route where starts the execution, the
column REWORK RETURN ROUTE indicates the name of
the production process to execute after the rework and finally
the column REWORK RETURN OPER indicates the opera-
tion of the production process to execute after the corrective
actions. If we analyse Table 1 we can see that there is a rework
authorized at Operation 1120 (coulored rows of Table 1). The
rework route to execute is ’RWKYYR’ shown in Table 2. Ex-
ecution of rework starts at Operation 9720 (only operation of
this rework route). After executing the corrections we go back
to production process ’H90SHXXF’ at Operation 1120.
3. TRANSLATION TO WORKFLOWS
In this section we will explain how to make a convertion
from experts’ specifications of production routes to workflow
format (STEP 1 in Figure 1).
A workflow corresponds to a definition of certain process.
The process is composed, in general, by several activities that
are executed in certained order to accomplish an objective.
Activities can be atomic tasks or not. Non-atomic tasks are
activities that can be decomposed and are associated to sub-
processes. Sub-processes can be, as well, composed of sub-
processes. The resources for executing the different atomic
tasks must also be specified for well defining a workflow. A
work item is the representation of the information (or object)
given to a certain process for accomplishing the desired re-
sult. The process define how activities are connected so that
the work item advances in the process. The flow controls used
in general are: AND-Split, AND-Join, OR-Split, OR-Join, It-
eration and Sequence. We consider that this transformation to
workflow is necessary because the process we work with are
complex, they are not just simple sequences of actions.
Considering STMicroelectronics information, each opera-
tion in a production route will be represented as a non-atomic
task. Each operation will be associated to a workflow com-
posed of a sequence of atomic tasks. Each of these atomic
tasks will represent the pair (step, event). Atomic tasks will
be associated to a group of resources that will be the group of
 OPERATION REWORK REWORK REWORK REWORK EVENT
ROUTE DESCRIPTION OPERATION OPER ROUTE RETURN RETURN STEP EVENT DESCRIPTION RECIPE ENTITY
OPER ROUTE
H90SHXXF Laser Marking 1010 3010 PRPMKKLL Laser Marking MLAS LS02
H90SHXXF Laser Marking 1010 3010 PRPMKKLL Laser Marking MLAS LS01
H90SHXXF Laser Marking 1010 3511 PRMCCW Sorter lecture arr et face avant CCWID SR18
H90SHXXF Laser Marking 1010 3511 PRMCCW Sorter lecture arr et face avant CCWID SRDOWN
H90SHXXF Laser Marking 1010 8611 PRMDD01D D0 Laser Measurment MK_LAS DM01
H90SHXXF Laser Marking 1010 8611 PRMDD01D D0 Laser Measurment MK_LAS DM03
H90SHXXF Laser Marking 1010 8611 PRMDD01D D0 Laser Measurment MK_LAS DM05
H90SHXXF Clean Zero level oxid 1015 3010 PRPNFC13 HF 50 SC1 60C 800W SC2 NFC13A040 WC07
H90SHXXF Clean Zero level oxid 1015 3010 PRPNFC13 HF 50 SC1 60C 800W SC2 NFC13A040 WC04
H90SHXXF Clean Zero level oxid 1015 3010 PRPNFC13 HF 50 SC1 60C 800W SC2 NFC13A040 WC05
H90SHXXF Clean Zero level oxid 1015 3010 PRPNFC13 HF 50 SC1 60C 800W SC2 NFC13A040 WC01
H90SHXXF Initial Oxidation 1120 9720 RWKYYR 1120 H90SHXXF 3010 PRPO02 OXI 5nm / 850C / 7mn55 OXIDE02 FX01
H90SHXXF Initial Oxidation 1120 9720 RWKYYR 1120 H90SHXXF 3010 PRPO02 OXI 5nm / 850C / 7mn55 OXIDE02 FX02
H90SHXXF Initial Oxidation 1120 9720 RWKYYR 1120 H90SHXXF 3010 PRPO02 OXI 5nm / 850C / 7mn55 OXIDE02 FX05
H90SHXXF Initial Oxidation 1120 9720 RWKYYR 1120 H90SHXXF 3010 PRPO02 OXI 5nm / 850C / 7mn55 OXIDE02 FX06
H90SHXXF Initial Oxidation 1120 9720 RWKYYR 1120 H90SHXXF 5211 PRNO02E THICK.MEASURE ON TEST OXIDE02E TM06
H90SHXXF Initial Oxidation 1120 9720 RWKYYR 1120 H90SHXXF 5211 PRNO02E THICK.MEASURE ON TEST OXIDE02E TM07
H90SHXXF Initial Oxidation 1120 9720 RWKYYR 1120 H90SHXXF 5211 PRNO02E THICK.MEASURE ON TEST OXIDE02E TM10
H90SHXXF Nitride Deposition 1180 3010 PRPN01 NIT 150nm / 887C / 140mTorr NT01 LN02
H90SHXXF Nitride Deposition 1180 3010 PRPN01 NIT 150nm / 887C / 140mTorr NT01 LN05
H90SHXXF Nitride Deposition 1180 3010 PRPN01 NIT 150nm / 887C / 140mTorr NT01 LN06
H90SHXXF Nitride Deposition 1180 5211 PRNN1E THICK.MEASURE ON TEST NT01E TM06
H90SHXXF Nitride Deposition 1180 5211 PRNN1E THICK.MEASURE ON TEST NT01E TM07

Table 1: Production Route ’H90SHXXF’

OPERATION EVENT
ROUTE OPERATION STEP EVENT RECIPE ENTITY
DESCRIPTION DESCRIPTION
RWKYYR Rework Diff 9720 3010 PRPNCA01 SC1 60C 800W SC2 NCA01A WC08
RWKYYR Rework Diff 9720 3010 PRPNCA01 SC1 60C 800W SC2 NCA01A WC03
RWKYYR Rework Diff 9720 3010 PRPNCA01 SC1 60C 800W SC2 NCA01A WC06

Table 2: Rework Route ’RWKYYR’

entities qualified for doing the desired treatment. Depending
on the entity, a desired recipe is associated. Representation of
rework routes is analogue.
The WfMC1 has created a standard format called XPDL,
the XML Process Definition Language. We will concentrate
ourselves on Applications and WorkflowProcesses elements
of this file. In Applications we define all the necessary re-
sources for the execution (or implementation) of the different
activities of any workflow process in the same file. In Work-
flowProcesses there are the definitions of all of the workflows
processes. For each workflow process we define, as well, all
its Activities and all Transitions between them. The other
parts of the specification are more related to the editors used
for creating the files.
Listing 1: Applications specification
on Table 1).
In Listing 1 we can see an extract of the Applications spec-
ification for our example. There we can see how we define
an Application for each entity use for executing the recipes
of the production routes. In particular, we can see the spec-
ification for entity FX01. Each entity receives the recipe to
execute as parameter. For the rest of the entities is analogue.
Listing 2: Specification for H90SHXXF
< xpdl : WorkflowProcess Id =" H90SHXXF " Name =" H90SHXXF
">
< xpdl : Activities >
< xpdl : Activity Id =" H90SHXXF_OPER_1010 " Name ="
OPER_1010 ">
< xpdl : Description > Laser Marking </ xpdl :
Description >

< xpdl : Applications >

< xpdl : Application Id =" FX01 " Name =" FX01 ">
< xpdl : FormalParameters >
< xpdl : FormalParameter Id =" RECIPE " Mode =" IN ">
< xpdl : DataType >
< xpdl : BasicType Type =" STRING "/ >
</ xpdl : DataType >
</ xpdl : FormalParameter > (a) Workflow associated to production route ’H90SHXXF’
</ xpdl : FormalParameters >
</ xpdl : Application >
...
</ xpdl : Applications >

We will show some extracts of the translation obtained for (b) Workflow associated to operation 1010
the example shown in the previous section (production route
1 Workflow Management Coalition Figure 2: Workflow Models for our example

195
 Step
<in_res I IN {1 ..N}> ? 'free' <out_resI>!('dem', Ftime (Lot, Entity, Recipe)

[Entity = ' – ' and

<in_lot> Dem Event = 'PR------' and S0 <out_lot>
Waiting
Alloc Recipe = '----' ] δ = FTime(Lot,
Res
δ=∞ δ=0 Entity, Recipe)

<out_lot> ! FTransf(Lot,Entity,Recipe]
[Lot = { } ]
<in_resI> ? 'free'
<in_resi=1.. n>
<out_res i= 1.. n>

No
Lot Lot

δ= ∞ <in_lot>?l δ= ∞
[Lot = l]

Phase, Lot, Entity, Recipe, Ffransf,, FTime,

(a) DEVS atomic model associated to the atomic workflow task representing a Step

Entity
<in> ?( 'dem', Time)

Free <out i=1 .. n>

<in i=1 .. n> Busy
δ= ∞
δ = Time

<out> ! 'ended'

Phase

(b) DEVS atomic model associated to a resource

Figure 3: DEVS atomic models of our library

< xpdl : Implementation > < xpdl : Transition From =" H90SHXXF_OPER_1015 "
< xpdl : SubFlow Id =" H90SHXXF_OPER_1010 "/ > Id =" H90SHXXF_OPER_1015_H90SHXXF_OPER_1120 "
</ xpdl : Implementation > To =" H90SHXXF_OPER_1120 ">
</ xpdl : Activity > </ xpdl : Transition >
< xpdl : Activity Id =" H90SHXXF_OPER_1015 " Name =" < xpdl : Transition From =" H90SHXXF_OPER_1120 "
OPER_1015 "> Id =" H90SHXXF_OPER_1120_H90SHXXF_OPER_1180 "
< xpdl : Description > Clean Zero level To =" H90SHXXF_OPER_1180 ">
oxidation </ xpdl : Description > < xpdl : Condition Type =" OTHERWISE "/ >
< xpdl : Implementation > </ xpdl : Transition >
< xpdl : SubFlow Id =" H90SHXXF_OPER_1015 "/ > < xpdl : Transition From =" H90SHXXF_OPER_1120 "
</ xpdl : Implementation > Id =" H90SHXXF_OPER_1120_H90SHXXF_1120_RWKYYR "
</ xpdl : Activity > To =" H90SHXXF_OPER_1120_REWORK_RWKYYR ">
< xpdl : Activity Id =" H90SHXXF_OPER_1120 " Name =" < xpdl : Condition Type =" CONDITION "> whereToGo ==
OPER_1120 "> " RWKYYR " </ xpdl : Condition >
... </ xpdl : Transition >
</ xpdl : Activity > < xpdl : Transition
< xpdl : Activity Id =" From =" H90SHXXF_OPER_1120_REWORK_RWKYYR "
H90SHXXF_OPER_1120_REWORK_RWKYYR " Name =" Id =" H90SHXXF_OPER_1120_REWORK_
RWKYYR "> RWKYYR_H90SHXXF_OPER_1120 "
... To =" H90SHXXF_OPER_1120 ">
</ xpdl : Activity > </ xpdl : Transition >
< xpdl : Activity Id =" H90SHXXF_OPER_1180 " Name =" </ xpdl : Transitions >
OPER_1180 "> </ xpdl : WorkflowProcess >
...
</ xpdl : Activity >
</ xpdl : Activities >
In Listing 2 we can see the specification of the workflow
< xpdl : Transitions > process corresponding to the production route H90SHXXF.
< xpdl : Transition From =" H90SHXXF_OPER_1010 " We can see there that the process is defined by a group of
Id =" H90SHXXF_OPER_1010_H90SHXXF_OPER_1015 " Activities representing Operation 1010, Operation 1015, Op-
To =" H90SHXXF_OPER_1015 ">
</ xpdl : Transition >
eration 1120, Operation 1180 and Rework Route RWKYYR.
Each of these activities is as well a workflow. We can see this

196
by the reference to a Subflow in the Implementation specifica- the recipe MLAS (parameter associated). A graphical repre-
tion. In the same Listing we show the specifications of Transi- sentation of Operation 1010 can be seen in Figure 2(b).
tions between the different activities of process H90SHXXF.
In this listing (Transitions definition) we can identify two pos- 4. TRANSLATION TO DEVS MODELS
sible paths after Operation 1120. A graphical representation
In this section we are going to present some ideas on how
of production route H90SHXXF can be appreciated in Figure
to convert workflow specifications into DEVS specifications
2(a). In graphical representation atomic tasks are represented
(STEP 2 in Figure 1).The formalism that is commonly associ-
as one line rectangles, non-atomic tasks as double line rect-
ated to workflows are petri nets. There are three good reasons
angles.
for choosing petri nets for representing workflows: 1) there
Listing 3: Specification for Operation 1010 of H90SHXXF exists a formal semantics associated to petri nets; 2) it defines
models based on state an not on events; and 3) there exist
< xpdl : WorkflowProcess Id =" H90SHXXF_OPER_1010 " Name
=" H90SHXXF_OPER_1010 "> many techniques for doing analysis. However, DEVS formal-
< xpdl : Activities > ism is more general than petri nets. In the classic petri nets,
< xpdl : Activity Id =" H90SHXXF_OPER_1010_STEP_3010 " the notion of time is not considered. Models in classical petri
Name =" PRPMKKLL "> nets are not hierarchical and they are not well adapted for im-
< xpdl : Description > Laser Marking </ xpdl :
Description > plementation. This is why we decided to use DEVS for our
< xpdl : Implementation > ’generic models’.
< xpdl : Tool Id =" LS01 "> The idea is to define a library of DEVS models, each as-
< xpdl : ActualParameters >
< xpdl : ActualParameter >" MLAS " </ xpdl :
sociated to the different basic elements of a workflow defini-
ActualParameter > tion. These models should then be instantiated using differ-
</ xpdl : ActualParameters > ent parameters from the workflow considered for translation.
</ xpdl : Tool > We need to define atomic models associated to atomic tasks,
< xpdl : Tool Id =" LS02 ">
...
i.e., for steps and for resources and the different controllers
</ xpdl : Tool > (XOR-Split, XOR-Join, AND-Split, AND-Join, etc).
</ xpdl : Implementation > In Figure 3(a) we can see a graphical representation of an
</ xpdl : Activity > atomic DEVS model representing a step in a production route
< xpdl : Activity Id =" H90SHXXF_OPER_1010_STEP_3511 "
Name =" PRMCCW "> of STMicroelectronics. We can see that this atomic model
... contain an input port for receiving the lot and an input port
</ xpdl : Activity > for each of the qualified entities. STMicroelectronics experts’
< xpdl : Activity Id =" H90SHXXF_OPER_1010_STEP_8611 " call lot to the manufactured object2 . There are also two func-
Name =" PRMDD01D ">
... tions that must be defined in the DEVS model of Figure 3(a).
</ xpdl : Activity > FTrans f (Lot, Entity, Recipe) that calculates the transformation
</ xpdl : Activities > of the lot in according to the Entity and the Recipe used and
< xpdl : Transitions >
FTime (Lot, Entity, Recipe) that calculates the time needed for
< xpdl : Transition From ="
H90SHXXF_OPER_1010_STEP_3010 " the Entity for executing the corresponding Recipe over the
Id =" H90SHXXF_OPER_1010_STEP_3010_ lot. This models contains also one outport for sending the lot
H90SHXXF_OPER_1010_STEP_3511 " to the following step and an outport for each of the qualified
To =" H90SHXXF_OPER_1010_STEP_3511 ">
</ xpdl : Transition >
entities.
< xpdl : Transition From =" In Figure 3(b) we can see a graphical representation of an
H90SHXXF_OPER_1010_STEP_3511 " atomic DEVS model of an entity in STMicroelectronics. This
Id =" H90SHXXF_OPER_1010_STEP_3511_ model contain an inport and an outport for all the steps that
H90SHXXF_OPER_1010_STEP_8611 "
To =" H90SHXXF_OPER_1010_STEP_8611 ">
can use it for the treatment.
</ xpdl : Transition > For performing the transformation, we propose to create
</ xpdl : Transitions > for each atomic task associated to a Step in STMicroelectron-
</ xpdl : WorkflowProcess > ics a corresponding atomic DEVS models as the one shown
Listing 3 shows the specification of Operation 1010 of pro- in Figure 3(a). For each resource representing STMicroelec-
duction route H90SHXXF. We can appreciate that this oper- tronics entities we need to create an atomic DEVS model
ation of composed of three activities associated to Step 3010, similar to the one in Figure 3(b). For each workflow process
Step 3511 and Step 8611, respectively. Each of these activi- we define a couple DEVS models, paying attention to respect
ties is associated to the qualified tools. For example, we can the coupling between equivalent models. Coupled workflow
see that Step 3010 associated to Event PRPMKKLL can be 2 A lot is a box containing at most 25 silicium plates used for producing

performed by two entities: LS01 and LS02. Both of them uses the final products

197
 H90SHXXF
OPER_1010
OPER_1010 OPER_1015
OPER_1010 OPER_1120
OPER_1010 OPER_1180
OPER_1010

XOR Join XOR Split

<in_lot> <out_lot> <in_lot> <out_lot> <in_lot> <in_lot> <out_lot> <in_lot> <in_lot> <out_lot>

RWKYYR
OPER_1010

<in>
<in_lot> <out>

(a) DEVS Coupled Model for H90SHXXF

OPER_1010
STEP_3010
OPER_1010 STEP_3511
OPER_1010 STEP_8611
OPER_1010

<in_lot> <out_lot> <in_lot> <out_lot> <in_lot> <out_lot>

LS01
OPER_1010 SR18
OPER_1010 DM01
OPER_1010

<in>
<in_lot> <out> <in>
<in_lot> <out> <in>
<in_lot> <out>

LS02
OPER_1010 SRDOWN
OPER_1010 DM03
OPER_1010

<in>
<in_lot> <out> <in>
<in_lot> <out> <in>
<in_lot> <out>

DM05
<in>
<in_lot> <out>

(b) DEVS Coupled Model for Operation 1010

Figure 4: DEVS Models for our example

models must result in coupled DEVS models. If there is any tion is a new option there will be a high risk associated and
transition restriction when connecting different tasks in the an alarm will be shown in the user interface. Once the mod-
workflow definitions, we need to create the necessary con- ification will be controlled and validated by Control Process
troller models (XOR-Split, XOR-Join, etc). In Figure 4(a) we engineers, it will be added to the ’generic model’ (using the
can see the coupled DEVS model resulting from the trans- transformations explained in this article).
formation of workflow in Figure 2(a). In Figure 4(b) there We can conclude that we are working towards to use DEVS
is the result of the transformation of the workflow of Figure formalism in the real industrial world.
2(b). There we can appreciate all steps that compose Oper-
ation 1010 and all the qualified entities for performing the REFERENCES
necessary transformations for each step. In DEVS graphical [Giambiasi, 2009] Giambiasi, N. (2009). From sequential
representation atomic models are represented as one line rect- machines to devs formalism. SCS 2009.
angles, coupled DEVS models as double line rectangles. For
confidentiality reasons, we do not show all DEVS models ob- [Viale et al., 2010a] Viale, P., Benayadi, N., Goc, M. L., and
tained. The formalization of the transformation of workflows Pinaton, J. (2010a). Discovering large scale manufacturing
into DEVS models will be the aim of a future article. process models from timed data: Application to stmicro-
electronics production processes. In ICSOFT 2010, vol-
ume 1, pages 227–235.
5. CONCLUSION
[Viale et al., 2010b] Viale, P., Benayadi, N., Goc, M. L., and
We have presented general ideas for creating DEVS mod-
Pinaton, J. (2010b). Modeling large scale manufacturing
els from experts definitions. These models would be used
process from timed data: Using the tom4l approach and se-
in the future for constructing the desired ’generic models’.
quence alignment information for modeling stmicroelec-
’Generic models’ will be models of STMicroelectronics’ pro-
tronics production processes. In ICEIS 2010, volume 2,
duction routes containing all the different options of the pro-
pages 129–138.
cesses at different dates (resumed in one model). The idea is
to use the already existent tool that identifies every day modi- [Zacharewicz, 2006] Zacharewicz, G. (2006). Un Environ-
fications with these ’generic models’. When a detected modi- ment G-DEVS/HLA: Application à la Modelisation et Sim-
fication will be already part of these ’generic models’ the risk ulation Distribuée de Workflow. Thèse de doctorat, Univ.
associated will be considered low. However, if the modifica- Aix-Marseille III.

198