Вы находитесь на странице: 1из 19

MODELAGEM E SIMULAO DISTRIBUDA DE SISTEMA PRODUTIVO BASEADOS EM REDE DE PETRI

Fabrcio Junqueira
fabri@usp.br

Paulo Eigi Miyagi


pemiyagi@usp.br

Escola Politcnica da USP Departamento de Engenharia Mecatrnica e de Sistemas Mecnicos CEP 05508-030 So Paulo, SP

RESUMO
Em funo da capacidade computacional instalada e da estrutura dispersa de alguns sistemas produtivos, existe interesse em solues de modelagem e simulao distribuda destes sistemas. Isso considerado como um recurso fundamental para o projeto, implementao e melhoria de desempenho desses sistemas produtivos. A idia que por meio de simulaes com o uso de computadores sicamente dispersos, mas integrados atravs de uma rede de comunicao, podese avaliar o comportamento de sistemas em concepo e melhorar resultados de plantas existentes. Este trabalho prope assim, um procedimento para a modelagem de sistemas produtivos em ambientes distribudos. Esse procedimento foi aplicado com sucesso a alguns estudos de caso onde sua eccia foi conrmada. Este trabalho envolve ainda a proposta de um algoritmo para o gerenciamento da simulao distribuda. Com o mtodo de modelagem e o algoritmo de gerenciamento tem-se os principais elementos para a implementao prtica de um simulador de sistemas produtivos dispersos.
PALAVRAS-CHAVE: sistema produtivo disperso, simulao

infrastructure of some productive systems, there are interest for distributed modeling and simulation of these systems. These techniques are considered fundamental for design, implementation and performance improvement of productive systems. The approach is the simulation through the use of computers physically dispersed but integrated via a communication network to evaluate the behavior of systems still in conception level and also to improve the performance of existing plants. This work proposes a procedure for modeling of productive systems in distributed environment. This procedure was applied to case studies to conrm it effectiveness. The work includes an algorithm for the management of the distributed simulation. With the modeling method and the management algorithm we have the main elements for the practical implementation of the disperse productive system simulator.
KEYWORDS: disperse productive system, distributed simulation, Petri net.

1 INTRODUO
Algumas empresas do setor de manufatura vm se estabelecendo de maneira distribuda e dispersa devido globalizao do mercado e a necessidade de atender demandas locais envolvendo inclusive fatores scio-culturais. Eles aproveitam o crescimento e a capilaridade das redes de comunicao e da tecnologia da informao. Estas empresas deixam de ser consideradas como uma entidades isoladas, mas sim como partes de um consrcio de empresas cooperativas (Shi, Gregory, 1998) (Zhang, et al., 2006) (Shi et al., 2002), e este

distribuda, rede de Petri.

ABSTRACT
Based on the existing computational capability and disperse
Artigo submetido em 28/04/2008 (Id:872) Revisado em 03/12/2008 Aceito sob recomendao do Editor Associado Prof. Jos Reinaldo Silva

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

novo padro de relacionamento pode ser identicado como um novo paradigma de produo, chamado de rede de manufatura dispersa (Zhan et al., 2003) (Cheng, Cheng, 2006). Uma rede de manufatura dispersa consiste de instalaes fsicas que esto geogracamente dispersas, mas precisam se comunicar e trabalhar cooperativamente trocando uma grande quantidade de informaes e dados entre suas prprias fbricas, empresas terceirizadas e fornecedores. O projeto e operao deste tipo de sistema produtivo requerem uma abordagem de projeto distribudo, em que equipes geogracamente distribudas em diferentes locais fsicos colaboraram para a especicao do sistema e avaliao dos processos produtivos. A evoluo da tecnologia da informao e sua aplicao nos processos produtivos permitiram a integrao de sistemas heterogneos (Sanz, Alonso, 2001) (Sanz et al., 2003). Como um exemplo, um sistema supervisrio industrial interage com um conjunto heterogneo de hardware e software (por exemplo: estaes de trabalho, unidades remotas, controladores programveis, etc), a m de monitorar e controlar um processo industrial. A integrao de sistemas heterogneos aumenta a complexidade na tarefa de analisar o sistema e requer o desenvolvimento de novas solues. Entre elas, o uso da simulao distribuda merece ateno especial. A simulao distribuda trata da execuo de programas computacionais em equipamentos geogracamente dispersos conectados atravs de uma rede de comunicao, o que pode ser visto como um tipo de supercomputador virtual (Fujimoto, 1999) (Banks, 2000) (Karatza, Theodoropoulos, 2006) (McLean, Riddick, 2001). Neste contexto, o objetivo deste trabalho apresentar uma nova abordagem de modelagem de sistemas prpria para a simulao distribuda e, como esta simulao pode ser, de fato, implementada num ambiente disperso. Esta abordagem de modelagem baseia-se no conceito de orientao a objeto e rede de Petri associado a um procedimento de renamento progressivo. E, para que os modelos sejam efetivamente integrados e simulados concomitantemente com outros modelos em um ambiente geogracamente distribudo, um algoritmo de gerenciamento da comunicao tambm introduzido. Na seo 2, conceitos bsicos adotados neste trabalho so discutidos. A seo 3 apresenta o procedimento para a modelagem hierrquica de sistemas produtivos. A seo 4 apresenta um exemplo em que o procedimento aplicado modelagem de um sistema de transporte de material. Na seo 5 apresentado um algoritmo para gerenciamento da comunicao para a simulao distribuda e dados de alguns experimentos so citados na seo 6. A seo 7 apresenta as consideraes nais sobre este trabalho.

2 CONCEITOS BSICOS
Algumas razes para distribuir a simulao entre vrios computadores so: Reduo do tempo de execuo de experimentos atravs da diviso do modelo de simulao entre os processadores; Possibilidade de trabalhar com modelos mais detalhados de cada processo j que a dimenso do modelo total no mais um problema; Possibilidade de trabalhar com informaes mais precisas de cada parte (cada planta) do sistema que podem ser modelados e simulados localmente sem obrigatoriamente necessitar de informaes adicionais sobre esses modelos especcos de cada uma das partes envolvidas; e Aumento do grau de tolerncia falha, isto , se um processador falhar, outros processadores podem continuar a simulao. Preocupados com a complexidade desse tipo de simulao, alguns pesquisadores enfatizam o emprego de modelos reaproveitveis baseados em componentes (Fujimoto, 1999) (Karatza, Theodoropoulos, 2006) (Kachitvichyanukul, 2001). Um componente pode ser selecionado a partir de um repositrio e ser usado sozinho, ou ser combinado com outros para gerar um novo componente. Um problema inerente da simulao distribuda a partio do modelo entre os processadores, e algumas propostas utilizam o conhecimento prvio do sistema modelado para otimizar a simulao (Nevison, 1990). No entanto, a otimizao da simulao torna-se invivel quando se trabalha com tcnicas genricas de modelagem e nmero indenido de processadores. Neste caso, a tcnica de modelagem no restringe o tipo de sistema produtivo em estudo. , portanto, impossvel a utilizao de estratgias de otimizao baseadas no conhecimento prvio sobre o sistema, bem como o nmero de processadores a ser utilizado na simulao. Por outro lado, os modelos baseados em sistemas a eventos discretos (SED) so intensamente utilizados para descrever, analisar e controlar processos em sistemas produtivos. Estes sistemas so caracterizados por estados discretos e ocorrncia de eventos instantneos, que regem a sua dinmica. A evoluo destes sistemas baseada em regras que denem as condies para a ocorrncia de eventos, bem como o novo estado alcanado aps um evento (Cassandras, Strickland, 1992). Neste contexto, a rede de Petri uma tcnica de modelagem grca e matemtica que descreve com clareza

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

interaes entre processos que caracterizam um SED (Murata, 1989) (Villani et al., 2007) e, explorando isto, ele tem sido utilizado intensamente para modelar sistemas dinmicos em uma ampla gama de reas (Davrazos, Koussoulas, 2007) (Miyagi, Riascos, 2006) (Tolba et al., 2005). Os pesquisadores tambm apontam a modelagem hierarquizada como uma forma de lidar com sistemas de grande porte com grande nmero de interaes entre seus elementos (Kachitvichyanukul, 2001) (Daum, Sargent, 1999, 2002) (Carullo et al., 2003) (Gomes, Barros, 2005). O modelador pode dividir este sistema em subsistemas (e conseqentemente submodelos), que so relativamente mais fceis de serem trabalhados. Os modelos podem ser gerados em diferentes nveis de abstrao, ajudando a vericao e validao dos processos. No domnio da simulao distribuda com rede de Petri, duas solues so comumente consideradas: computadores paralelos e computadores em rede. No primeiro caso, o esforo de computao para simular um modelo de grande porte distribudo em um ambiente multi-processado (Fujimoto, 2003) (Perumalla et al., 2005) (Nicol, Roy, 1991) (Chiola, Ferscha, 1993) (Kumar, Kohli, 1997) (Beraldi, Nigro, 1999). Contudo, a partio do sistema e a distribuio de processamento transparente para os usurios. Do ponto de vista do usurio, a simulao realizada como um sistema nodistribudo. Os principais inconvenientes desta soluo so custos relativamente elevados e uma abordagem de modelo centralizadora. Alguns pesquisadores propem a criao e manuteno de uma lista global de eventos que devero ocorrer (Chiola, Ferscha, 1993) (Djemame et al., 1998). A lista por sua vez classicada e dividida entre os vrios processadores. Cada processador, em seguida, gerencia a sua prpria lista local. A partio do modelo pode resultar em conitos, como quando um estado a pr ou ps-condio de dois ou mais eventos alocados em diferentes processadores. Neste caso, os processadores trocam um conjunto de mensagens para resolver o conito preservando a causalidade entre os eventos. Entretanto, com os avanos da informtica e de tecnologias de rede de comunicao, a segunda soluo tem se tornado cada vez mais atraente (Nketsa, Valette, 2001). Uma das suas principais vantagens a possibilidade de explorar a capacidade em geral ociosa de computadores dispersos geogracamente. Esta a soluo adotada no presente trabalho. Um dos principais problemas da simulao distribuda com rede de Petri como gerenciar a simulao de forma a garantir a consistncia e coerncia dos resultados. A soluo proposta na literatura disponvel pode ser agrupada em duas classes: a abordagem conservadora e a otimista. A abordagem conservadora evita erros de causalidade atravs do bloqueio da ocorrncia de eventos que so considerados como inseguros, isto , eventos que podem levar a uma situao

onde as restries de causalidade so violadas (Beraldi, Nigro (1999). Como resultado, todos os ns (computadores ou processadores) devem compartilhar o mesmo clock de simulao. Por outro lado, a abordagem otimista permite um certo grau de ocorrncia de eventos inseguros e cada n possui um clock virtual local. Quando as restries de causalidade so violadas, a simulao deve reverter as ltimas operaes realizadas at que um estado seguro seja alcanado (o que chamado de rollback). A simulao ento recomea a partir deste estado. Umas das implicaes desta abordagem que cada n deve manter um registro de suas ltimas operaes. Para gerenciar o tamanho do registro, o clock virtual global indica o tempo do ltimo estado seguro e limita a memria usada pelo algoritmo. Essa abordagem normalmente utilizada na computao paralela com memria compartilhada, que explora o paralelismo inerente aos modelos quando comparado com o protocolo conservativo. No entanto, grande parte do esforo computacional perdida devido s operaes de retorno at o ultimo estado seguro (rollback). Na simulao distribuda, quando uma rede de computadores empregada, resulta-se no no compartilhamento de memria. Alm disso, a possibilidade de operaes de rollback associada com as vrias mensagens que so normalmente trocadas entre computadores pode resultar na sobrecarga do trfego da rede.

3 PROCEDIMENTO PARA A MODELAGEM


O modo pelo qual o sistema produtivo modelado baseado tanto nas suas caractersticas como a sua complexidade, bem como em fatores pessoais como experincia da equipe de projeto e no nvel de abstrao desejado. Em qualquer caso, a equipe de projeto deve ser capaz de visualizar o sistema produtivo (ou as principais partes em estudo) como um todo, as partes que o compe, seu comportamento e a relao entre as partes (suas interfaces).O procedimento de modelagem ento organizado em passos, que so discutidos a seguir. Passo 1 Denio do problema e delimitao do escopo do sistema produtivo O modelador deve delimitar o mbito do sistema produtivo em estudo, ou seja, aquilo que os departamentos, equipamentos (ferramentas) e pessoas (ambos considerados como recursos do sistema produtivo) envolvidos e, quais caractersticas e processos a serem modelados e analisados. Passo 2 Renamento sucessivo visando a identicao dos elementos bsicos que compe o sistema e seus relacionamentos
3

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

A abordagem top-down adotada nessa etapa. O uso de tcnicas de modelagem como PFS (Production Flow Schema) auxiliam na tarefa de construo do modelo do sistema produtivo (Hasegawa et al., 1999) (Miyagi et al., 2000). O PFS um tipo de rede de Petri composto de atividades, elementos distribudos e arcos. O PFS propcio para descrever a relao estrutural entre as principais partes do sistema. Este o modelo conceitual aplicado na fase inicial da modelagem do sistema que gradativamente traduzido em modelos em rede de Petri (este texto considera a classe especca de rede de Petri lugar/transio temporizada), que representa os detalhes e o comportamento dinmico das atividades. Tcnicas de simplicao tambm so aplicadas neste processo. No nal desta fase, um conjunto de processos e elementos bsicos que constituem o sistema produtivo identicado, assim como o relacionamento entre eles, isto , suas interfaces e o formato das mensagens trocadas entre eles. Passo 3 Modelagem dos elementos bsicos utilizando redes de Petri Nesta etapa, as funcionalidades dos elementos bsicos so modeladas com auxlio da rede de Petri. Cada modelo chamado classe (Fig. 1a). Similar s linguagens de programao orientadas a objeto, a classe descreve um conjunto de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semntica. O modelo de cada elemento bsico pode ser analisado isoladamente, facilitando a validao antes de sua utilizao para compor modelos de elementos mais complexos. Passo 4 Denio dos objetos Cada classe denida no passo 3 usada como elemento bsico para gerar um ou mais objetos. A abordagem bottom-up , ento, utilizada. Passo 5 Gerao de componentes Uma vez que os objetos foram denidos, eles podem ser combinados para formar um componente mais complexo. Esta fase tem trs sub etapas: 1. Encapsular os objetos em componentes; 2. Conectar as interfaces dos objetos; e 3. Mapear as interfaces dos objetos remanescentes como interface de componente.
4

Classe 1

(a)

Entrada

Objeto 1

Objeto 2

Componente 1

Sada
Objeto 3

(b)
Figura 1: (a) classe implementada em rede de Petri; (b) componente constitudo por trs objetos.

O processo de criao de componentes comea usando os objetos denidos no passo 4. Objetos que compartilham algumas caractersticas em comum, ou precisam trabalhar conjuntamente para a execuo de uma tarefa, so agrupados (i) formando um componente (Fig. 1b). A seguir, (ii) as interfaces dos objetos so denidas e conectadas (setas cinzas na Fig. 1b). No presente procedimento, as interfaces so modeladas como transies1 e a relao entre os modelos so realizadas atravs da fuso de transies (Fig. 2) (Gomes, Barros, 2005) (Sibertin-Blanc, 1993). A chamada de mtodo deve obedecer a seguinte regra: uma vez que um objeto faz a chamada de um mtodo a um segundo objeto, ele deve esperar a resposta, no importa quanto tempo isso leve. Se um segundo objeto estiver executando a chamada de um mtodo a um terceiro objeto no mesmo instante, ele ir adicionar o pedido a uma lista de pedidos e
1 Neste

texto, termos especcos da rede de Petri esto em Arial Narrow.

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Obj1 Componente

Obj2

Para gerar um aplicativo, dois ou mais componentes so agrupados e suas interfaces so conectadas (Fig. 4). Este passo similar ao anterior. A diferena que o aplicativo no possui interface externa. Em outras palavras, fazendo uma analogia com elementos de software, um componente semiacabado no executa nada e pode ser usado em diferentes contextos, enquanto um aplicativo possui todos os elementos necessrios para trabalhar sozinho e possui um propsito bem denido.

(a)
Obj1.L1 Obj2.L1

4 EXEMPLO
Para ilustrar a aplicao do processo, um exemplo prtico apresentado focando os aspectos mais relevantes do procedimento. Passo 1 Denio do problema e delimitao do escopo do sistema produtivo Considera-se que quatro estaes de trabalho compem um sistema de transporte de material. Cada estao produz ou consome produtos. A estao A fornece produtos para a estao B, e a estao C fornece produtos para a estao D. Um transportador, com capacidade unitria usado para o transporte de produtos como mostrado na Fig. 5a. Cada estao possui o seu tempo de processamento. As estaes A e C entregam o produto (e as estaes B e D recebem o novo produto) quando elas terminam suas tarefas, isto , aps os respectivos tempos de processamento. A tarefa para o carregamento de produtos do transportador para a estao e vice versa no considerada neste exemplo, isto , entende-se que ela no consome tempo relevante. No entanto, o tempo de transferncia, isto , de movimentao do transportador modelado sendo que ele permanecer parado at a concluso dessa transferncia. Passo 2 - Renamento sucessivo visando a identicao dos elementos bsicos que compem o sistema e seus relacionamentos Baseado na descrio do sistema, o PFS usado para modelar as principais atividades, assim como detalhar os seus relacionamentos. A Fig. 5b representa o PFS do sistema mostrado na Fig. 5a. Este grafo representa a movimentao circular do transportador e a passagem do transportador atravs das estaes. Algumas atividades deste modelo podem ser destacadas: (1) [Transporte entre duas estaes]; (2) [Parada na estao] onde as mercadorias so (des)carregadas; (3) [Transportador]; e (4) [Estao]. Alm disso, as setas azuis representam as informaes trocadas entre [Parada na estao] e [Estao], e as setas cinzas, as informaes entre [Parada na estao] e [Transportador].
5

Obj1.T1

(ObjIP, ObjID, Return)

Obj2.T1

Obj1.L2

Obj2.L2

Obj1.T2

Obj2.T2

Obj1.L3

Obj2.L3

(b)
Figura 2: Exemplo de interface de um objeto: (a) representao esquemtica; (b) Representao de uma rede de Petri com fuso de transies.

executa este assim que possvel. Um exemplo ilustrado na Fig 3. Na Fig. 3a, o objeto 3 envia uma chamada de mtodo ao objeto 2, mas o objeto 2 ainda est executando o mtodo solicitado pelo mtodo 1. Na seqncia, Fig. 3b ilustra os trs objetos aps a resposta do objeto 2 ao objeto 1. Na Fig. 3c, o mtodo do objeto 2 est agora disponvel e, na Fig. 3d, o objeto 2 est executando o mtodo do objeto 3. No modelo em rede de Petri, esta regra implica que as transies que representam a chamada de mtodo no podem estar em conito com outras transies. Esta segunda regra tambm determina que as transies associadas chamada de mtodo so sempre instantneas. Para concluir o modelo de componente, necessrio (iii) mapear as interfaces dos objetos remanescentes como interface de componente. As setas azuis (slida e tracejada) na Fig. 1b so um exemplo deste mapeamento. Passo 6 Gerao do aplicativo

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Obj1.L1

Obj2.L1

Obj3.L1

Componente 5
Obj1.T1 Obj2.T1 Obj3.T1

Componente 1

Obj1.L2

Obj2.L2

Obj3.L2

Obj1.T2

Obj2.T2

Obj3.T2

Componente 4
Obj1.L3 Obj2.L3 Obj3.L3

(a)
Obj1.L1 Obj2.L1 Obj3.L1

Componente 3

Componente 2

Obj1.T1

Obj2.T1

Obj3.T1

Obj1.L2

Obj2.L2

Obj3.L2

Obj1.T2

Obj2.T2

Figura 4: Um aplicativo composto por dois ou mais componentes.

Obj3.T2

Obj1.L3

Obj2.L3

Obj3.L3

(b)
Obj1.L1 Obj2.L1 Obj3.L1

Obj1.T1

Obj2.T1

Obj3.T1

Obj1.L2

Obj2.L2

Obj3.L2

Obj1.T2

Obj2.T2

Obj3.T2

Obj1.L3

Obj2.L3

Obj3.L3

(c)

(a)
Obj1.L1 Obj2.L1 Obj3.L1

Estao B

Estao A

Obj1.T1

Obj2.T1

Obj3.T1

Obj1.L2

Obj2.L2

Obj3.L2

Parada em B

Transporte de A -> B

Parada em A

Obj1.T2

Obj2.T2

Obj3.T2

Obj1.L3

Obj2.L3

Obj3.L3

Transporte de B -> C

Transportador

Transporte de D -> A

(d)

Figura 3: Duas chamadas de mtodos concorrentes: (a) o objeto 2 est executando o mtodo requisitado pelo objeto 1, atravs da fuso de transies Obj1 T1 e Obj2 T1 , enquanto o objeto 3 est esperando pela disponibilidade do objeto 2; (b) o objeto 2 responde a chamada de mtodo atravs da fuso de transies Obj2 T2 e Obj1 T2 ; (c) o mtodo do objeto 2 (Obj2 T1 ) est agora disponvel; e (d) o objeto 3 solicita o mtodo fornecido pelo objeto 2 atravs da fuso de transies Obj3 T1 e Obj2 T1 .

Parada em C

Transporte de C -> D

Parada em D

Estao C

Estao D

(b)
Figura 5: (a) movimentao circular do transportador, passando atravs das estaes; (b) sistema de transporte de material modelado em PFS.

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

P1 Transporte de X -> Y

T1
P2

T2 P1

T1

Estao Z P2

Figura 6: Modelo em rede de Petri da atividade [Transporte entre duas estaes (de X a Y)].
Interface Transportador/ Estao P2

P3

T3

T1 P1 Parada na estao Z

T2 P3

(a)
T1 T2 P1

T2

Figura 7: Modelo em rede de Petri da atividade [Parada na estao Z].

Transportador P2

P3

Passo 3 Modelagem dos elementos bsicos em rede de Petri

T3

(b)
Na Fig.6 tem-se a atividade [Transporte entre duas estaes] modelada em rede de Petri onde as estaes so genericamente identicadas por X (partida) e Y (chegada). O lugar P1 a pr-condio desta operao. A transio T1 considera o tempo necessrio para ir de X a Y. O lugar P2 a ps-condio desta operao. A Fig. 7 apresenta a atividade de parada em cada estao (genericamente chamada de estao Z). O lugar P1 assinala a chegada do transportador estao. O inicio da operao representado pela transio T1. O lugar P2 representa o (des) carregamento do produto. T2 indica o m da operao e o lugar P3 representa o estado nal da operao. A atividade [Interface Transportador/Estao] detalhada na Fig. 8. O lugar P1 representa o estado inicial, P2 a operao e P3 o trmino da operao de (des) carregamento. As transies T1 e T2 so, respectivamente, o inicio e o m da operao de (des) carregamento. A Fig. 9 apresenta o modelo em rede de Petri da atividade [Estao Z]. As transies T1 e T2 so os modelos das interface desta atividade. T1 representa o incio da operao de (des) carregamento, enquanto que T2 representa o seu trmino. A transio T3 representa a durao da operao de (des) carregamento. O lugar P1 representa a espera da estao pelo trmino da operao de (des) carregamento. Os lugares P2 e P3 so, respectivamente, o incio e o trmino do processamento dos produtos nas respectivas estaes.
T1 Interface Transportador/ Estao P1 P2 T2 P3

Figura 9: (a) Modelo em rede de Petri da atividade [Estao Z]; (b) Modelo em rede de Petri da atividade [Transportador].
Interface Transportador/ Estao P2

T1 P1 Parada na estao Z

T2 P3

T2 P1

Estao Z P2

T1 t

T2 P3

T3

Figura 10: A relao entre as atividades [Parada na estao Z] e [Estao Z] atravs da fuso de transio.

O modelo em rede de Petri da atividade [Transportador] mostrado na Fig. 9b. O lugar P1 representa o estado de movimentao do [Transportador], enquanto que P2 e P3 so respectivamente os estados inicial e nal das operaes de (des)carregamento. A transio T1 representa a parada do transportador e o incio da operao de (des)carregamento. T3 representa a durao da operao de (des)carregamento, e T2 o m da operao. T1 e T2 so tambm interfaces do modelo da atividade [Transportador]. A relao entre os modelos [Parada na estao Z] e [Estao Z] so modelados atravs da fuso de transies (Fig. 10). As transies T1 de ambos os modelos so unidas, trabalhando como uma s. O mesmo acontece com T2. A Fig. 11 mostra a fuso de transio entre [Transportador] e [Interface Transportador/Estao]. As transies T1, de ambos os modelos, se comportam como uma s. O mesmo ocorre com a transio T2.
7

Figura 8: Modelo em rede de Petri da atividade [Interface Transportador/Estao].

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

P2

T12

T11 P12 P11

T10 P10

T9 P9

T8 P8

T7 P7

P3

T3 Transportador T1 P1 T2

T13 P13 P14

T14 P15

T1 Interface Transportador/ Estao P1 P2

T2 P3

T1

T2 P2 P3

T3 P4

T4 P5

T5 P6

T6

Figura 11: Relao entre as atividades [Transportador] e [Interface Transportador/Estao] atravs da fuso de transies.
Parada na Estao C Transporte de C -> D Parada na Estao D

P1

Figura 13: Modelo funcional do modelo da Fig. 5b em rede de Petri.

(a)
t P2 P1 P3 P1 t

Estao A

T1

(b)
t T1 P1 T2 P3 t

(a)

(c)
Figura 12: Aplicao de tcnicas de reduo do modelo.
Transportador

Analisando a Fig. 5b, 6 e 7, uma simplicao pode ser aplicada na parte do modelo detalhado na Fig. 12a. Neste caso, o lugar P2 do modelo [Parada na Estao C] e P1 do modelo [Transporte de C para D] (Fig. 12b), por exemplo, podem ser unidos, resultando no lugar P1 do modelo da Fig. 12c. A tcnica de simplicao aplicada ao modelo da Fig. 5b, que resulta no modelo [Malha de movimentao] da Fig. 13. Outra simplicao adotada neste exemplo o uso de somente um par de transies (T13 e T14) para interagir com o modelo [Transportador]. Portanto, os conitos por recursos so evidenciados no modelo e a gerao de componentes (Passo 4) simplicada. Passo 4 Denio dos objetos Cada classe denida no passo 3 usada como modelo para gerar um ou mais objetos. A abordagem bottom-up ento adotada. As Figs. 14a, 14b e 14c mostram, respectivamente, o objeto Estao A (B, C e D) baseado na classe estao, objeto Transportador baseado na classe transportador e objeto Malha de movimentao baseado na classe de mesmo nome. Passo 5 Gerao dos componentes
8

(b)

Malha de Movimentao

(c)
Figura 14: (a), (b) e (c) so objetos baseados nas classes denidas no passo 3.

Esses objetos so agora agrupados para comporem o componente da clula de manufatura (Fig. 15). Utilizou-se a notao de interfaces de entrada e sada do diagrama de componentes da UML para ilustrar as interface e os uxos de informaes entre os objetos do componente Clula de Manufatura (Figs. 14 e 15). Passo 6 Gerao do aplicativo Para este exemplo simplicado, o modelo de aplicativo o mesmo do componente obtido no passo anterior.

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Estao B

Estao A

O gerenciamento da simulao distribudo entre as estaes. O label utilizado para sincronizar a evoluo do tempo de simulao em todas as estaes, de acordo com a abordagem conservadora. O label composto por cinco diferentes campos que podem ser modicados por qualquer uma das estaes do anel, a saber: Campo de identicao da estao (varLabelId) este campo indica a ltima estao a alterar os valores dos demais campos do label. Campo de tempo futuro (varLabelTF) este campo contm o tempo de simulao requisitado pela estao indicada no campo de identicao da estao.

Malha de Movimentao

Estao C

Transportador

Estao D

Figura 15: Componente da clula de manufatura.

Campo de status (varLabelStatus) este campo indica o status atual da estao indicada no campo de identicao da estao. A Tabela 1 apresenta seus possveis valores. Campo de instruo (varLabelInstrucao) este campo envia instrues para todas as estaes, como por exemplo iniciar, pausar e parar a simulao. Campo de erro (varLabelErro) este campo usado para gerenciar erros de simulao, como quando uma estao perde a conexo por problemas de comunicao. Os campos do label so todos zerados quando a simulao comea. A estao mestre seleciona o campo de instruo (varLabelInstruction) para iniciar e enviar o label pelo anel.
Tabela 1: Possiveis valores para o campo de status.

Estao B Estao A Estao C

Circulao do label Interao entre objetos

Figura 16: Comunicao entre modelos.

Valor do campo

Signicado (nenhuma estao est usando o label) A estao est vericando o status corrente de outras estaes. A estao est enviando uma ordem para que as demais estaes atualizem seus tempos de simulao com base no campo de tempo futuro. A estao entrou em deadlock.

5 ALGORITMO DE COMUNICAO PARA O GERENCIAMENTO DA SIMULAO DISTRIBUDA


O algoritmo de gerenciamento da comunicao proposto para gerenciar a simulao distribuda baseado no protocolo label2 ring (Ghring, Kauffels, 1994). No entanto, no contexto deste trabalho, as estaes no esto necessariamente conectadas atravs de uma topologia fsica em anel, isto , implementa-se, de fato, um anel lgico. O algoritmo no interfere no protocolo de comunicao usado na rede de comunicao (como por exemplo, o protocolo TCP/IP). Ele executado num nvel superior. Cada estao conhece a identidade da prxima estao e um label enviado atravs das estaes em uma ordem pr-denida (Fig. 16).
2 Utiliza-se aqui termo label ao invs de token para evitar confuso com o elemento token usado em rede de Petri.

status 0 1 2

As 9 regras descritas na Tabela 2 gerenciam a simulao atravs da rede de modelos. O modelo da Fig. 17 usado como exemplo para ilustrar o funcionamento do algoritmo. Apesar das simplicaes do
9

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Modelo A - "mestre"

TA.2

t=3

Estao A Envia label token(-, 0, 0, iniciar, 0) Dispara transio (TA.1)

Estao B

Estao C

Envia label token(-, 0, 0, iniciar, 0) Envia label token(-, 0, 0, iniciar, 0) Dispara transio (TC.1)

TA.1

TA.3

TA.4

Modelo B
t=5 TB.1

TB.2
Envia label token(-, 0, 0, iniciar, 0) Dispara transio (TA.3)

Chama mtodo (TC.2)

Envia label token(B, 5, 1, iniciar, 0) Envia label token(B, 5, 1, iniciar, 0)

Modelo C

Envia label token(A, 3, 1, iniciar, 0) Envia label token(A, 3, 1, iniciar, 0) Envia label token(A, 3, 1, iniciar, 0) Envia label token(A, 3, 2, iniciar, 0)

TC.1

TC.2

Ajusta relgio(3)

Envia label token(A, 3, 2, iniciar, 0) Ajusta relgio(3)

Figura 17: Exemplo do modelo em rede de Petri.

Envia label token(A, 3, 2, iniciar, 0)

label Envia token(-, 3, 0, iniciar, 0)


Dispara transio (TA.4)

Ajusta relgio(3) Envia label token(B, 5, 1, iniciar, 0)

Envia label token(B, 5, 1, iniciar, 0)

caso, ele mostra alguns dos principais pontos do algoritmo como a passagem do label e os mtodos de chamada. No exemplo, o sistema a ser modelado composto por trs objetos (A, B e C), simulado em 3 diferentes estaes. O comportamento dos principais eventos ilustrado no diagrama de seqncia em UML (Booch et al., 1999) da Fig. 18. importante observar que as atividades preliminares para compor o anel no so aqui mostradas, estas devem tambm ser executadas pelo servidor. Alm disso, intervalos de tempo para o envio e o recebimento do label, ou a execuo das sub-rotinas dos disparos das transies so denidas aleatoriamente. Como esses intervalos de tempo dependem da capacidade dos computadores e da disponibilidade dos meios de comunicao, eles podem variar de caso para caso. A simulao inicia quando o servidor envia o label atravs do anel com o campo Instruo = Start. Aps receber o label, cada estao pode disparar suas transies instantneas, que neste caso so o tA.1 e tA.2 (ou tA.3 ) para a estao A, e tC.1 para a estao C. A transio tC.2 a chamada de mtodo do objeto B, mas este mtodo no est ainda disponvel, assim o objeto C deve aguardar. Na prxima etapa, o objeto B requisita que o clock da simulao seja atualizado para 5; no entanto, antes que ele receba o label de volta, o objeto A altera o campo do label com uma requisio de alterao do clock para 3. Quando o label percorre o anel, todas as estaes j dispararam todas as suas transies instantneas possveis, ento a estao A conrma a atualizao para 3 (campo Status = 2). Aps o disparo tA.3 , a estao A alcana o estado de deadlock e envia o label com o campo Status = 3. A estao B, que novamente requisita a atualizao do clock para 5, substitui esta informao. Esta ltima informao no substituda, logo o clock de simulao colocado em 5. A estao B pode ento dispara tB.1 e responder a chamada de mtodo, que resulta no disparo de tB.2 e tC.2 .
10

Envia label token(B, 5, 1, iniciar, 0) Envia label token(B, 5, 2, iniciar, 0) Ajusta relgio(5) Envia label token(B, 5, 2, iniciar, 0) Envia label token(B, 5, 2, iniciar, 0) Ajusta relgio(5) Ajusta relgio(5) Envia label token(-, 5, 0, iniciar, 0) Envia label token(-, 5, 0, iniciar, 0) Dispara transio (TB.1) Mensagem de resposta (TC.2) Dispara transio (TB.2) Envia label token(A, 5, 3, iniciar, 0) Dispara transio (TC.2) Envia label token(A, 5, 3, iniciar, 0) Envia label token(A, 5, 3, iniciar, 0) Envia label token(A, 5, 3, parar, 0) Envia label token(A, 5, 3, parar, 0) Envia label token(A, 5, 3, parar, 0)

Figura 18: Exemplo do diagrama UML de seqncia.

Comparando a abordagem proposta com uma tradicional, o algoritmo conservador apresentado em (Fujimoto, 1999) troca mensagens (nulas ou no) para sincronizar cada clock local. Assim, se o problema de simulao possui N modelos interagindo entre si (caso mais crtico), cada modelo necessita enviar N 1 mensagens para determinar o tempo seguro para avanar o clock de simulao. Isto resulta em N (N 1) mensagens trocadas. Considerando a percentagem de mensagens nulas, a expresso resulta em (N 2 N ) mensagens nulas trocadas para sincronizar o tempo de simulao. No algoritmo proposto, cada modelo monitora a mensagem label. O nmero de mensagens label trocadas denido como . Assim, o simulador troca N mensagens para sincronizar o tempo de simulao. Quando nenhum simulador altera os atributos do label, duas passagens de labels so necessrias (a primeira para consulta, e a segunda para atualizar o tempo de simulao), resultando em 2N mensagens trocadas.

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Tabela 2: Regras para o gerenciamento da simulao


Linha de commando
if (varLabelInstrucao != "stop") { if (varLabelErro == "1") { varLabelInstrucao = "stop"; } else if (varLabelId == ) { if (local object deadlock == 2) { // Nenhuma das estaes est usando o label. // Regra 01 o objeto/modelo local de simulao est em deadlock ele no possui transies instantneas ou temporizadas a serem disparadas. Ele precisa noticar aos demais objetos/modelos sobre o estado de deadlock. // Se um erro for detectado, a simulao deve ser encerrada.

Observaes

varLabelId = local object identification; varLabelStatus = "3"; } else if (local object deadlock == 1) { // Regra 02 o objeto/modelo local de simulao est em deadlock ele no possui transies instantneas a serem disparadas. Ele precisa consultar aos demais objetos/modelos antes de avanar o tempo de simulao do sistema como um todo.

varLabelId = local object identification; varLabelStatus = "1"; varLabelTF = local object clock; } } else if (varLabelId != local object identification) { if (local object deadlock == 0) { // O label foi utilizado por outro objeto/modelo da simulao. // Regra 03 o objeto/modelo local no est em deadlock e um outro modelo est consultando a rede sobre outros objetos/modelos em deadlock. O objeto/modelo local reinicia os campos varLabelId e varLabelStatus e copia o relgio de simulao local para o campo varLabelTF.

varLabelId = ; varLabelStatus = "0"; varLabelTF = local object clock; } else if ((local object deadlock == 1) && (varLabelStatus == "1") && (varLabelTF > local object clock)) { varLabelId = local object identification; varLabelTF = local object clock; } else if ((local object deadlock == 1) && (varLabelStatus == "3")) { // Regra 05 o objeto/modelo local de simulao est em deadlock ele no possui transies instantneas a serem disparadas. e ele recebe o label informando que um objeto/modelo anterior est em deadlock. O objeto/modelo local copia seus valores para os campos varLabelId e varLabelFT e altera o varLabelStatus para "1 para consultar outros objetos/modelos antes de evoluir o seu clock local. // Regra 04 o objeto/modelo local de simulao est em deadlock ele no possui nenhuma transio instantnea ou temporizada a ser disparada. Ele recebe o label, que tem o varLabelTF maior que o clock local. O objeto/modelo local copia sua prpria identicao para o campo varLabelId e seu clock local para o campo varLabelTF.

varLabelId = local object identification; varLabelStatus = "1"; varLabelTF = local object clock; } else if (varLabelStatus == "2") { // Regra 06 o objeto/modelo local recebe o label com a instruo para atualizar o seu clock de simulao local. Ele copia o valor do campo varLabelTF para o clock do objeto local e reseta a varivel deadlock do objeto local para disparar suas transies.

local object clock = varLabelTF; local object deadlock = 0; } } else { // O label foi utilizado por um objeto/modelo local.

continua . . .

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

11

Tabela 2: Continuao da pgina anterior


if (varLabelStatus == "3") { // Regra 07 o objeto/modelo local, no estado de deadlock (sem transies instantneas ou temporizadas), envia o label informando aos demais modelos sobre a sua condio, e recebe o label sem alteraes. O objeto/modelo local escreve no campo erro do label para informar que todo o sistema est no estado de deadlock e toda a simulao deve ser encerrada.

varLabelError = "1"; } else if (varLabelStatus == "1") { // Regra 08 o objeto/modelo local, no estado de deadlock (somente sem transies instantneas), envia o label perguntando aos demais modelos sobre a possibilidade de avanar seus clocks locais e ele recebe o label de volta sem alteraes. O objeto/modelo local altera o campo varLabelStatus para 2, e ele envia o label para os demais modelos que tero os seus clocks locais atualizados.

varLabelStatus = "2"; } else if (varLabelStatus == "2") { // Regra 09 aps os demais modelos terem os seus clocks locais atualizados, o label retorna ao objeto/modelo local. O objeto/modelo local atualiza o seu clock local e libera o label.

varLabelId = ; varLabelStatus = "0"; local object deadlock = 0; } } }

zados de simulao: Os simuladores, atravs do uso de sockets, formam um anel lgico entre si; Cada simulador executa uma consulta de eventos organizados em ordem ascendente; O evento do tempo i+1 o evento do tempo i adicionado de um nmero aleatrio maior que zero; A consulta de eventos no possui dois eventos com o mesmo time stamp isto foi adotado para analisar o algoritmo no caso mais crtico: quando apenas um evento disparado em cada processo sincronizado; O processo de sincronizao registrado no campo de seqncia de aes (Seqncia de Aes na Fig. 19); O simulador deriva o tempo despendido pelo label para completar cada volta, desta vez no considera o tempo do algoritmo, apenas o tempo de circulao; O experimento usou computadores com processador Pentium IV e com no mnimo 512Mb de memria RAM. Segue a descrio de algumas das experincias realizadas e os seus resultados.

Figura 19: Interface do software de simulao.

Assim, se (N 2 -N) N 0, a abordagem tradicional utiliza menos a rede de comunicao trocando mensagens nulas para sincronizar o tempo dos simuladores, isto , N (/) + 1.

6 AVALIAO DO ALGORITMO
O software de simulao foi implementado (Fig. 19) para avaliar o desempenho do algoritmo. Este simulador foi replicado em diferentes computadores, todos eles conectados a uma rede local de comunicao de10Mbps. Existem algumas consideraes sobre os experimentos reali12

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

6.1

Validao do algoritmo

Aqui, dois simuladores so usados, sendo que dez eventos foram programados para cada simulador (Fig. 20). Este exemplo ilustra um dos experimentos realizados para validar o algoritmo de comunicao para gerenciamento da simulao distribuda. O resultado da simulao apresentado na Tabela 3. A passagem do label inicia em 0 no primeiro simulador, pois ele dispara o processo de simulao. A regra 00 indica que nenhum dos simuladores est usando o label (o label est livre).

6.2

Inuncia do nmero de simuladores utilizados

(a) Lista dos Eventos do simulador 1 (Obj1)

Neste caso, 100 eventos foram programados para cada simulador. Este exemplo ilustra um dos experimentos realizados para analisar a inuncia do nmero de simuladores (N ) nos seguintes parmetros: (1) nmero de passagens do label para processar todos os eventos dos simuladores; (2) o tempo de circulao do label; (3) o nmero de passagens do label entre dois eventos consecutivos no simulador; e (4) o tempo real entre dois eventos consecutivos no simulador. A inuncia do nmero de simuladores no (1) nmero de passagens do label, e (2) no tempo de circulao do label apresentado na Tabela 4. O resultado mostra que o nmero de passagens do label aumenta com o nmero de simuladores. tambm observado que o tempo de circulao cou prximo de 70ms e independente do nmero de simuladores. A inuncia do nmero de simuladores no nmero de passagens do label entre dois eventos consecutivos no simulador apresentado na Tabela 5. Nota-se que quanto maior o nmero total de eventos dos simuladores, menor o nmero de passagens do label necessrio para execuo destes eventos (Fig. 21). A inuncia do nmero de simuladores sobre o tempo real decorrido entre dois eventos consecutivos apresentado na Tabela 6.
(b) Lista dos eventos do simulador 2 (Obj2)
Figura 20: Lista dos eventos usados no algoritmo de validao.

Nmero mdio de passagens do token ponderado de eventos processados Nmero mdio de passagens do label pelo total pelo total de eventos processados 2,550 2,500 2,450 2,400 2,350 2,300 2,250 0 100 200 300 400 500 600

6.3

Inuncia da rede de comunicao sobre a simulao

Tem-se aqui um exemplo dos experimentos realizados para analisar a inuncia da rede de comunicao nos seguintes aspectos: (1) tempo de circulao do label; (2) o nmero de passagens do label entre dois eventos consecutivos no simulador; e (3) o tempo real decorrido entre dois eventos consecutivos no simulador.

Figura 21: Inuncia do nmero de simuladores, ponderando-se pelo nmero total de eventos processados (eixo horizontal), em relao ao nmero de passagens do label entre dois eventos consecutivos considerando todos os eventos dos simuladores (eixo vertical).

Para este experimento, foram feitas as seguintes consideraes:


13

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Tabela 3: Resultado da simulao distribuda para dois simuladores (objetos).


Object 1 Passagem do label 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 14 << ><0000><0><1><0>> << ><0000><0><1><0>> <<Obj2><0016><1><1><0>> <<Obj2><0016><2><1><0>> << ><0016><0><1><0>> <<Obj1><0017><1><1><0>> <<Obj1><0017><2><1><0>> <<Obj2><0027><1><1><0>> <<Obj2><0027><2><1><0>> << ><0027><0><1><0>> <<Obj1><0042><1><1><0>> <<Obj1><0042><2><1><0>> <<Obj2><0045><1><1><0>> <<Obj2><0045><2><1><0>> << ><0045><0><1><0>> <<Obj2><0052><1><1><0>> <<Obj2><0052><2><1><0>> << ><0052><0><1><0>> <<Obj1><0078><1><1><0>> <<Obj1><0078><2><1><0>> <<Obj2><0102><1><1><0>> <<Obj1><0090><1><1><0>> <<Obj1><0090><2><1><0>> <<Obj2><0102><1><1><0>> <<Obj2><0102><2><1><0>> << ><0102><0><1><0>> <<Obj2><0106><1><1><0>> <<Obj2><0106><2><1><0>> << ><0106><0><1><0>> <<Obj2><0122><1><1><0>> <<Obj2><0122><2><1><0>> << ><0122><0><1><0>> <<Obj1><0126><1><1><0>> <<Obj1><0126><2><1><0>> <<Obj2><0152><1><1><0>> <<Obj1><0144><1><1><0>> <<Obj1><0144><2><1><0>> <<Obj2><0152><1><1><0>> <<Obj2><0152><2><1><0>> << ><0152><0><1><0>> <<Obj1><0161><1><1><0>> <<Obj1><0161><2><1><0>> <<Obj2><0161><3><1><0>> <<Obj1><0206><1><1><0>> <<Obj1><0206><2><1><0>> <<Obj2><0206><3><1><0>> 00 02 00 06 02 08 09 00 06 02 08 09 00 06 02 00 06 02 08 09 04 08 09 00 06 02 00 06 02 00 06 02 08 09 04 08 09 00 06 02 08 09 05 08 09 05 0009 0008 0007 0006 0005 0004 0003 0002 0001 label recebido Regra Evento Passagem do label 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 Object 2 label recebido << ><0000><0><1><0>> << ><0000><0><1><0>> <<Obj1><0017><1><1><0>> <<Obj2><0016><1><1><0>> <<Obj2><0016><2><1><0>> <<Obj1><0017><1><1><0>> <<Obj1><0017><2><1><0>> << ><0017><0><1><0>> <<Obj2><0027><1><1><0>> <<Obj2><0027><2><1><0>> <<Obj1><0042><1><1><0>> <<Obj1><0042><2><1><0>> << ><0042><0><1><0>> <<Obj2><0045><1><1><0>> <<Obj2><0045><2><1><0>> <<Obj1><0078><1><1><0>> <<Obj2><0052><1><1><0>> <<Obj2><0052><2><1><0>> <<Obj1><0078><1><1><0>> <<Obj1><0078><2><1><0>> << ><0078><0><1><0>> <<Obj1><0090><1><1><0>> <<Obj1><0090><2><1><0>> << ><0090><0><1><0>> <<Obj2><0102><1><1><0>> <<Obj2><0102><2><1><0>> <<Obj1><0126><1><1><0>> <<Obj2><0106><1><1><0>> <<Obj2><0106><2><1><0>> <<Obj1><0126><1><1><0>> <<Obj2><0122><1><1><0>> <<Obj2><0122><2><1><0>> <<Obj1><0126><1><1><0>> <<Obj1><0126><2><1><0>> << ><0126><0><1><0>> <<Obj1><0144><1><1><0>> <<Obj1><0144><2><1><0>> << ><0144><0><1><0>> <<Obj2><0152><1><1><0>> <<Obj2><0152><2><1><0>> <<Obj1><0161><1><1><0>> <<Obj1><0161><2><1><0>> << ><0161><0><1><0>> <<Obj1><0206><1><1><0>> <<Obj1><0206><2><1><0>> << ><0206><0><1><0>> <<Obj1><0234><1><1><0>> Regra 00 00 04 08 09 00 06 02 08 09 00 06 02 08 09 04 08 09 00 06 02 00 06 02 08 09 04 08 09 04 08 09 00 06 02 00 06 02 08 09 00 06 01 00 06 01 00 0010 0009 0008 0007 0006 0005 0004 0003 0002 0001 Evento

continua . . .
Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Tabela 3: Continuao da pgina anterior


Object 1 Passagem do label 47 48 49 50 label recebido <<Obj1><0234><1><1><0>> <<Obj1><0234><2><1><0>> <<Obj2><0234><3><1><0>> <<Obj2><0234><3><1><1>> Regra 08 09 00 00 0010 Evento Passagem do label 48 49 50 Object 2 label recebido <<Obj1><0234><2><1><0>> << ><0234><0><1><0>> <<Obj2><0234><3><1><0>> Regra 06 01 07 Evento

Tabela 4: Inuncia do nmero de simuladores na passagem e no tempo de circulao do label.


Tempo (em segundos) N 2 3 4 5 Passagem do label 0507 0727 0952 1141 Min 0,000 0,000 0,000 0,000 Max 1,035 0,365 0,095 0,090 Mediana 0,070 0,070 0,070 0,070 Moda 0,070 0,070 0,070 0,070 Mdia 0,072 0,085 0,070 0,070 Desvio Padro 0,043 0,022 0,004 0,004

Tabela 5: Inuncia do nmero de simuladores sobre o nmero de passagens do label entre dois eventos consecutivos no simulador.
Nmero da passagem do label entre dois eventos consecutivos no simulador N 2 3 4 5 Passagens do label 0507 0727 0952 1141 Min 0.000 0.000 0.000 0.000 Max 11.000 22.000 23.000 27.000 Mediana 5.000 5.000 8.000 10.000 Moda 5.000 5.000 5.000 5.000 Mdia 4.970 7.140 9.090 10.980 Desvio Padro 2.372 4.584 4.866 6.754

Tabela 6: Inuncia do nmero de simuladores sobre o tempo real decorrido entre dois eventos consecutivos.
Tempo (em segundos) N 2 3 4 5 Passagens do label 0507 0727 0952 1141 Min 0.000 0.000 0.000 0.000 Max 1.175 1.890 1.605 1.890 Mediana 0.350 0.490 0.560 0.698 Moda 0.350 0.420 0.350 0.210 Mdia 0.357 0.599 0.635 0.767 Desvio Padro. 0.186 0.405 0.342 0.473

Uso de dois simuladores; 100 eventos programados para cada simulador; Um dos experimentos usou uma rede de comunicao comercial para conectar o computador da universidade com uma outra distante 470km;

Outro experimento usou a Intranet, onde um hub de 10Mbps e um switch de 100Mbps foram testados como pontes entre os dois simuladores. A inuncia da rede sobre a circulao do label apresentado na Tabela 7. observado que na rede de comunicao
15

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Tabela 7: Inuncia da rede de comunicao sobre o tempo de circulao do label.


Tempo (em segundos) Rede comercial 10Mbps 100Mbps Passagem do label 0514 0507 0520 Min 0.000 0.000 0.000 Max 12.595 1.035 0.110 Mediana 0.160 0.070 0.070 Moda 0.135 0.070 0.070 Mdia 0.300 0.072 0.081 Desvio Padro 0.631 0.043 0.025

Tabela 8: Inuncia dos eventos instantneos sobre o tempo de circulao do label.


Tempo (em segundos) % 10 30 50 70 90 Passagens do label 0414 0314 0211 0107 0022 Min 0.020 0.015 0.025 0.040 0.045 Max 0.405 0.230 0.390 0.120 0.130 Mediana 0.105 0.075 0.100 0.070 0.105 Moda 0.105 0.070 0.105 0.070 0.105 Mdia 0.097 0.086 0.092 0.071 0.090 Desvio Padro 0.034 0.020 0.029 0.009 0.025

Tabela 9: Inuncia dos eventos instantneos sobre o nmero de passagens do label para executar dois eventos consecutivos no simulador.
Tempo (em segundos) % 10 30 50 70 90 Passagens do label 0414 0314 0211 0107 0022 Min 0 0 0 0 0 Max 14 11 11 8 3 Mediana 3 3 0 0 0 Moda 3 0 0 0 0 Mdia 4.110 3.120 2.030 1.035 0.180 Desvio Padro 2.463 2.610 2.601 1.935 0.656

Tabela 10: Inuncia dos eventos instantneos sobre o tempo real entre dois eventos consecutivos executados no simulador.
Tempo (em segundos) % 10 30 50 70 90 Passagens do label 0414 0314 0211 0107 0022 Min 0.000 0.000 0.000 0.000 0.000 Max 1.365 0.945 1.015 0.615 0.330 Mediana 0.350 0.250 0.000 0.000 0.000 Moda 0.000 0.000 0.000 0.000 0.000 Mdia 0.398 0.268 0.186 0.072 0.014 Desvio Padro 0.259 0.227 0.244 0.137 0.057

16

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

dedicada, a circulao do label 3 vezes mais rpida que em uma rede de comunicao comercial (e no dedicada). Alm disso, observado que a rede de comunicao no inuenciou o nmero de passagens de label. A pequena diferena resulta do diferente conjunto de eventos aleatrios em cada execuo. Este experimento mostra que a simulao distribuda tem melhor desempenho numa rede de comunicao dedicada ou numa de baixo trfego.

Alm disso, o procedimento proposto prprio para simulao distribuda, uma vez que os modelos resultantes e suas interaes so explicitamente especicados. Assim, a simulao distribuda pode ser efetivamente realizada. Sobre a proposta do algoritmo de simulao, suas principais caractersticas so a abordagem conservativa e a sincronizao de modelos baseada em label-ring para o gerenciamento do tempo de simulao. importante salientar que a considerao de diferentes intervalos de tempo para a execuo das subrotinas de disparo de transies e para a comunicao entre estaes pode levar a diferentes valores dos campos do label e a seqncias diferentes de eventos. Isto tambm pode eventualmente resultar em diferentes marcaes (estados) para os modelos em rede de Petri. No obstante, importante destacar que qualquer cenrio possvel vlido a partir do ponto de vista do formalismo da rede de Petri (a marcao inicial pode levar a diferentes marcaes atravs de seqncias diferentes de disparo de transies). Este artigo sintetiza e organiza alguns resultados preliminares apresentados em (Junqueira, Miyagi, 2006) (Junqueira et al., 2005) onde alm da avaliao dos revisores, novas contribuies foram consideradas.

6.4

Inuncia de eventos instantneos no desempenho da simulao

Apresenta-se agora um exemplo dos experimentos realizados para se determinar a inuncia de eventos instantneos no desempenho da simulao onde, utilizou-se dois simuladores com 100 eventos programados para cada um. A porcentagem de eventos instantneos no inuencia o tempo de circulao do label como mostrado na Tabela 8. Porm, eventos instantneos inuenciam muito o nmero de passagens do label entre dois eventos consecutivos como mostrado na Tabela 9. O nmero de passagens do label reduz com o aumento do nmero de eventos instantneos. A inuncia da porcentagem de eventos instantneos sobre o tempo real entre dois eventos consecutivos mostrado na Tabela 10. A mdia reduz com o aumento do nmero dos eventos instantneos, pois h mais eventos em execuo ao mesmo tempo na simulao.

AGRADECIMENTOS
Os autores agradecem o apoio parcial do CNPq, CAPES e FAPESP para o desenvolvimento deste trabalho.

7 COMENTRIOS FINAIS
Como observado em alguns artigos (Daum, Sargent, 2002) (Kachitvichyanukul, 2001) (Banks, 2000), a pesquisa na rea de modelagem e simulao necessria, especialmente no desenvolvimento de novas tcnicas de modelagem, assim como o reuso de modelos. O procedimento de modelagem proposto torna possvel o entendimento e o detalhamento do sistema produtivo de modo progressivo, atravs de renamentos sucessivos. A abordagem adotada permite uma melhor caracterizao dos elementos do sistema e do relacionamento entre eles. Um modelo relativamente simples pode representar elementos que possuem caractersticas comuns, garantindo a sua reusabilidade, isto , uma biblioteca de modelos pode ser implementada. Assim, as propriedades e funcionalidades de cada elemento podem ser vericadas e, a partir da composio desses elementos, elementos mais complexos, como sub-sistemas, podem ser criados, e as suas funcionalidades, validadas. Desta forma, o modelo total do sistema pode ser obtido atravs de um procedimento de composies sucessivas.

REFERNCIAS
Banks, J. (2000) Simulation in the future. Proc. of the Winter Simulation Conference, pp. 1568-1576. Beraldi, R. and L. Nigro (1999) Distributed simulation of timed Petri nets: a modular approach using actors and time warp. IEEE Concurrency, 1999, 7, 52-62. Booch, G., J. Rumbaugh, and I. Jacobson (1999) The Unied Modeling Language User Guide. Addison Wesley Longman, Inc. Carullo, L., A. Furfaro, L. Nigro and F. Pupo, (2003) Modelling and simulation of complex systems using TPN Designer. Simulation Modelling Practice and Theory, 11, 503-532. Cassandras, C.G. and S.G. Strickland (1992) Sample Path Properties of Timed Discrete Event Systems in Discrete Event Dynamic Systems. IEEE Press, New York. Cheng, J. and L. Cheng (2006) Dispersed networked manufacturing mode and its application in China. Proc. of
17

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

IEEE Intern. Conf. on Industrial Informatics, pp. 12911294. Chiola, G. and A. Ferscha (1993) A distributed discrete event simulation framework for timed Petri net models, Technical Report Series of the Austrian Center for Parallel Computation, ACPC/TR, pp. 93-21. Daum, T. and R.G. Sargent (1999) Scaling, hierarchical modeling, and reuse in an object-oriented modeling and simulation system. Proc. of the Winter Simulation Conference, pp. 1470-1477. Daum, T.S. and R.G. Sargent (2002) A Web-ready HiMASS: facilitating collaborative, reusable, and distributed modeling and execution of simulation models with XML. Proc. of Winter Simulation Conference, vol. 1, pp. 634640. Davrazos, G. and N.T. Koussoulas (2007) Modeling and stability analysis of state-switched hybrid systems via differential Petri nets. Simulation Modelling Practice and Theory, 15, 879-893. Djemame, K., D.C. Gilles, L.M. Mackenzie, and M. Bettaz (1998) Performance comparison of high-level algebraic nets distributed simulation protocols. J. of Systems Architecture, 44, 457-472. Fujimoto, R. (2003) Parallel discrete event simulation. Communications of the ACM, 33, 30-53. Fujimoto, R.M. (1999) Parallel and distributed simulation. Proc. of the Winter Simulation Conference, pp. 122131. Ghring, H-G. and F-J. Kauffels (1994) Token ring: Principles, Perspectives and Strategies. Addison-Wesley Pub. Co. Gomes, L. and J.P. Barros (2005) Structuring and composability issues in Petri nets modeling. IEEE Transactions on Industrial Informatics, 1, 112-123. Hasegawa, K., P.E. Miyagi, D.J. Santos Filho, K. Takahashi, L. Ma, and M. Sugisawa (1999) On resource arc for Petri net modeling of complex resource sharing system. J. of Intelligent and Robotic Systems, 26, 423-437. Junqueira F. and P.E. Miyagi (2006) A new method for the hierarchical modeling of productive systems. Proc. of BASYS2006 IFIP Intern. Conf. on Information Technology for Balanced Automation System in Manufacture and Services, pp. 479-488. Junqueira, F., E. Villani and P.E. Miyagi (2005) A platform for distributed modeling and simulation of productive
18

systems based on Petri nets and object-oriented paradigm. Proc. of ETFA IEEE Intern. Conf. on Emerging Technologies and factory Automation, Catania, pp. 907914. Kachitvichyanukul, V. (2001) Simulation environment for the new millennium. Proc. of the Winter Simulation Conference, pp. 541-547. Karatza, H.D. and G.K. Theodoropoulos (2006) Distributed systems simulation. Simulation Modelling Practice and Theory, 14, 677-678. Kumar, D. and A. Kohli (1997) Faster simulation of timed Petri nets via distributed simulation. Proc. of the 21st Intern. Computer Software and Applications Conf., pp. 149-152. McLean, C. and F. Riddick (2001) Integrating distributed manufacturing simulations. Proc. of IEEE Intern. Conf. on Systems, Man, and Cybernetics, vol. 2, pp. 12941298. Miyagi, P.E. and L.A.M. Riascos (2006) Modeling and analysis of fault-tolerant systems for machining operations based on Petri nets. Control Engineering Practice, 14, 397-408. Miyagi, P.E., D.J. Santos Filho, and W.M. Arata (2000) Design of deadlock avoidance compensators for anthropocentric production systems. Proc. of BASYS2000 IEEE/IFIP Intern. Conf. on Information Technology for Balanced Automation Systems in Production and Transportation, pp. 287-294. Murata, T. (1989) Petri nets - properties, analysis and applications. Proceedings of the IEEE, 77, 541-580. Nevison, C. (1990) Parallel simulation of manufacturing systems: structural factors. Proc. of 22nd SCS Multiconference on Distributed Simulation, vol. 1, pp. 17-19. Nicol, D.M. and S. Roy (1991) Parallel simulation of timed Petri-nets. Proc. of the Winter Simulation Conference, pp. 574-583. Nketsa, A. and R. Valette (2001) Rapid and modular prototyping-based Petri nets and distributed simulation for manufacturing systems. Applied Mathematics and Computation, 120, 265-278. Perumalla, K.S., R.M. Fujimoto, P.J. Thakare, S. Pande, H. Karimabadi, Y. Omelchenko, and J. Driscoll (2005) Performance prediction of large-scale parallel discrete event models of physical systems. Proc. of Winter Simulation Conference.

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

Sanz, R. and M. Alonso (2001) CORBA for control systems. Annual Reviews in Control, 25, 169-181. Sanz, R., S. Galan, M. Rodriguez, C. Garcia, R. Chincilla, and A. Yela (2003) An experiment in distributed objects for real-time process control. Proc. of ETFA03 IEEE Intern. Conf. on Emerging Technologies and Factory Automation, vol. 2, pp. 664-668. Shi, Y., and M. Gregory (1998) International manufacturing networks to develop global competitive capabilities. Journal of Operations Management, 16, 195-214. Shi, Y., D. Fleet, and M. Gregory (2002) Understanding and conceptualising the global manufacturing virtual network. Proc. of IEMC02 IEEE Intern. Conf. on Engineering Management, vol. 1, pp.119-124. Sibertin-Blanc, C. (1993) A client-server protocol for the composition of Petri nets. Proc. of the 14th Intern. Conf. on Application and Theory of Petri Nets, pp. 377396. Tolba, C., D. Lefebvre, P. Thomas and A. El Moudni (2005) Continuous and timed Petri nets for the macroscopic and microscopic trafc ow modeling. Simulation Modelling Practice and Theory, 13, 407-436. Villani, E., P.E. Miyagi, and R. Valette (2007) Modelling and Analysis of Hybrid Supervisory Systems - A Petri Net Approach, Springer, London. Zhan, H.F. et al. (2003) A web-based collaborative product design platform for dispersed network manufacturing. Journal of Materials Processing Technology, 138, 600 604. Zhang, Y., M.Gregory, and Y. Shi (2006) Foundations of global engineering networks: essential characteristics of effective engineering networks. Proc. IEEE Intern. Conf. on Management of Innovation and Technology, vol. 2, pp.1113-1117.

Revista Controle & Automao/Vol.20 no.1/Janeiro, Fevereiro e Maro 2009

19