TOWARDS MODULAR AND COORDINATED 

MANUFACTURING SYSTEMS ORIENTED TO SERVICES 

HACIA UM SISTEMA DE MANUFACTURA MODULAR Y 
COORDINADO CON ORIENTACIÓN A SERVICIOS 

JOSÉ ISIDRO GARCIA MELO 
Mechanical Engineering School, University of Valle, Cali, Colombial. Jose.i.garcia@correounivalle.edu.co 

FABRÍCIO JUNQUEIRA 
Escola Politécnica, University of São Paulo, São Paulo, Brazil. fabri@usp.br  

PAULO EIGI MIYAGI 
Escola Politécnica, University of São Paulo, São Paulo, Brazil. pemiyagi@usp.br  

Received for review September 23 th , 2009, accepted March 2 th , 2010, final version April, 7 th , 2010 

ABSTRACT:  Nowadays,  there  is  a  trend  for  industry  reorganization in  geographically  dispersed  systems,  carried 
out  of  their  activities  with  autonomy.  These systems  must  maintain  coordinated relationship  among themselves  in 
order to assure an expected performance of the overall system. Thus, a manufacturing system is proposed, based on 
“web  services”  to  assure  an  effective  orchestration  of  services  in  order  to  produce  final  products.  In  addition,  it 
considers  special  functions,  such  as  teleoperation  and  remote  monitoring,  users’  online  request,  among  others. 
Considering the proposed system as discrete event system (DES), techniques derived from Petri nets (PN), including 
the Production Flow Schema (PFS), can be used in a PFS/PN approach for modeling. The system is approached in 
different levels of abstraction: a conceptual model which is obtained by applying the PFS technique and a functional 
model which is obtained by applying PN. Finally, a particular example of the proposed system is presented. 

KEYWORDS: manufacturing system, distributed system, web service, teleoperation. 

RESUMEN: Actualmente, una tendencia es la reorganización industrial en sistemas geográficamente dispersos, en 
la  ejecutando  sus  actividades  con  autonomía.  Estos  sistemas  deben  establecer  relaciones  coordinadas  a  fin  de 
asegurar el funcionamiento general del sistema. Así, este trabajo propone un sistema de manufactura basado en “web 
service”   para  asegurar  una  efectiva  orquestación  de  servicios  para  producir  productos  finales.  Adicionalmente,  es 
considerado funciones especiales, tales como teleoperación y el monitoreo remoto, solicitaciones online de usuarios, 
entre otras. Considerando el sistema propuesto como un sistema a eventos discretos (DES), técnicas derivadas de la 
rede de Petri (PN), incluyendo las de Production Flow Schema (PFS), pueden ser utilizadas en un abordaje PFS/PN 
para  modelado.  El  sistema  es  abordado  en  diferentes  niveles  de  abstracción:  uno  conceptual,  el  cual  es  obtenido 
aplicando técnicas PFS, y un modelo funcional, el cual es obtenido aplicando PN. Finalmente, el trabajo presenta un 
ejemplo del sistema propuesto. 

PALABRAS CLAVE: Sistema de manufactura, sistema distribuído, Web Service, teleoperacion. 

to  changes  in  customer  requests.  As  a  result, 

1.  INTRODUCTION  these enterprises are continuously reviewing and 
updating  their  structures  to  improve  their 
Recently,  the  demands  on  manufacturing  flexibility,  reconfigurability  and  interoperability 
enterprises have strongly increased to face global  [1].  In  general,  the  new  structures  need  to  deal 
competitiveness and to obtain a quickly response  with  heterogeneous  systems  and  their 
communication  incompatibility.

Dyna, year 77, Nro. 163, pp. 201­210.  Medellin, September, 2010.  ISSN 0012­7353 

202  Garcia et al 

It  due  to  the  diversity  of  involved  resources  services.  Second,  in  accordance  to  the  overall 
(devices,  protocols,  programs)  implement  in  the  manufacture  process  (to  produce  a  final 
manufacturing  process.  This  increases  the  product),  a  service  is  defined  to  integrate  and 
complexity  of  the  overall  system.  Thus,  coordinate  different  manufacturing  system 
specialists indicate a modular approach based on  modules involved. The resulting system is called 
the  definition  of  functionalities  [2].  Here,  the  coordinated  teleoperative  manufacturing  system 
term  functionality  represents  a  set  of  operations  (CTMS). In other words, it defines a hierarchical 
in the same scope. In this sense, service­oriented  structure  to  reach  a  service  orchestration  of 
architecture  (SOA)  has  emerged  as  a  way  to  manufacturing  modules.  In  fact,  this  system  is 
implement  distributed computing system,  where  being  implemented  based  on  an  advanced 
a functionality of each module can be requested  Internet  infrastructure  provided  by  the  FAPESP 
from other modules as a service, either locally or  TIDIA/KyaTera  program  [7].  This  program 
remotely, over  a  communication network [3].  considers a collaborative environment based on a 
Fiber­to­the­Lab network with at least 1.2 Gbps­ 
Web  service  (WS)  is  an  instance  of  this  speed  average.  This  research  addresses  the 
architecture  [2].  It  relies  on  a  set  of  standards  problem  of  characterization  of  CTMS  with 
including:  simple  object  access  protocol  remote monitoring and control of manufacturing 
(SOAP),  web  services  description  language  processes  without  time  constraint.  In  this  sense, 
(WSDL),  and  universal  description,  discovery  initially,  the  solution  adopted  in  this  work 
and integration (UDDI) to support autonomy and  considers  a  coordinated  transnational 
interoperability among applications developed in  architecture.  The  proposal  also  considers  new 
different  languages  and  running  on  different  challenges  for  the  monitoring  and  teleoperation 
platforms  or  operating  systems  [4].  [5]  presents  of  the  different  activities  involved  with 
an architecture for the integration of WS devices  coordinated,  distributed  and  dispersed 
with  enterprise  applications.  [2]  summarizes  manufacturing  systems.  The  term  teleoperation 
different  implementations  of  service­oriented  represents  a  human  operators’  support  in 
systems  in  industrial  applications  such  as:  situations  such  as:  conflicts  arbitration, 
manufacturing  and  logistic  system,  train  car  definition of productive activities to be executed, 
management  system,  control  system  for  among  others.  Nonetheless,  the  CTMS  involves 
semiconductor  processing  equipment.  In  this  different  kinds  of  functions  and  activities,  and 
context,  coordinated  teleoperated  systems  have  their  modeling  and  analysis  are  not trivial. 
arisen  as  an  alternative  solution  to  meet  actual 
demands,  such  as  structural  flexibility,  Therefore,  a  procedure  for  CTMS 
autonomy, interoperability, among others.  characterization  is  presented  here.  The 
characterization  task  is  based  on  the 
These  systems  encapsulate  several  productive  specification  of  CTMS  as  a  discrete  event 
modules  that  work  coordinately  in  an  system  (DES);  then,  techniques  derived  from 
autonomous  way  to  produce a final product.  interpreted  Petri  net  (PN)  are  considered  for 
These  modules  can  be  installed  in  a  distributed  system  modeling,  and  analysis  [8].  PN  is  a 
and geographically dispersed  configuration  [6].  graphical and mathematical modeling technique, 
In  this  context,  this  research  presents  characterized by their ability to handle operation 
architecture for  the  integration  and  coordination  sequence,  parallelism,  conflict  and  mutual 
of  manufacturing  systems  in  a  service­oriented  exclusion  [9].  PN  has  been  used  for  modeling 
approach.  The  characterization  of  this  dynamic  systems  in  a  wide  range  of  areas.  In 
architecture can be  divided  into two  main steps.  [10],  an  environment  for  distributed  modeling 
First,  the  plants  and  set  of  machines  that  and  simulation  of  productive  system  was 
compose  the  manufacturing  system  must  be  proposed.  In  [11],  it  was  used  to  specify  a 
structured  as  modules,  and  their  functional  distributed system protocol. In [12], a technique 
operations  are  grouped  according  their  based  on  PN  called  “open  workflow  net”  is 
functionality that  represents the  module service.  presented,  which  simplifies  the  WSs  definition, 
In  this  sense,  a  module  can  offer  several  integration,  and  coordination.  In  [13],  open
 Dyna 163, 2010  203 

workflow  nets  are  used  to  represent  both  basic  “ teleoperator´s  interface” ,  “ teleoperative”  
and structured activities of standard coordination  service,  “ supervisory  control” ,  “local  control” , 
of  WSs,  called  business  process  execution  “ database of system module” and “ devices” . 
language (BPEL).  customer’s 
Interface 
This  work is  organized as  follows. In section 2,  costumers 

the  framework  adopted  for  the  development  of  “request 

manager”” 
this  work  is  described.  Section  3  presents  the  service 

proposal  for  the  CTMS  modeling  procedure.  In  Database of 

CTMS 
“request 
observer” 
section  4,  an  example  illustrates  the  proposed 
procedure.  Finally,  in  section  5,  the  main  “integration and 
coordination” service 

conclusions are presented.  “teleoperative  “teleoperative 

manufaturing system ”  manufaturing system N” 
service  service 

2.  ARCHITECTURE DESCRIPTION  “teleoperative productive  Database of 

system” service  system module 

“teleoperative”  teleoperator’s 
The  architecture  considered  is  based  on  SOA,  Supervisory control 
service  interface 

promoting  interactions  among  customers,  local control 

teleoperator,  and  resources  involved  in  a 
distributed  manufacturing  system,  as  shown  in  devices 
(sensors, actuactors, etc) 
teleoperators 

Fig. 1. 
The “ customers”  are people who have access to  Figur e 1. Architecture for coordinated teleoperative 
the  system  by  the  customer´s  interface  with  an  manufacturing systems (CTMS) 
identification  and  password.  Also,  users  can 
check the production order status, cancel orders,  The “ teleoperative productive system”  service is 
and  make  new  orders.  Order  is  the  customers’  a WS. It exposes the productive functionality of 
request execution.  manufacturing system module that represents its 
The  “ request  manager”   service  is  a  WS  that  service,  and  enables  a  loosely  interaction,  by 
exposes  the  functionality  to  manage  customer  command  messages, between the  manufacturing 
requests.  In  fact,  it  interacts  with  the  module  and  the  “ integration  coordination”  
“ customer´s  interface” ,  the  “ integration  and  service. 
coordination”  service, and other entities such as  The  “ teleoperators”   are  special  users  that 
“ database”   and  “ request  observer”   in  order  to  interact  by  the  “ teleoperator´s  interface” .  They 
schedule the “ customer”  requests.  can  choose  between  two  operational  modes  for 
The “ request observer”  ensures that the number  the  “ devices”   under  their  responsibility: 
of  customer  orders  being  processed  do  not  teleoperation  or  monitoring  modes. 
exceed the number  of resources  available  in the  Teleoperation  mode  means  that  the 
CTMS.  “ teleoperator”   can  interact  with  the  “ devices”  
The “ database of CTMS”  is an entity that stores  from a remote location to decide about their next 
information  about:  “ customers” ,  “ customer”   actions.  On  the  other  hand,  in  the  monitoring 
requests,  tracking  “ customers”   requests.  This  mode, “ teleoperators”  are passive elements, and 
information  allows  scheduling  “ customer”   the  decisions  are  previously  programmed  in  the 
requests and tracks their execution.  “ teleoperative” service. 
The “ integration and coordination”  service is a  The  “ teleoperative”   service  is  a  WS  which 
WS  that  orchestrates  the  involved  WSs  to  exposes  the  teleoperation  functionality.  It 
produce a final product.  permits  “ teleoperators”,  geographically 
The  “ teleoperative  manufacturing  system”   dispersed,  to  manage  the  execution  productive 
service  exposes  each  manufacturing  system  process.  In  this  sense,  a  loose  interaction 
module  of  CTMS.  This  service  encapsulates  between  “ supervisory  control”   and 
several  components,  such  as:  “ teleoperative  “ teleoperators”   allows  managing  the  execution 
productive  system”   service,  “ teleoperators” ,  of  the  module  productive  process.
204  Garcia et al 

The  “ supervisory  control”   is  a  task  controller  system  to  define  its  limits  without  a  formal 
that  interacts  with  the “ teleoperative  productive  representation. 
system”   service,  “ teleoperative”   service,  and 
“ local  control” ,  to  manage  the  productive 
activities,  according  to  the  operational mode. 
The “ local control”  contains  a set  of functional 
blocks,  each  one  responsible  for  executing  a 
productive  activity.  The  “ supervisory  control”  
requires  these  functional  blocks  to  assure  the 
normal  productive  process  performance.  In  this 
sense,  several  “ local  control”   modules  can  be 
controlled  by  the  same  “ supervisory control”. 
The  “ database  of  system  module”   is  the  entity 
that stores information about each manufacturing 
system  module,  such  as:  execution  of  module  Figur e 2. Procedure to model the services of each 
productive  process,  “devices” ,  and  “ tele­  CTMS modules
operators” .  This  information  is  used  in  all  the 
process  steps,  for  example,  to  estimate  process  ·  Stage  A2:  Definition  of  each  manufacturing 
time  and  maintenance  time.  Moreover,  its  main  system module 
purpose is to be a gateway between fast Internet 
operations  (activities  that  take  milliseconds  or  The  information  obtained at  stage A1  is  used to 
seconds  to  be  performed)  and  productive  establish  the  manufacturing  system  module 
operations  (activities  that  take  minutes  or  hours  requirements.  These  requirements  are  presented 
to  be  performed).  The  characterization  of  as a set of functional operations, and are defined 
database  is  out  of  scope  due  the  fact  that  using  UML  use  case  diagram.  In  this  sense,  a 
temporal  constraints  are  not  considered here.  module  service  represents  a  set  of  clearly 
The “ devices”  are control elements at shop floor  defined functional operations..
level  such  as  sensors  and  actuators  that  allow  ·  Stage  A3:  Conceptual  and  functional 
developing  manufacturing activities.  modeling  of  each  manufacturing  system 
module 

3.  MODELING PROCEDURE APPROACH  The  modeling  of  each  manufacturing  system 

module  represents  all  functional  operations 
The procedure is divided into two parts. The aim  defined  through  the  UML  use  case  diagrams  in 
of  the  first  one  is  modeling  and  analysis  the  pre  stage.  It  is  systematically  developed  in 
procedure  to  define  the  services,  or  accordance  with  a  hierarchical  approach  using 
functionalities  perfectly  defined,  of  autonomous  the  PFS/PN  methodology  [14,  15].  Initially, 
sub­systems (modules) that integrate the CTMS.  using the PFS, a conceptual  model  is  developed 
This  part  of  the  procedure  is  composed  of  five  for  each  functional  operation.  It  is  mapped  into 
stages (Fig. 2). the PFS activity. Then, gradually, a refinement is 
conducted to obtain its detailed functional model 
·  Stage  A1:  Scope  about  each  manufacturing  in  an  interpreted  PN.  To  compose  the  PN 
system module  models,  the  transition  fusion  approach  is  used 
[16].
At  this  stage,  the  functional  characteristics  of 
each  manufacturing  system  module  is  identified  ·  Stage A4: Model analysis 
and  documented  initially  in  an  informal  mode. 
The  information  collected  is  used  to  make  a  Aimed  to  validate  and  verify  the  functional 
preliminary analysis and to identify relevant data  requirements  of  the  modules,  the  functional 
from each module. In this sense, the aim here is  models in PN obtained at stage A3 are submitted 
getting  knowledge  about  the  manufacturing  to  a  structural  and  dynamic  behavior  analyses,
 Dyna 163, 2010  205 

based  on  PN  properties.  The  properties  Initially, each coordinated functional operation is 

investigated  in  the  models  are:  deadlock,  mapped  into  an  activity  defined  in  PFS. 
stability  of  its  dynamic  behavior,  existence  of  Afterwards,  through  a  refinement  of  the  PFS 
specified  states,  for  example,  prohibited  states,  model that is gradually conducted, its functional 
achievable  and  critically  unreachable  states,  model in interpreted PN is derived.
among others. Thus, this work explores a formal 
·  Stage B3: Model analysis 
analysis  techniques  of  PN  combined  with 
simulation  techniques.  Here,  the  software 
Once  the  functional  models  of  CTMS  are 
HPSim  is used in the  development of this work.
obtained,  the  structural  and  behavior  analysis 
·  Stage A5: Componentization  based  on  PN  properties  of  these  models  are 
conducted in order to validate and to verify if the 
Once the manufacturing system module has been  requirements  and  functionalities  of  CTMS  are 
defined, the different  activities  can be arranged,  completed. 
according  to  their  function,  in components. 
Next,  the  complementary  part  of  the  proposed 
procedure  is  presented.  The  focus  here  is  the  4.  APPLICATION EXAMPLE 
composition  and  coordination  of  different 
activity  modules  of  the  manufacturing  systems  In  this  example,  the  CTMS  is  composed  by  the 
that  compose  the  CTMS.  This  part  of  the  following  manufacturing  sub­systems:  work­ 
procedure  is  carried  out in three stages (Fig. 3).  piece  supply  sub­system,  work­piece  inspection 
sub­system, pallet transportation sub­system, and 
product  assembly  sub­system.  In  addition, 
interfaces  must  be  considered  for  teleoperators 
and  customers  interaction.  These  sub­systems 
are treated as modules that are interconnected by 
a  communication  network  and  evidently  they 
must  work  coordinately  to  produce  a  customers’ 
Figur e 3. Procedure to integrate and coordinate 
requested  product.  This  disperse  manufacturing 
CTMS modules system  is  emulated  through  a  flexible  assembly 
system  installed  at  the  University  of  São  Paulo 
·  Stage  B1:  Definition  of  the  composition  and  (USP). 
coordination process 
The  “work­piece  supply”  module  executes  the 
This stage should consider the overall production  service  that  removes  a  work­piece  from  a 
process  or,  in  other  words,  the  sequence  of  buffer/magazine  and  puts  it  in  a  specified 
operations  from  the  customers’  requests  to  the  position  in the “work­piece  inspection”  module. 
end  of  the  process,  to  obtain  the  final  product.  The  “work­piece  inspection”  module  executes 
This  sequence  of  operations  is  exposed  as  a  services  related  to  quality  control  and 
service,  and  for  each  manufacturing  system  identification  of  the  work­pieces  physical 
module  involved  in  the  process,  a  functional  characteristic;  the  approved  ones  are  put  on  a 
operation  is  defined.  The  requirements  of  free pallet of the “pallet transportation”  module, 
process flow are established using UML use case  which  moves  the  pallet  to  the  “product 
diagram  for  each  coordinated  functional  assembly”  module.  When  a  pallet  with  a  work­ 
operation. piece reaches  the “product  assembly”  module, a 
·  Stage  B2:  Functional  modeling  of  robot performs different assembly activities. The 
composition and coordination process  assembly  service  is  carried  out  in  three  stages. 
Initially,  the  work­piece  is  placed  onto  an 
Using  the  PFS/PN  methodology,  the  functional  appropriate  base  where  the  product  assembly  is 
composition and coordination model is obtained.  realized,  i.e.,  according  to  the  work­pieces 
physical  characteristics,  the  specified  parts  are
206  Garcia et al 

assembled.  After  the  assembly  process  is  over,  accordance  with  the  incoming  signal  from  the 
the  final  product  is  put  on  a  free  pallet  for  the  “ telecommand  request”   function.  Meanwhile, 
“pallet  transportation”  module  to  leave  the  the  “ available”   functional  operation  indicates 
system.  The  type  and  number  of  products  for  the available conditions of the module to meet a 
assembly  are  defined  and  requested  by  the  request.  It  consults  other  two  functions 
customer  via  Internet.  Every  module  can  be  accounting  for  checking  the  status  of  “ devices”  
monitored  and  teleoperated  via  Internet.  In  the  and “ teleoperator” , i.e., “ device available”  and 
monitoring  mode,  information  of  each  module  “ teleoperator  available” .  The  “ teleoperator”  
function  is  provided  to  its  operator  in  order  to  can request the “ teleoperator access”  functional 
ensure  the  monitoring  of  remote  production  operation  to  access  the  module  under  his 
process  execution.  In  teleoperation  mode,  the  responsibility,  and  the  “ telecommand  request”  
operator can also  provide a series  of commands  functional operation, in which he can execute the 
for  the  execution  of  the  production  process.  teleoperation activities. 
In order to provide the product requested by the 
customers,  a  coordinated  work  is  established 
among  the  modules  involved  in  the  CTMS. 
Due  to  the  limited  space  available  for  this  text, 
just  a  sample  of  some  results  is  presented  here. 
In  this  sense,  the  “work­piece  supply  module” 
and  its  services  are  used  to  illustrate  the 
procedure  proposed  for  CTMS  modeling.
·  Stage  A1:  Scope  about  each  manufacturing 
system module 

The aim of the “work­piece supply module” is to 
Figur e 4. Work­piece supply module definition
provide  a  work­piece  for  the  “work­piece 
inspection  module”.  The  pneumatic  actuator 
devices  need  a  minimum  of  6  bar  (87  PSI)  ·  Stage  A3:  Conceptual  and  functional 
operating  pressure,  and  electro­mechanical  modeling  of  each  manufacturing  system 
devices  need  a  24V  electrical  energy  source.  module 
Concretely,  three  actuators,  five  electro­valve 
and six sensors (five magnetic, and an optic one)  In  Fig.  5,  the  refinement  of  the  “ work­piece 
are  used to  carry the work­piece supply service. request”   functional  operation  is  shown.  It 
·  Stage  A2:  Definition  of  each  manufacturing  presents  the  sequence  of  activities  performed  in 
system module  the  work­piece  service.  Initially,  the  functional 
operation  is  mapped  into  a  PFS  activity.  Thus, 
The  information  obtained  from  the  previous  [incoming  work­piece  request]  activity  is 
stage  is  used  to  define  the  work­piece  supply  activated  when a  work­piece request  message  is 
module  behavior  and  functional  operations.  received.  Then,  [sending  execution  request] 
These  operations  are  represented  in  a  UML  use  activity prepares and sends a message to activate 
case diagram (Fig. 4). In this sense, this  module  the  [execution  request]  activity,  which  is  an 
provides  functional  operations  for  the  “ CTMS”   activity  defined  in  accordance  with  the  work­ 
and  “ teleoperator”   actors.  The  “ CTMS”   can  piece  process  that  executes  the  manufacturing 
invoke  the  “ work­piece  request”   and  the  tasks. Next, a “stand by” state is instanced. Then, 
“ available”   operations.  Once  the  “ work­piece  the  [incoming  execution  notification]  activity  is 
request”   functional  operation  is  activated,  it  activated  when  a  message  from  the  [execution 
calls the “ execution request”  function to develop  request]  activity  is  received  with  the  execution 
the  work­piece  process.  To  execute  the  work­  status.  Finally,  the  [sending  work­piece 
piece process, the  device activities  are activated  notification] activity is executed, sending back a 
by  the  “ execution  activities”   function  in  message to the CTMS.
 Dyna 163, 2010  207 

Figur e 7. Refinement of the [telecommand 

Figur e 5. Refinement of the [work­piece request]  request] activity 
activity 

Fig.  6  presents  the  refinement  of  the  [execution 

request]  activity.  Initially,  the  [incoming 
execution  request]  activity  is  activated  when  a 
request  message  is  received.  Next,  a  cycle  of 
process  activity  requests  based  on  telecommand 
response is carried out. Therefore, the [sending a 
telecommand  request]  activity  prepares  and 
sends  a  request  message,  which  activates  the 
[telecommand  request]  activity.  Based  on  the  (a)  (b) 
response  of  telecommand,  received  by  the 
[incoming  telecommand  response]  activity,  a  Figur e 8. Refinement of the [teleoperation mode] 
request  message  is  sent  by  the  [sending  activity 
execution  request].  State  information  of  shop­ 
floor­devices,  is  received  by  the  [incoming  The  [teleoperation  mode]  activity  is  detailed  in 
execution  notification]  activity  after  the  activity  Fig.  8a.  This  activity  is  developed  concurrently 
execution  and  it  is  registered  by  the  [tracking  with  the  [teleoperation  function]  activity. 
device request] activity.  Therefore,  its  first  activity  is  completed  by  the 
[incoming  telecommand  state  inquiry]  when  it 
receives  a  request  message  about  the  state  of 
telecommand  from  [sending  telecommand  state 
request]  activity.  Then,  a  wait  state  is  instanced 
until  the  [sending  telecommand  state]  activity 
prepares and sends a status response message to 
the  [incoming  telecommand  state  response] 
Figur e 6. Refinement of the [execution request] 
activity  activity.  After  that,  it  keeps  waiting  until  the 
[sending  telecommand  authorization]  activity 
The [telecommand request] activity is detailed in  sends  a  telecommand  message  to  the  [incoming 
Fig. 7. It is activated when a message is received  telecommand authorization] activity. 
by the [incoming telecommand request] activity.  At  this  refinement  point,  a  functional  model  is 
The  requester  message  is  registered  by  the  generated  (Fig.  8b).  In  this  way,  the  requester 
[registration  telecommand  request ]  activity.  transition  (T1b)  sends  a  telecommand  state 
Depending on the operation mode, the activation  request message to its paired requested transition 
of  the  [monitoring  mode]  activity  or  (T1a).  Similarly,  the  requester  transition  (T2a) 
[teleoperation  mode]  activity  is  selected.  The  sends  the  corresponding  telecommand  response 
register of the telecommand status is carried out  message  to  its  requested  transition  (T2b). 
by the [telecommand state actualization] activity.  Finally,  the  requester  transition  (T3b)  sends  a 
Finally,  a  message  with  the  status  of  telecommand authorization message to its paired 
telecommand  is  sent  back  by  the  [sending  requested  transition  (T3a),  which  received  the 
telecommand response] activity.  information.
208 Garcia et al 

·  Stage A4: Model analysis  control” ,  based  on  the  information  received 

from the “ teleoperator” . 
Based on PN properties, to validate and to verify  The  “ local  control”   defines  and  executes 
the  functional  correctness  of  work­piece  supply  interactions  with  devices  located  at  shop­floor 
services, the state space of the functional  model  devices  to  develop  the  process activities. 
is  generated. From a specific initial state (initial  Next,  the  proposed  procedure  is  applied  to 
marking  of  PN)  behavioral  properties  of  the  compose  and  coordinate  the  services  of  all  the 
module  are  verified  through  the  state  space  modules that compose the CTMS.
resulting  from  the  transitions  firing  of  PN. 
·  Stage B1: Definition of the composition, and 
Examples  of  such  properties  are  the  absence  of 
coordination process 
deadlock in the supply service, the possibility of 
always  reaching  a  given  state,  and  the  delivery 
In  Fig.  10,  the  “ integration  and  coordination”  
guarantee  of  a  given  service.  The  HPSim  tool 
service  definition  is  presented.  Thus,  the 
was  used  here  for  the  model  simulation,  and  to 
composition  and  coordination  of  functionalities 
validate it.
of  different  manufacturing  systems  involved  in 
·  Stage A5: Componentization  the  final  product  process  are  defined  using  the 
UML use case diagram. 
According  its  functionality,  the  activities  of 
“work­piece  supply  module”  are  classified  into 
five  components:  “ teleoperative  work­piece 
supply”   service,  “ teleoperation”   service, 
“ supervisory  control” ,  “ local  control” ,  and 
“ teleoperator´s interface” (Fig. 9). 

Figur e 10. Definition of “integration and 
coordination” service 

At this level of abstraction, the CTMS is related 
with  the  following  actors:  “ customers” , 
“ requester  observer” ,  “ work­piece  supply 
module” ,  “ work­piece  inspection  module” , 
“ pallet  transportation  module” ,  and  “ product 
Figur e 9. Components of the “ work­piece supply  assembly module”. 
module” : (a) “ teleoperative  work­piece supply”   The  CTMS  exposes  the  functional  operations, 
service, (b) “ teleoperative”  service, (c)  “ new  request  register”   and  “ request  register 
“ teleoperator´s interface” , (d) “ supervisory control” ,  inquiry”,  allowing  “ customers”   to  send  new 
(e) “ local control”   product  requests  and  to  monitor  requests 
previously made. 
The “ teleoperative work­piece supply”  service is  The  “ request  observer”   requests  the  “ state 
a  WS  that  exposes  the  productive  functionality  request  inquiry”   functional  operation.  If  the 
of a  module as  a service. It  can be accessed  via  system  has  productive  resources  to  meet  a 
communication network.  costumer  request,  the  “ coordination  available”  
The “ teleoperation”  service is a WS that permits  functional  operation  is  used  and  an  instance 
a  loosely  interaction  between  “ supervisory  functional  operation  of  “ tracking  request”   is 
control”   and  “ teleoperator”   to  set  the  supply  activated.  To  permit  an  incoming  response 
process activity execution.  message  from  “ work­  piece supply module” , 
The  “ supervisory  control”   coordinates  the  the  “ work­piece  supply  response”   functional 
execution  of  the  supply  process  in  the  “ local  operation  is  available.  In  the  same  way  “ work­
 Dyna 163, 2010  209 

piece  inspection  response” ,  “ pallet  transitions  pair  (T2a,  T3b),  where  T3b  is  a 
transportation  response”,  and  “ product  requester  transition  to  send  a  notification 
assembly  response”   operations  permit  an  message,  and  T2a  is  a  requested  transition  to 
asynchronous interaction with the actors: “ work­  receive the message. 
piece inspection module” , “ pallet transportation 
module” ,  and  “ product  assembly  module” , 
respectively.
·  Stage  B2:  Functional  modeling  of 
composition and coordination process 

Initially,  each  functional  operation  is  mapped 

into a PFS activity. For instance, Fig. 11 shows 
the  “ work­piece  supply  response”   operation  as 
[work­piece  supply  response]  activity.  It  is 
activated  when  a  response  message  from  the  Figur e 12. Functional model of [sending correlation 
request], [incoming correlation notification], and 
“work­piece supply  module” is  received. In this  [correlations request] activities
sense,  its  first  activity  is  [incoming  work­piece 
supply  response].  After  that,  the  [sending  ·  Stage B3: Model analysis 
correlation request] activity prepares and sends a 
request  message  to  validate  the  incoming  Once  the  PN  functional  models  of  CTMS  are 
message.  obtained, an analysis of interactions is conduced. 
Considering  specific  scenarios,  i.e.,  initial  state 
(PN initial marking), the state space is obtained. 
The  state  space  allows  verifying  the  process 
definition, for example, if the process activity is 
properly  performed,  or  identifies  conflicts  in 
messages broadcast. The validation of the model 
is  carried  out  through  structural  analysis  of  the 
Figur e 11. Definition of the [work­piece supply  PN  and  simulation  techniques  using  the  HPSim 
response] activity  tool. 

Then,  the [work­piece  supply  response]  activity 

waits  for  the  response.  If  the  message  is  5.  CONCLUSIONS 
validated,  the  next  activity,  [sending  working­ 
piece inspection request], is activated. Finally, a  Increased  demand  and  technological  advances, 
register  of  process  execution  is  carried  out  with  with  respect  to  hardware  and  information 
the  activation  of  [sending  tracking  request]  technology  (as  shown  by  the  internet 
activity  and  sending  its  information  through  the  infrastructure  provided  by  the  KyaTera  project) 
[incoming tracking notification] activity.  encourages  the  adoption  of  more  flexible 
The  functional  and  interpreted  PN  model  of  productive  structures.  The  proposed  approach 
[sending  correlation  request],  [incoming  considers  the  iterations  among  teleoperators, 
correlation  notification],  and  [correlations  productive resources and customers, and also the 
request]  activities  are  shown  in  Fig.  12,  where  fact  that  they  can  be  geographically  dispersed. 
the requester transition (T1a) sends a correlation  Teleoperators  can  act  in  two  ways:  monitoring 
request for its paired requested transition (T1b).  and teleoperating.  To  characterize  the  dispersed 
Then, a state for preparing the correlation is met  productive  system,  a  modeling  and  analysis 
(L2b). The  incoming  message is  compared  with  procedure  was  also  proposed  based  on  a  formal 
the  customer  request  being  validated.  This  tool,  derived  from  interpreted  PN  that  permits 
procedure  is  executed  in  the  internal  transition  validation  and  verification  of requirements.
(T2b).  The  response  is  represented  by  the 
210  Garcia et al 

6.  ACKNOWLEDGMENTS  Discretos. São Paulo, Ed. Edgard Blücher, 1996. 

(In Portuguese). 
The  authors  would  like  to  thank  the  partial 
[9]  AGUIRRE,  L.A.;  BRUCIAPAGLIA,  A.H.; 
financial  support  of  the  Brazilian  governmental 
MIYAGI,  P.E.;  and  CALDEIRA,  R.H. 
agencies CNPq, CAPES, and FAPESP, specially 
Enciclopédia  de  Automática.  Editora  Edgard 
the TIDIA/KyaTera committee. 
Blucher, 1, 2007. 

REFERENCES  [10]  JUNQUEIRA,  F.;  and  MIYAGI,  P.E.  A 

new  method  for  the  hierarchical  modeling  of 
productive  systems.  IFIP  International 
[1]  WU,  B.;  XI,  L.­F.;  and  ZHUO,  B.­H.  Federation  for  Information  Processing,  V.  220, 
Service­oriented communication architecture for  Information  Technology  for  Balanced 
automated  manufacturing  system  integration.  Manufacturing  Systems,  Ed.  V.  Shen,  Boston: 
International  Journal  of  Computer  Integrated  Springer, 479­488, 2006. 
Manufacturing, 21 (5), 599­615, 2008. 
[11] KANESHIRO, P.J.I.; GARCIA MELO, J.I.; 
[2]  KOMODA,  N.  Service  oriented  architecture  and  MIYAGI,  P.E.  Modeling  of  collision 
(SOA) in industrial systems. Proc. of IEEE Conf.  resolution  algorithm  in  Lonworks  networks. 
on Industrial Informatics, 1, 1­5, 2006.  Proc.  of  IMECE´07  the  ASME  International 
Mechanical  Engineering  Congress,  Seattle. 
[3]  ROSEN,  M.;  LUBLINSKY,  B.;  SMITH,  USA, 2007. 
K.T.;  and  BALCER,  M.J.,  Applied  SOA 
Service­Oriented  Architecture  and  Design  [12]  MASSUTHE,  P.;  REISIG,  W.;  and 
Strategies. Indiana, Wiley Publishing, 2008.  SCHMIDT, K. An operating guideline approach 
to  the  SOA.  Techn.  Report  191,  Humboldt­ 
[4]  CERAMI,  E.  Web  Service  Essentials.  Universit at zu Berlin, 2005. 
O’Really, 2002. 
[13]  LOHMANN,  N.  A  feature­complete  Petri 
[5]  MOREIRA,  S.L.;  SPIESS,  P.;  GUINARD,  net  semantics  for  WS­BPEL  2.0.  Proc.  of 
D.;  KOHLER,  M.;  KARNOUSKOS,  S.;  and  FABPWS’07  the  Workshop  on  Formal 
SAVIO,  D.  SOCRADES:  a  web  service  based  Approaches  to  Business  Processes  and  Web 
shop  floor  integration  infrastructure.  Proc.  of  Services, 1, 21­35, 2007. 
International  Conference  for  Industry  and 
Academia, Zurich, Switzerland, 50­67, 2008.  [14]  HASEGAWA,  K.;  TAKAHASHI,  K.;  and 
MIYAGI,  P.E.,  Application  of  the  Mark  Flow 
[6]  GARCIA  MELO,  J.I.;  JUNQUEIRA,  F.;  Graph  to  represent  discrete  event  system  and 
MORALES,  R.A.;  and  MIYAGI,  P.E.  A  system  control.  Trans.  of  the  Society  of 
procedure for  modeling and analysis  of service­  Instrument  and  Control  Engineer,  24,  67­75, 
oriented  and  distributed  productive  systems.  1988. 
Proc.  of  CASE’08  the  IEEE  Conf.  on 
Automation  Science  and  Engineering,  1,  941­  [15]  JUNQUEIRA,  F.;  and  MIYAGI,  P.E. 
946, 2008.  Modelagem e Simulação Distribuída de Sistema 
Produtivo  Baseados  em  Rede  de  Petri.  SBA  ­ 
[7]  TIDIA­KyaTera  –  Advanced  Internet  Sociedade  Brasileira  de  Automática,  20,  1­19, 
Program,  FAPESP,  Brazil.  Available:  2009. 
http://kyatera.incubadora.fapesp.br  [January,  8 th , 
2007].  [16]  GOMES,  L.;  and  BARROS,  J.  Structuring 
and composability issues in Petri nets modeling. 
[8]  MIYAGI,  P.E.  Controle  Programável:  IEEE  Trans.  on  Industrial  Informatics,  1,  112­ 
Fundamentos do Controle de Sistemas a Eventos  123, 2005.