Modelo de Composição Facilitada de Resource-HLs no Meta ...jeansimao/SiteAnalytice... · Ministério da Educação Universidade Tecnológica Federal do Paraná Pró-Reitoria de

Ministério da Educação Universidade Tecnológica Federal do Paraná Pró-Reitoria de Pesquisa e Pós Graduação

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁPR

PROGRAMA INSTITUCIONAL DE INICIAÇÃO CIENTÍFICA (PIBIC)

RELATÓRIO DE ATIVIDADES (OUTUBRO/2009 A SETEMBRO/2010)

Modelo de Composição Facilitada de Resource-HLs no Meta-

Modelo de Controle de um Simulador de Sistemas de Manufatura

Holônico.

AAlluunnoo:: RRôômmuulloo MMeeiirraa GGóóeess

Orientador: Prof. Dr. Jean Marcelo Simão

Co-orientador: Prof. Dr. Paulo Cézar Stadzisz

Modalidade: Bolsista FUNDAÇÃO ARAUCÁRIA

CAMPUS CURITIBA, Agosto de 2010



Resumo

As tendências relativas à produção, assim como a crescente demanda de produção,

exigem Sistemas Manufatureiros (SM) ágeis. Logo, a abordagem holônica foi proposta. Nos

SM Holônicos (SMH) as entidades como recursos (resources) e produtos (products)

possuem certa inteligência. Tais entidades, também chamadas de Holons (HLs), possuem

suas ações organizadas por um Controle Holônico (CH). Dessa forma, um meta-modelo do

CH foi proposto inspirando-se em Sistemas Baseados em Regras (SBR) e implementado

sobre uma ferramenta de simulação.

Neste meta-modelo, as relações causais do CH são tratadas por agentes, chamados

de Rules, que recebem dados factuais dos Resource-HLs e decidem sobre ações relativas

as Resource-HLs. Estas decisões baseiam-se em uma solução de inferência. Em suma, a

inferência ocorre por meio de uma cadeia ímpar de notificações, que permite alta reatividade

do controle, desacoplamento dos elementos e mesmo resolução de conflitos.

Posteriormente, o meta-modelo de CH foi interpretado como orientado ao “produto”. Nessa

solução, entidades como Product-HLs utilizam Resource-HLs para obter produções

personalizadas. No meta-modelo, suas interações são organizadas utilizando Rules

aprimoradas. Outrossim, o meta-modelo foi testado em suas evoluções sobre a ferramenta

de projeto e simulação ANALYTICE II, conformando-a como uma ferramenta para SMH,

Não obstante as suas evoluções, esta solução de controle/simulação está ainda em

um estado protótipo. Sendo assim não fornece certas facilidades para realizar experimentos.

Por exemplo, a criação de Resource-HLs tem sido feita tecnicamente por meio de

programação em linguagem C++, baseada em um framework do meta-modelo, inclusive

para o ambiente simulado. Neste âmbito, este trabalho apresenta evoluções sobre esse

conjunto de ferramentas com a implementação de uma interface amigável para facilitar a

instanciação de Resource-HLs no ambiente simulado. Nesse sentido, também foram

realizados testes comparativos no simulador em relação à utilização da interface amigável

para com o processo “manual” precedente.

Palavras Chaves: Sistema de Manufatura Holônicos (SMH), Meta-Modelo de Controle,

Ferramenta Cowizard.



1. Introdução

Em diversos setores é visível a demanda por qualidade, agilidade e

diversidade na produção. Neste âmbito, abordagens ágeis vêm sendo propostas,

como por exemplo, a abordagem holônica. Em Sistemas de Manufatura Holônica

(SMH), os recursos (resources) e os produtos (products) possuem certa inteligência.

Tais entidades são chamadas de holons (HLs) cujas inteligências são relacionadas

às habilidades de autonomia e colaboração [9]. Para organizar apropriadamente a

colaboração dos holons, deve existir o Controle Holônico (CH) no SMH, visando

alcançar agilidade de produção.

Neste contexto, em esforços prévios de pesquisa realizados pelo professor

orientador deste trabalho, propôs-se um meta-modelo de CH [15][16][17]. Tal meta-

modelo de CH foi inspirado em sistemas baseados em regras e implementado sobre

a ferramenta de projeto e simulação de sistemas de manufaturas ANALYTICE II.

Tecnicamente, o meta-modelo constitui-se em um framework desenvolvido em

linguagem C++ [13][16][17]. Neste meta-modelo ou framework de CH, as relações

causais são tratadas por agente Rules que recebem dados dos Resource-HLs e

deliberam sobre ações, como a coordenação dos Resource-HLs, através de um

mecanismo diferenciado de inferência [14][15][16][17][19].

A inferência das Rules ocorre por meio de uma cadeia ímpar de notificações,

que em suma permite alta reatividade, determinismo, desacoplamentos e resolução

de conflitos [8][12][15]. Ainda, esta solução permite a implementação e expressão

coerente do controle, visto que as instâncias podem emergir a partir do

conhecimento de regras especialistas [8]. Além disso, a solução é interpretada como

orientada ao produto, onde os Product-HLs requisitam e utilizam os Resource-HLs

para obter produções personalizadas. No meta-modelo, é utilizado Rules

aprimoradas para a organização de suas interações [12][22]. Outrossim, os

experimentos com o framework sobre o ANALYTICE II demonstram estas

propriedades e concomitantemente o evoluem como um simulador de SMH.

Esta solução de controle e simulação de SMH vem ao encontro das

demandas do mercado e das comunidades relacionadas. Porém, seu estado de

protótipo não fornece algumas facilidades para realização de experimentos. Assim,

um primeiro objetivo dos esforços de pesquisa vem sendo a melhoria destas

ferramentas e a realização de um conjunto de experimentos em SMH. Neste âmbito,



este relatório resume os esforços e contribuições realizados pelo autor para com

este ferramental e pesquisas referentes a ela.

Uma primeira contribuição efetiva foi o desenvolvimento de uma interface

amigável para o desenvolvimento de Resource-HLs sobre ANALYTICE II, chamado

de cowizard. Esta interface é chamada assim por poder ser utilizado com um wizard

de composição de Rules de pesquisas complementares [8][22]. Em suma, o

cowizard proposto permite elaborar automaticamente Resource-HLs baseados nos

equipamentos simulados no ANALYTICE II. Isto facilita o processo de criação destes

Resource-HLs que antes se dava tecnicamente por meio da linguagem de

programação C++, ainda que apoiado no framework do meta-modelo de controle.

Este relatório descreverá sucintamente o método de desenvolvimento do

cowizard e suas respectivas funcionalidades. O relatório descreverá também as

outras atividades desta iniciação científica, em especial as que são diretamente

decorrentes da elaboração do cowizard. Estas atividades são essencialmente a

elaboração e a comparação qualitativa de controles sobre um mesmo sistema

simulado (i.e. uma célula de manufatura simulada), primeiramente sem a utilização

do cowizard para composição dos Resource-HLs da célula e logo após utilizando-o.



2. Revisão Bibliográfica

A crescente demanda de agilidade, qualidade e diversidade na produção são

visíveis em diversos setores. O setor industrial está atualmente diante de certa

mudança de um mercado de vendedores para um de compradores [4]. Neste

âmbito, a competição passou de um nível nacional para um nível global, onde o ciclo

de vida de um produto diminuiu, e ainda há uma crescente exigência para satisfazer

as necessidades específicas e individuais dos consumidores [5]. Assim, o sucesso

dos industriais não será apenas avaliado pela relação custo-eficácia da produção de

um produto, mas também pela flexibilidade, agilidade e versatilidade [4].

Na verdade, essas rápidas mudanças do ambiente industrial forçam as

companhias a aumentar o desempenho dos Sistemas de Manufatura (SM) [5]. Para

fins de sobrevivência empresarial, considera-se que existe a necessidade dos SM

adaptarem-se em ritmo cada vez maior, incorporando novas tecnologias, novos

produtos, novas estruturas organizacionais etc [4]. Em suma, novas soluções são

necessárias.

Estas tendências e necessidades motivam pesquisadores na academia e

indústria a buscar novos paradigmas de produção. Nesse âmbito, surgem os

paradigmas ágeis de SM (classificados na Tabela 1), tais como: biônico, fractal,

genético, e o holônico. Tais paradigmas objetivam eliminar deficiências quando

paradigmas não ágeis são implementados nesse novo contexto [8].

Paradigmas

1. Isolado ou Fragmentado

2. Hierárquico ou Rígido

3. Hierarquia Integrada ou Visível

4. Heterárquivo ou Interoperável

5. Inteligente, Adaptável ou Ágil

Abordagem deArquitetura de Sistemas

Abordagem Ad hocEmpirismo

Controle AutomáticoTeoria de Sistema

Manufatura Integrada por Computador (CIM)Sistêmica e Engenharia de Sistema

Descoplado (Objetos) ou Sistemas Distribuídos (Agentes)Ontologias & Cognitivos

Sistem Multi-Agente (MAS)Fractal, Bionico & Holônico

de ModelagemTeórico

Paradigmas

1. Isolado ou Fragmentado

2. Hierárquico ou Rígido

3. Hierarquia Integrada ou Visível

4. Heterárquivo ou Interoperável

5. Inteligente, Adaptável ou Ágil

Abordagem deArquitetura de Sistemas

Abordagem Ad hocEmpirismo

Controle AutomáticoTeoria de Sistema

Manufatura Integrada por Computador (CIM)Sistêmica e Engenharia de Sistema

Descoplado (Objetos) ou Sistemas Distribuídos (Agentes)Ontologias & Cognitivos

Sistem Multi-Agente (MAS)Fractal, Bionico & Holônico

de ModelagemTeórico

Tabela 1: Classificação de Abordagens.

A manufatura hierárquica apresenta uma boa otimização da produção, mas a

rigidez e a centralização da estrutura de controle implicam em uma fraca resposta

para imprevistos. Por outro lado, a manufatura heterárquica apresenta boa resposta

para mudanças e distúrbios inesperados, mas a otimização da produção global não

é garantida. Isto se deve ao fato das decisões serem baseadas em um

conhecimento parcial do sistema [7].



Por sua vez, uma manufatura ágil deve combinar as melhores características

das estruturas organizacionais hierárquicas e heterárquicas. Neste quadro, segundo

Jin-Hai, Anderson e Harrinson em [5], o conceito de manufatura ágil incorpora a

capacidade de suportar mudanças pela aplicação de core competencies para o

fornecimento de produtos customizados. Isto dito, entre os paradigmas ágeis dá-se

destaque ao holônico advindo da teoria de sistemas adaptativos.

Sistema de Manufatura Holônico (SMH) advém de um paradigma (concebido

pelo filósofo Koestler) que traduziu o conceito de organização de organismos vivos e

sociais para o universo industrial. Para o filósofo, em sistemas complexos as

entidades constituintes são ao mesmo tempo, o todo e a parte [6]. Com isso, para

descrever a unidade básica organizacional Koestler inventou a palavra holon, que

em uma organização social comporta-se “em parte como o todo e totalmente como

partes” [1]. A introdução do paradigma holônico em sistemas de manufaturas trouxe

vantagens como modularidade, descentralização, autonomia e escalabilidade,

voltando-se para a agilidade.

A idéia principal é manter as boas características dos sistemas holônicos,

como organização e agilidade, no contexto industrial. Neste contexto, uma solução

para aumentar a agilidade seria que cada “ordem de produção”, representando um

produto, seja uma entidade inteligente. Essa entidade saberia as capacidades e

estados de cada recurso (e.g. cada equipamento e célula) [18]. Os recursos também

podem ser aperfeiçoados com certa inteligência, para permitir que as ordens de

produção consultem seus estados, bem como requisitar serviços dos mesmos [18].

Essas entidades inteligentes são os holons, que etimologicamente significam

equilíbrio entre a autonomia e cooperação. Na personalização em massa, mais

precisamente, cada produto será representado por um agente de “ordem de

produção” compondo assim um Product-HL. Esses Product-HLs colaborariam com

holons de Resource-HL para produzir com variedade e agilidade [8][12].

Baseados em fatores como a prioridade das ordens, Product-HLs competiriam

entre si para utilizar os serviços dos Resource-HLs. Os serviços seriam negociados

baseados em habilidades disponíveis e necessidades personalizadas, com o

objetivo de adaptabilidade visando agilidade [8]. A Figura 1 ilustra este ambiente

composto por holons.



Figura 1: Entidades ‘Inteligentes’ em uma Planta Flexível[12].

Não obstante a certa potencial agilidade, Product-HLs e Resource-HLs

negociando dessa forma, heterárquica, não é suficiente para alcançar os benefícios

esperados pelo SMH [18]. Isto poderia acarretar em problemas, como estados

imprevisíveis e deadlocks [11]. Assim sendo, um controle deveria existir para regular

a sociedade de holons (i.e. a holarquia). Nesse contexto o Controle Holônico (CH)

surge para regular a holarquia, por meio de regras flexíveis.

Esse CH seria compatível com os interesses industriais e pesquisas na área

de Manufacturing Execution Systems (MES) [18]. Na verdade, o CH é uma evolução

dos atuais Shop Floor Controls (SFCs). Porém, para fins de robustez, o CH deveria

ser composto por holons distribuídos, cada qual regulando uma parte da holarquia

[8]. Neste âmbito, pesquisas têm sido propostas e desenvolvidas sobre arquiteturas

holônicas, enfatizando aspectos de controle para regular a holarquia [8][11][21]. No

entanto, a composição de um controle totalmente voltado para o pensamento

holônico é muito raro, sendo uma exceção o trabalho do professor orientador, que

adicionalmente prevê controle holônico com e sem Product-HLs [8][15][18].

Entretanto, em geral, ainda se faz necessário uma grande quantia de esforços

para confirmar a abordagem holônica, mesmo sendo um paradigma promissor para

satisfazer os requisitos para a próxima geração [3][8]. Exemplos de tais esforços são

amplos conjuntos de testes de soluções de controle em ambientes de simulação

apropriados, para fins de confirmação de soluções, e testes decorrentes e efetivos

sobre sistemas reais.



3. Materiais e Métodos

Esta seção é dedicada à apresentação dos chamados Materiais e Métodos

empregados.

3.1 - Materiais

A necessidade de testes e comparações é uma recorrência das tecnologias

de SM [10]. Entretanto, ressalta-se os riscos e custos associados em

implementações de testes reais em SM [20]. Assim sendo, a simulação é uma

alternativa que evita riscos e possui um custo menor [18]. Porém, sua utilização

implicaria em obter um simulador com certas características necessárias, que

poderiam ser disponibilidade de código, baixo preço e alta qualidade [12].

Neste contexto, um esforço de pesquisa do LSI (Laboratório de Sistemas

Inteligentes) da UTFPR foi o desenvolvimento do ANALYTICE II, uma ferramenta de

concepção e simulação de um sistema de manufaturas [7][12]. ANALYTICE II possui

um conjunto de características desejáveis em um simulador, algumas mostradas na

Tabela 2. Uma característica especial é modularidade e escalabilidade. Essa

característica contribui para a separação entre a emulação física e as entidades de

recurso e de controle (e.g. MES e SFC) por meio de uma rede de comunicação

simulada [12]. Tal separação é uma raridade em simuladores [10].

Tabela 2: Características de ANALYTICE II.

A Figura 2, por sua vez, mostra essa separação por meio de uma rede virtual

(lado esquerdo), assim como mostra um módulo de animação gráfica representando

uma célula de manufatura simulada [18]. Todas essas características fazem o

ANALYTICE II oportuno para desenvolvimento de uma máquina realística de

simulação de SMH [12].



Figura 2: ANALYTICE II – Uma ferramenta de simulação in-house[8].

Em ANALYTICE II, os Resource-HLs são implementados de forma realista,

pois a parte de software é separada da parte físico-mecatrônica por meio de uma

rede virtual, conforme mostrado na Figura 3. Neste quadro, um primeiro esforço

sobre o ANALYTICE II foi sua holonificação propototipal, englobando a criação de

Resource-HLs e uma solução de controle [12].

Na simulação, cada Resource-HL é formado por um recurso (equipamento)

emulado e por um recurso (equipamento) virtual. Os recursos emulados são

executados no âmbito do ANALYTICE II e mandam seus estados discretos através

da rede virtual [12]. Já os recursos virtuais recebem a informação correspondente à

sua parte física, atualizam-se e notificam o CH [12]. Na verdade, cada recurso

emulado e seu respectivo recurso virtual comunicam em ambos os sentidos por meio

da rede virtual compondo assim um dado Resource-HL.

Ainda, segundo a solução de CH, cada Resource-HL indica seus estados

através dos subholons Attribute e suas ações poderiam ser requisitadas por

subholons Method [22]. Esta estruturação de Resource-HLs é mostrada na Figura 3.

Isto dito, é relevante salientar que este trabalho de iniciação científica orbita nestes

elementos, ANALYTICE II e criação de Resource-HLs.



Figura 3: Atributos e Métodos para os Resource-HLs [12].

Uma vez desenvolvido os Resource-HLs (e mesmo Product-HLs) em

ANALYTICE II, passou-se ao desenvolvimento e uso do framework conforme

definido no meta-modelo de CH. Primeiramente, aplicou-se o CH orientado ao

processo, ou seja, sem participação de Product-HLs. Isto é possível, porque a

essência do meta-modelo de controle encontra inspirações no conceito de Sistema

Baseados em Regras (SBR) onde as coordenações dos Resource-HLs se dá por

meio de “regras”.

Figura 4: (a) Resource-HL em ANALYTICE II. (b) Controle sobre Resource-HLs [12]

Segundo o meta-modelo de CH, as relações causais do controle são

expressas em regras e tratadas como entidades chamadas Rules. Tais entidades

também são holons e podem ser vistos na Figura 4.

De certa forma, cada controle instanciado é similar a um Sistema Especialista.

A base de fatos é relacionada aos estados dos atributos (no interior) dos Resource-

HLs) avaliados pelas Rules (como na Figura 5). A decisão e coordenação são

executadas pelas Rules e a conclusão final será a instigação dos métodos dos

Resource-HLs [18].



Figura 5: Holons Rules [8].

Alternativamente, o processo de inferência dessas Rules é realizado via

colaborações baseadas em notificações [8][15]. De uma forma mais simples, os

Resource-HLs notificam para as Rules dados factuais, relacionado ao estado de

seus Atributos (cf. Figura 5). Cada Rule notificada define o momento apropriado para

a execução de certa ação de controle, ativando Métodos dos Resource-HLs [12].

Na verdade, essa inferência acontece em uma cadeia ímpar de notificações,

sendo possível graças à composição dos Resource-HLs e das Rules baseadas em

agentes (cf. Figura 6). Os Attributes dos Resource-HLs permitem a composição de

Premises (Premissas) e então as Conditions (Condições) das Rules, enquanto aos

Methods dos Resource-HLs permitem compor as Instigations (Instigações) e então

as Actions (Ações) das mesmas.

Os Attributes notificam à respeito de mudanças de estado apenas a Premises

interessadas. Da mesma forma as Premises em relação às Conditions e as

Conditions em relação às Rules, conjuntamente realizando o cálculo lógico e causal

por meio de notificações [14]. As Rules aprovadas, por sua vez, instigam a Actions,

as quais instigam as Instigations. Estas, por fim, instigam os Methods dos Resource-

HLs. A Inferência Orientada a Notificações (ION) é esboçada na Figura 7.



Figura 6: Meta-Modelo de Controle [12]

As vantagens que este tipo de inferência (ION) traz para o CH são: alta

reatividade, o desacoplamento dos elementos, compatibilidade/equivalência com

formalismo das redes de Petri, potenciais mecanismos para questões relativas ao

conflito e ao determinismo e, ainda, a coerência entre a implementação e a

expressão do controle [12][14].

Resource-HL.1

Resource-HL.n

Attribute-SubHL1.1

Attribute-SubHL1.n

Attribute-SubHL2.1

Attribute-SubHL2.n

Method-SubHL1.1

Method-SubHL1.n

Method-SubHL2.1

Method-SubHL2.n

Attributes

Methods

Premise-SubHL.1

Premise –SubHL.2

Premise -SubHL.4

Premise -SubHL.n

Premise -SubHL.3

Premises

Instigation–SubHL.2




Instigations

Condition-SubHL.1

Condition-SubHL.n

Action-SubHL.1

Action-SubHL.n

Conditions

Actions

RulesBase of facts…

Rule-HL.1

Rule-HL.n

Resource-HL.1

Resource-HL.n

Attribute-SubHL1.1

Attribute-SubHL1.n

Attribute-SubHL2.1

Attribute-SubHL2.n

Method-SubHL1.1

Method-SubHL1.n

Method-SubHL2.1

Method-SubHL2.n

Attributes

Methods

Premise-SubHL.1

Premise –SubHL.2

Premise -SubHL.4

Premise -SubHL.n

Premise -SubHL.3

Premises





Instigations

Condition-SubHL.1

Condition-SubHL.n

Action-SubHL.1

Action-SubHL.n

Conditions

Actions

RulesBase of facts…

Rule-HL.1

Rule-HL.n

Figura 7: Mecanismo Colaborativo de Notificações [12].



Em suma, esta solução de CH orientada ao processo trata de um conjunto de

questões de controle, ainda sendo uma solução auto-contida e também aberta [12].

Justamente a abertura da solução permite a interpretação como uma solução

orientada ao produto. Tal controle é uma tendência para alcançar a agilidade, via

desacoplamento dos pedidos de produção e suas execuções [8]. As entidades

utilizadas podem ser, por exemplo, os Product-HLs.

Nesta abordagem cada Product-HL é relacionado a uma ordem de produção

específica e personalizada [22]. Os Product-HLs utilizam os Resource-HLs para

alcançar os seus desejos de produção [12][18]. Porém a negociação não é feita

diretamente entre o Product-HLs e Resource-HLs, elas são organizadas e

moderadas por Rules de coordenação, que podem identificar conflitos na utilização

dos recursos e evitar redundâncias temporais e estruturais [22].

A solução tem sido aplicada em exemplos em ANALYTICE II, apresentando

independência da simulação, já que cada sistema de controle não é consciente que

os Resource-HLs e Product-HLs são simulados. No entanto, a solução de controle

foi implementado na forma de um framework em C++ sob o ANALYTICE II. Dessa

forma, primeiramente as instâncias de controle foram implementadas tecnicamente

via código C++ derivando a partir do framework, em seguida foi implementadas via

wizard, desenvolvido por Lucca [8] e evoluído por Witt [22].

3.2 - Métodos

Nesta seção será falado dos métodos empregados para a realização deste trabalho.

Para isso foi subdivida em duas partes. Primeiramente, dar-se-á ênfase ao

desenvolvimento do cowizard e ao seu funcionamento. Posteriormente, considerar-

se-á um controle desenvolvido utilizando Resource-HLs gerados pelo cowizard.

3.2.1 - A Ferramenta Cowizard

Nesse contexto de ANALYTICE II e de seu meta-modelo (framework) de

controle, é atribuído a este trabalho o desenvolvimento de um módulo de suporte

para facilitar a criação de Resource-HLs. Este módulo tem a forma de interface

amigável, denotada aqui como cowizard.

Efetivamente, um cowizard é essencial para atividades de pesquisas em

controle sobre o ANALYTICE II, já que anteriormente a criação de Resource-HLs era



desenvolvida via código, ainda que suportada por uma hierarquia de classes

framework do meta-modelo de CH. Ademais, em alguns caso, certos Resource-HLs

eram feitos apenas com o que se necessitava no momento e para a planta industrial

em questão, não se preocupando necessariamente em reutilização do Resource-HL

criado. Certamente, essa abordagem prévia gerava certa lentidão no processo e

mesmo improdutividade.

O desenvolvimento do cowizard foi realizado dentro do quadro de atividades

deste trabalho. Primeiramente houve um estudo entendendo os modelos/projetos e

códigos do meta-modelo de controle, bem como seu ambiente de teste, ANALYTICE

II. Subseqüentemente, fez-se um estudo da ferramenta wizard. Depois de

compreendido o simulador, o meta-modelo de controle e a ferramenta wizard,

passou-se então a elaboração do cowizard.

Figura 9: Estação de trabalho simulada em ANALYTICE II.

O desenvolvimento do cowizard teve como método o clássico processo em

escada da engenharia de software. Primeiramente, houve o planejamento e



levantamento de requisitos. Depois, houve a modelagem (em UML) de como seria

um cowizard para gerar Resource-HLs. A partir disto, desenvolveu-se o código do

cowizard em C++, que faz apelo a biblioteca gráfica Microsoft.Net, sendo

desacoplado do ANALYTICE II. Finalmente, testou-se e validou-se o cowizard.

Neste sentido, os Resource-HLs foram gerados pelo cowizard, bem como

testados e validados, por meio de uma célula de manufatura em particular, simulada

em ANALYTICE II. A Figura 8 mostra esta célula de manufatura por meio de uma

representação gráfica (dos seus equipamentos) existente no próprio ANALYTICE II.

Salienta-se que para cada equipamento mostrado foi gerado um Resource-HL por

meio do cowizard , cada qual possuindo seu “agente” ou recurso virtual.

A composição dos Resource-HLs pelo cowizard é feita em etapas. Ao todo

são sete etapas. A Figura 9 mostra a janela inicial do software. Primeiramente o

usuário faz a escolha do nome do Resource-HLs e o local a ser salvo. Logo após, o

usuário escolherá qual Classe Base irá derivar o Resource-HL, Figura 10. Na

verdade, esta Classe Base provém da implementação prévia do framework CON

(Controle Orientado a Notificações), desenvolvido por Banaszewski em [2], do CH

que serve de suporte para o cowizard.

Figura 9: Janela inicial do software Cowizard.



Em seguida, haverá a escolha do equipamento a partir do qual será feito o

Resource-HL. Com a escolha do equipamento, o software analisa os atributos do

mesmo para gerar Attributes (Atributos) e Methods (Métodos) no Resource-HL. O

usuário ainda poderá escolher quais Attributes e Methods serão gerados, como

mostra a Figura 11, bem como seus nomes.

Figura 10: Classe Base a ser escolhida.

Ao final de todas as etapas serão gerados dois arquivos, um arquivo “.h” e

outro “.cpp”. Tais arquivos serão utilizados no simulador ANALYTICE II,

desempenhando a função de recurso virtual do Resource-HLs.

Figura 11: Atributos a serem escolhidos.



Os Resource-HLs gerados pelo cowizard não são Resource-HLs completos

ainda, isso é devido ao fato de alguns Attributes e, também, alguns Methods dos

Resouce-HLs estarem relacionados à célula/planta industrial, e.g. movimentação do

Robô Puma até posição de um Armazém. Dessa forma a célula/planta industrial

deixa a criação de Resource-HLs limitada a sua disposição espacial.

Assim o cowizard gera “apenas” Attributes e Methods possíveis somente a

partir do equipamento relacionado ao Resource-HL a ser gerado. Então os

Resource-HLs gerados via cowizard são apenas uma estrutura genérica e prototipal.

Para tornarem-se efetivamente funcionais, ainda há a necessidade do usuário

implementar via código C++ funções relacionadas a disposição espacial da

célula/planta industrial a ser simulada em ANALYTICE II.

3.2.2 - Desenvolvimento de um CH usando Resource-HLs gerados via Cowizard

Depois do termino da interface, o próximo passo foi gerar Resource-HLs para

uma célula/planta industrial e implementar um controle em cima dessa. Para tal, foi

considerado o SMH apresentado na Figura 8.

Primeiramente, foram gerados os Resource-HLs via cowizard, ao todo foram

oito: Armazém de nove posições, Mesa de duas posições, Robô Puma 560, Maquina

de Ferramentas, AGV (Automated Guided Vehicle) com manipulador, Robô ER III e

Torno Mecânico. Porém, como já dito, os Resource-HLs gerados pelo cowizard

apenas são protótipos baseados nos equipamentos dos mesmos, gerando funções

de base e não se preocupando na questão espacial e disposição da planta industrial.

Em seguida, após os Resource-HLs serem gerados, pode-se trabalhar neles

para implementação das funções relacionadas à disposição dos mesmos na planta

industrial. Ao final dessas implementações foi possível dar funcionalidade aos

Resource-HLs. Com os Resource-HLs prontos pode-se instanciar um controle e

validá-los. Com auxilio do wizard foi instanciado o controle (CH) orientado ao

processo, o mesmo já desenvolvido anteriormente.

Na verdade, em um experimento anterior, havia sido implementado os

mesmos Resource-HLs e respectivo CH orientado ao processo, mas sem a ajuda do

cowizard. Isto dito, salienta-se que os resultados sobre a diferença de complexidade

de composição das duas instâncias de controle serão considerados na próxima

seção.



4. Resultados

Esta seção é dedicada à apresentação dos resultados obtidos.

4.1 - Quanto à Ferramenta Cowizard Criada

Como era esperado, o cowizard se demonstrou funcional e permite a

construção de Resource-HLs baseados em seus equipamentos. Pode-se construir

Resource-HLs que outrora eram construídos tecnicamente por meio da linguagem

de programação C++, ainda que baseados em uma hierarquia de classes do

framework do Meta-Modelo de CH..

Nesse sentido, para fins de validação, foram gerados Resource-HLs via

cowizard para uma célula/planta industrial e depois instanciou-se regras de controle

que foram comparadas com as da célula/planta industrial onde os Resource-HLs

foram criados sem o cowizard. Para instanciar o controle foi utilizada a ferramenta

wizard detalhada em [8][22].

O controle de SM com os Resource-HLs criados com o cowizard e sem este

se comportaram exatamente da mesma forma. Isto representa legitimidade do

cowizard, validando-o

4.2 - Quanto à diferença de complexidade de composição das duas instancias

de controle

A diferença de complexidade de composição das duas instâncias de controle,

sendo a primeira sem facilidade na composição de Resource-HLs e a segunda com

facilidade, será feita de forma qualitativa. Para isso, utilizou-se a planta industrial

demonstrada na Figura 8.

A composição dos Resource-HLs sem facilidade, sem a utilização do

cowizard, foi longa e demorada, isso devido a implementação dos Resource-HLs via

código C++. Não obstante, depois de criados os Resource-HLs, instanciou-se um

controle na planta industrial. Em particular, uma dificuldade encontrada foi a falta de

padrão na criação dos Resource-HLs. Tal falta de padrão dificultou instanciar certas

Rules, tornando-as confusas e a falta de entendimento do usuário.



O controle utilizando os Resource-HLs criados via código mostrou-se viável e

satisfatório, porém houve uma longa demora e certa improdutividade na criação dos

Resource-HLs. Na verdade, devido à este tipo de situação que foi criado o cowizard.

Com a utilização do cowizard foram gerados os Resource-HLs de maneira

rápida e de forma padronizada. Após isso, bem verdade que se teve de implementar

alguns Attributes e Methods via código C++ (pelo motivo explicado anteriormente).

Porém, o tempo de tal implementação desse código nos Resource-HLs é muito curta

comparada com a implementação de todo o Resource-HL via código C++

desenvolvida anteriormente.

Ademais, ao criar os Resource-HLs com o cowizard pode-se padronizar a sua

criação. De fato, com a padronização dos Resource-HLs, ficou mais fácil instanciar

as regras do controle. Na Figura 12 pode-se observar algumas regras de controle

instanciadas.

Finalmente, constatou-se que com a utilização do cowizard facilita na

composição do Resource-HLs e até da Rules do CH quando comparado com a

composição via código C++. Em suma, houve uma diminuição do tempo de

composição dos Resource-HLs.

Figura 12: Algumas regras holônicas usadas.



4.3 - Quanto ao Cumprimento do Plano de Atividades Propostos

Inicialmente, o plano de atividade deste trabalho de iniciação científica

compunha-se das seguintes das seguintes atividades:

Atividade 1 - Estudo de ANALYTICE II, Meta-modelo de Controle Orientado a

Notificações (CON) e Wizard de CON. Neste estudo seria dada atenção especial a

natureza e composição de Resource-HL e as suas potenciais generalizações.

Atividade 2 - Evolução do wizard para facilitar a composição de Resource-HLs (e

generalizações) segundo as imposições deste meta-modelo.

Atividade 3 - Desenvolvimento de (pelo menos) um controle usando a nova versão

do wizard. Este controle será normalmente o equivalente a uma instância

desenvolvida previamente.

Atividade 4 - Comparação qualitativa sobre a diferença de complexidade de

composição das duas instâncias de controle, sendo a primeira sem facilidade na

composição de Resource-HLs e a segunda com facilidades.

Atividade 5 - Redação de relatórios e artigos.

Foram completadas todas as atividades no tempo pré-estipulado no plano de

atividades desse projeto. A finalização deste trabalho foi composta pelo

desenvolvimento deste relatório e de um artigo acadêmico submetido ao SICITE

2010.



5. Considerações

As atividades realizadas refletem-se no desenvolvimento do cowizard de

Resource-HLs, o que se constitui em uma contribuição para o LSI/UTFPR. De fato, o

cowizard resulta em uma significativa evolução na facilidade de composição de

Resource-HLs, baseado no meta-modelo (framework) de controle, sobre

ANALYTICE II.

Nesse sentido, a partir da interface foram desenvolvidos os Resource-HLs de

uma planta industrial, para instanciar um controle holônico. Com isso, pode-se ter

um objeto de comparação com o controle holônico instanciado com Resource-HLs

gerados sem a interface, tendo ficado evidente a preponderância da utilização da

interface para desenvolver Resource-HLs.

Assim sendo, a iniciação científica resultou no aprendizado de uma linha de

pesquisa em sistema de manufatura holônico e controle discreto por meio de

tecnologias ímpares de simulação e controle, bem como no desenvolvimento

tecnológico pela composição do cowizard.

Por fim, dentre os trabalhos futuros, prevê-se a evolução da interface para

comportar aquelas funcionalidades pendentes. Bem como, prevê-se a publicação

deste trabalho em congresso nacional.



7. Referências Bibliográficas

[1] Babiceanu R. F., Chen F.: Development and applications of holonic

manufacturing system: a survey. Journal of Intelligent Manufacturing, Vol. 17(pp

111,131), 2006.

[2] Banaszewski, R. F.; Stadzisz, P. C.; Tacla, C. A.; Simão, J. M.: Notification

Oriented Paradigm (NOP): A Software Development Approach based on Artificial

Intelligence Concepts. International Congress on Logic Applied to Technology, 2007.

[3] Deen, S.M.: Agent-Based Manufacturing: Advances in the Holonic Approach,

2003. Springer. ISBN 3-540-44069-0.

[4] Giret A., Botti V.: Engineering Holonic Manufacturing Systems. Computers in

Industry, Vol. 60 (pp 428, 440), 2009.

[5] Jin-Hai L., Anderson A., Harrison R.: The evolution of agile manufacturing.

Business Process Management Journal, Vol. 9 (pp 170,189), 2003.

[6] Koestler A.: The Ghost in the Machine, Arkana Books, London, 1969.

[7] Leitão P. Restivo F.: ADACOR: A holonic architecture for agile and adaptive

manufacturing control. Computers in Industry, Vol 57 (pp 121, 130), 2006.

[8] Lucca, J.: Modulo de Interface Amigável sobre Meta-modelo de Controle

conectado em Ferramenta de Simulação de Sistemas de Manufatura. Relatório de

Iniciação Científica. PIBIC/UTFPR, 2008.

[9] Lucca, J.; Banaszewski, R. F.; Stadzisz, P. C.; Tacla, C. A; Simão, J. M: Interface

sobre Meta-modelo de Controle do Simulador ANALYTICE II e suas Utilizações para

Comparações de Políticas de Controle de Manufatura. Resumo Est. no Seminário de

Iniciação Cient. e Tecn. (SICITE) - UTFPR, 2008.

[10] Marík, V.: Industrial Application of the Agent-based Technology. Copyright IFAC

2004.

[11] McFarlane D., Sarma S., Chrin J.L., Ashton K.: Auto ID systems and intelligent

manufacturing control, Intell. Manuf.: Special issue of Engineering Applications of

Artificial Intelligence, vol. 16 (4) (pp 365–376), 2003.

[12] Simão, J. M.: A Contribution to the Development of a HMS simulation tool and

Proposition of a Meta-Model for Holonic Control. Ph. D. Thesis, CPGEI/UTFPR and

CRAN - UHP, June 2005.



[13] Simão, J.M.; Proposta de uma Arquitetura de Controle para Sistemas Flexíveis

de Manufatura Baseada em Regras e Agentes. Dissertação de

Mestrado,CPGEI/UTFPR, 2001.

[14] Simão, J. M., Stadzisz, P.C.: Inference Based on Notifications: A Holonic

Metamodel Applied to Control Issues. IEEE Transactions on Systems, Man and

Cybernetics. Part A, Systems and Humans, v. 39, p. 238-250, 2009.

[15] Simão J. M., Stadzisz P. C.: Paradigma Orientado a Notificações (PON) – Uma

Técnica de Composição e Execução de Software Orientada a Notificações. Request

of patent submitted to INPI/Brazil (Instituto Nacional de Propriedade Industrial) in

2008 and Innovation Agency of UTFPR in 2007. Temporary INPI Number:

015080004262. Actual INPI Number: PI0805518-1

[16] Simão J. M., Stadzisz P. C.: Mecanismo de Resolução de Conflito e Garantia de

Determinismo para o Paradigma Orientado a Notificações (PON).Request of patent

submitted to INPI/Brazil (Instituto Nacional de Propriedade Industrial) in 02/2010 and

Innovation Agency of UTFPR in 2009.Temporary INPI Number: 015100000477

Actual INPI Number to be defined.

[17] Simão J. M., Tacla C. A., Banaszewski R. F., Stadzisz P. C.: Mecanismo de

Inferência Otimizado do Paradigma Orientado a Notificações (PON) e Mecanismos

de Resolução de Conflitos para Ambientes Monoprocessados e Multiprocessados

Aplicados ao PON. Request of patent submitted to INPI/Brazil (Instituto Nacional de

Propriedade Industrial) in 03/2010 and Innovation Agency of UTFPR in 2010.

Temporary INPI Number: 015100000797. Actual INPI Number to be defined.

[18] Simão, J. M., Stadzisz P. C., Morel G.: Manufacturing execution systems for

customized production. Journal of Materials Processing Technology, Vol. 179 (pp

168-275), 2006.

[19] Simão, J. M.; Stadzisz, P. C.; Künzle, L.A.: Rule and Agent-Oriented Architecture

to Discrete Control Applied as Petri Net Players. Frontiers in Artificial Intelligence and

Applications ("Advances in Logic, Artificial Intelligence and Robotics" LAPTEC 2003).

Vol. 101 (pp. 121-129) IOS Press, Amsterdam - The Netherlands. ISSN: 0922-6389.

[20] Tacla, C.A.; Achraf, O.; Tazza, M.: Software Tool for Manufacturing Systems

Simulation and Performance Evaluation. Proceedings of IEEE International

Conference on System, Man and Cybernetics, v.2 (pp.1285-1290). USA, 1997.



[21] Van Brussel, H.; Wyns, J.; Valckenaers, P.; Bongaerts, L.; Peeters P.: Reference

Architecture for Holonic Manufacturing Systems PROSA. Computers in Industry, Vol.

37 (pp. 255-274), 1998.

[22] Witt, F. A., Avanço do Módulo de Interface Amigável (Wizard) sobre Meta-

modelo de Controle Orientado ao Processo para Orientação ao Produto de um

Simulador de Sistemas de Manufatura Holônico. Relatório de Iniciação Científica.

PIBIC/UTFPR, 2010.

Documents

Modelo de Composição Facilitada de Resource-HLs no Meta ...jeansimao/SiteAnalytice... · Ministério da Educação Universidade Tecnológica Federal do Paraná Pró-Reitoria de