Viabilidade de Emergência de Agentes-Regra a partir do ...Final]_F_Marx_Benghi_2011.pdf ·...

PROGRAMA INSTITUCIONAL DE INICIAÇÃO CIENTÍFICA

RELATÓRIO FINAL DE ATIVIDADES

(MARÇO/2011 A JULHO/2011)

Viabilidade de Emergência de Agentes-Regra a partir do Plano de Processo de Agentes-Produto, no âmbito do Meta-Modelo de Controle

Holônico e de seu Wizard.

Aluno: Felipe Marx Benghi

Orientador: Prof. Dr. Jean Marcelo Simão

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

Alunos colaboradores: Rômulo Meira Góes

Fernando Augusto de Witt

Modalidade: FUNDAÇÃO ARAUCÁRIA

CAMPUS CURITIBA - CENTRAL, JULHO 2011

(DAELN – LSIP/CPGEI - UTFPR)

Ministério da EducaçãoUniversidade Tecnológica Federal do ParanáPró-Reitoria de Pesquisa e Pós Graduação UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

PR

Resumo

A abordagem holônica foi proposta como uma solução ao contexto de produção,

onde são exigidos Sistemas de Manufatura (SM) flexíveis e ágeis. Neste âmbito, os

chamados Sistemas de Manufatura Holônicos (SMH) são compostos por entidades,

como recursos (resources) e produtos (products), dotadas de certa inteligência. Tais

entidades são chamadas Holons (HLs) e suas ações são organizadas por um Controle

Holônico (CH). Assim, foi proposto um meta-modelo do CH inspirado nos Sistemas

Baseados em Regras (SBR) e implantado sobre uma ímpar ferramenta de simulação.

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

Rules, que recebem dados factuais dos Resource-HLs e deliberam sobre ações deles.

Estas inferências ocorrem por uma cadeia de notificações, que permite alta reatividade,

desacoplamento e resolução de conflitos. Depois, foi proposta uma solução orientada

ao produto onde entidades Product-HLs usam Resource-HLs para alcançar produções

personalizadas. Neste contexto, as interações ocorrem por meio de Rules aprimoradas

e a execução destas depende do interesse explícito de Product-HL na sua utilização.

Nesta diversificada solução de CH, a criação de Rules se dava inicialmente em

linguagem C++, baseada no framework do meta-modelo. Posteriormente, foi

desenvolvida uma interface amigável (i.e. um wizard), para a elaboração destes

agentes. A princípio, esta ferramenta era habilitada somente para a composição de

controles orientados ao processo. Posteriormente, este wizard foi aperfeiçoado,

tornando-se possível a criação de controles orientados também ao produto.

Apesar dos avanços no wizard, a criação dos agentes Rules ainda apresentava

relativa dificuldade e morosidade. Neste sentido, este trabalho apresenta melhorias na

solução por meio de um wizard evoluído, com a possibilidade de emergência (i.e.

criação) de Rules automaticamente a partir dos planos de processo dos Product-HLs.

Para fins de validação e comparação qualitativa, foram analisados os resultados obtidos

por Rules criados manualmente e criados por meio da nova técnica de emergência. Os

resultados desmonstram a equivalência das instâncias, validando o novo wizard.

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

Orientado ao Produto, Ferramenta Wizard, Emergência automática.


PR

1. Introdução

Os sistemas ágeis de manufatura, como os Sistemas de Manufatura Holônico

(SMH), vêm sendo propostos como uma resposta à crescente demanda por qualidade,

agilidade e diversificação da produção. Neste âmbito, os SMH possuem entidades

dotadas de certa inteligência, como recursos (resources) e produtos (products). Essas

entidades são também chamadas de Holons (HLs) e sua capacidade de inteligência

está relacionada à autonomia e capacidade de colaboração que apresentam. O SMH

possui também um Controle Holônico cuja função é organizar os holons de modo a

viabilizar a agilidade na produção.

Neste contexto, em esforços prévios realizados pelo orientador deste trabalho, foi

proposto um meta-modelo de CH 6666. Este meta-modelo de CH inspirou-se em

Sistemas Baseados em Regras (SBRs) apresentando HLs de controle chamados de

Rules. O meta-modelo de CH baseado em Rules foi desenvolvido inicialmente na forma

de um framework em linguagem C++. Esse framework foi implementado sobre o

ANALYTICE II, uma ferramenta de projeto e simulação de sistemas de manufatura. Tal

simulador caracteriza-se por possuir uma nítida separação entre as entidades de

controle e recursos emulados na planta 6.

Ao bem da verdade, o framework foi implementado sobre o ANALYTICE II

primeiramente considerando a abordagem orientada ao processo do meta-modelo de

CH. Nesta abordagem orientada ao processo, a inferência das Rules acontece por meio

de uma cadeia de notificações que permite resolução de conflitos, determinismo,

desacoplamento e alta reatividade de Rules (i.e. entidades de controle) e Resource-HLs

(i.e. entidades controladas) 6. De fato, as Rules recebem dados dos Resource-HLs e

também inferem sobre ações referentes à coordenação dos Resource-HLs.

Ademais, a solução de CH pode ser orientada ao produto. Nesta abordagem,

Product-HLs requisitam e utilizam os Resource-HLs para alcançar produções

personalizadas. As interações ocorrem por Rules aprimoradas, em que a execução

destas depende do interesse explícito do Product-HL na sua utilização 66. Isto se dá,

devido a uma tendência para alcançar agilidade e atender as necessidades da

comunidade na produção de produtos personalizados 6.


PR

Subseqüentemente, o framework original em C++ do meta-modelo de CH foi

adaptado para suportar a versão orientada a produto do meta-modelo e testes foram

realizados 6. Nesse contexto, foi desenvolvida uma interface amigável (comumente

chamada wizard ou ‘mágico’) com o intuito de facilitar e tornar mais prática a

composição de controles a partir do Meta-modelo de CH. Entretanto, inicialmente tais

soluções compreendiam somente controles orientados ao processo 666.

Outrossim, no decorrer do tempo, o próprio Meta-modelo de CH, foi re-

denominado de Controle Orientado a Notificações (CON). Na verdade, o CON foi

mesmo generalizado gerando um novo elemento chamado Paradigma Orientado a

Notificações (PON) 6666. Neste âmbito, o PON foi re-implementado em um novo

framework, o qual foi estendido para o CON, mas desconsiderando a orientação ao

produto 6. Devido a esta defasagem, posteriormente,o framework PON/CON foi

modificado e foi também re-elaborado um respectivo wizard CON de forma que ambos

abrangessem a orientação ao produto 66. Assim, tornou-se possível a criação de Rules

adequadas à orientação ao processo e ao produto no wizard de CON.

Contudo, mesmo com a evolução da interface wizard, notou-se que a

composição de Rules ainda apresentava relativa morosidade e dificuldade. Neste

âmbito, os esforços de pesquisa contidos neste relatório são referentes à evolução da

interface wizard, de modo a permitir a possibilidade de emergência (i.e. criação) de

Rules automaticamente a partir dos Planos de Processo dos Product-HLs. Por fim, as

Rules elaboradas por meio desta nova técnica de emergência automática foram

comparadas com Rules criadas manualmente e comprovou-se a equivalência de ambas

validando, deste modo, a nova técnica.

2. Revisão Bibliográfica

Em diversos setores é perceptível o aumento da competitividade entre as

empresas e o maior comprometimento destas na busca por qualidade, agilidade e

diversidade. Ademais, observa-se que a concorrência passou a agir em um nível global.

Assim, para garantir a competitividade, muitas corporações precisam produzir grandes

quantidades de produtos em curtos períodos de tempo, mantendo a qualidade e a


PR

variedade 6. Ademais, uma tendência atual é a personalização em massa, em que a

produção será comandada pelos clientes e não pelos industriais 6.

Para tanto, as corporações são obrigadas a melhorar os Sistemas de Manufatura

(SM) de modo a obterem melhor integração entre informática e automática e garantirem

maior agilidade na produção personalizada 6. Neste contexto, os SM ágeis, como

biônico, fractal, genético e holônico, foram propostos com o objetivo de diminuir as

deficiências verificadas na aplicação dos SM não ágeis. Dentre estes últimos, podem

ser citados os paradigmas hierárquico e o heterárquico.

A Tabela 1 apresenta uma classificação para paradigmas de SM compatível com

a métrica EICM (Enterprise Integration Capability Model). Nesta tabela, são

apresentados tanto SM ágeis como não ágeis.

Tabela 1: Classificação de Abordagens 6.

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 de

Arquitetura 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 de

Arquitetura 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

A abordagem hierárquica absorve a inflexibilidade dos baixos níveis do SM,

gerando rigidez e inabilidade no manejo de situações não previstas. Outrossim, na

abordagem heterárquica a descentralização na tomada de decisões impede a

otimização global e a predição do comportamento de ordens de produção 6.

De forma a melhor atender as necessidades atuais, um SM ágil deve equilibrar

as características dos sistemas hierárquicos e heterárquicos. Para isso, busca-se

manter as vantagens de cada um, como a predição de comportamentos presente no

primeiro paradigma e estratégias flexíveis presente no último 6. Dentre os paradigmas

ágeis, destaca-se o holônico, o qual é baseado na teoria de criação e evolução de

sistemas adaptativos complexos 66.


PR

Nos Sistemas de Manufatura Holônico (SMH), as entidades constituintes

possuem relativa capacidade de integração, negociação e cooperação, podendo ser

consideradas como dotadas de certo grau de ‘inteligência’ [4][12]. Esta ‘inteligência’

torna os recursos (e.g. equipamentos, recursos e produtos) mais adaptáveis na

utilização das flexibilidades de SM [4][22].

Neste contexto de SMH, a utilização de holons cooperativos viabilizaria a

personalização em massa. Para tanto, holons de ‘ordem de produção’, representados

por um (Product-HL), concorreriam pela colaboração dos holons de recurso (Resource-

HL) de modo a suprir as necessidades personalizadas de cada produto, de acordo com

as capacidades do SM e visando à agilidade [7][14]. Para viabilizar este SMH, uma

possibilidade é a aplicação da tecnologia Radio Frequency Identification (RFID) capaz

de conectar efetivamente Product-HLs ao seu correspondente produto físico [11].

Em suma, os Product-HLs concorreriam pela utilização dos serviços dos

Resource-HLs. Esta concorrência se daria baseada, por exemplo, na prioridade da

ordem, nas necessidades personalizadas e nos recursos disponíveis. Na Figura 1[14]

este sistema composto por holons é ilustrado.

Figura 1: Entidades ‘Inteligentes’ em uma Planta Flexível 6.

Não obstante, somente as características apresentadas não seriam condizentes

com a abordagem holônica, pois esta busca o equilíbrio entre hierarquia e heterarquia.


PR

Por esta razão, além de Resource-HLs e Product-HLs negociando heterarquicamente,

faz-se necessária a existência de um Controle Holônico (CH) para regular sociedade

dos holons por meio de regras flexíveis 66. Tal controle mediaria a cooperação entre

Resource-HLs e a negociação de Product-HLs com estes.

Apesar de a abordagem holônica apresentar-se como uma paradigma promissor

para satisfazer os requisitos das próximas gerações [4][12], ainda são necessários

testes para confirmar sua adequação. A abordagem proposta por Simão, destaca-se

por prever uma modelagem controlada com ou sem Product-HLs e por ser testada na

ferramenta de simulação ímpar 6 descrita na seção 3.1.1.

3. Materiais e Métodos

Esta seção apresenta os chamados Materiais e Métodos empregados nos

esforços de pequisa descritos neste relatório.

3.1 Materiais

Esta subseção apresenta os Materiais, mais precisamente a Ferramenta de

Simulação ANALYTICE II e o Meta-Modelo de Controle Holônico (CH) ou Meta-Modelo

de Controle Orientado a Notificações (CON), com a versão do wizard orientada ao

produto e ao processo.

3.1.1 A Ferramenta de Simulação ANALYTICE II

A necessidade de realização de testes e comparações é recorrente às novas

tecnologias de SM, porém isto implica em riscos e custos no caso do uso de

equipamentos ou mesmo uma planta real 6. Por este motivo, uma alternativa

frequentemente utilizada é a simulação. Deste modo, evitam-se riscos e reduzem-se os

gastos 6. Neste âmbito, para a escolha de um simulador adequado são analisadas

características como qualidade, preço e disponibilidade do código fonte 6.

Isto dito, um esforço de pesquisa do então Laboratório de Sistemas Inteligentes

de Produção (LSIP) da UTFPR 66 resultou no desenvolvimento do ANALYTICE II. O

ANALYTICE II constitui-se em uma ferramenta de apoio à decisão/experimentação que


PR

integra um simulador em um ambiente de análise e projeto de SM. Outrossim,

atualmente o LSIP chama-se Laboratório Sistemas Inteligentes (LSI).

Tabela 2: Características de ANALYTICE II 6.

Na Tabela 2 são apresentadas algumas características singulares do

ANALYTICE II proveniente do LSI/UTFPR. Dentre estas, destacam-se a modularidade

e escalabilidade, as quais contribuem para a separação entre as entidades ‘físicas’

simuladas e as entidades de controle [14]. Tal separação realiza-se por meio de uma

rede virtual, ilustrada na Figura 2, em que as entidades de controle comunicam-se com

os recursos emulados e recuperam destes seus estados. Oportunamente, seria

pertinente salientar que é notória a raridade deste tipo de emancipação em simuladores

de SM 6.

Figura 2: Comunicação entre recursos emulados e controle, via rede virtual em ANALYTICE II[7].

Outrossim, no simulador ANALYTICE II as entidades de controle, como

Resource-HLs e mesmo Product-HLs, são implementadas mais realisticamente, uma

vez que parte do software é separada da (emulada) parte físico-mecatrônica por meio

de uma rede virtual, conforme mostrado na Figura 3[14].


PR

Figura 3: (a) Resource-HL em ANALYTICE II. (b) Controle sobre Resource-HLs 6.

Com base nas caracteríticas do ANALYTICE II demonstradas, este foi o

simulador escolhido para a realização de testes pertinentes ao meta-modelo de controle

proposto outrora, o qual será descrito nas próximas seções.

3.1.2 O Meta-modelo de Controle Orientado ao Processo

Os esforços necessários para permitir a holonificação do ANALYTICE II

inicialmente buscaram a integração de cada parte física emulada de cada recurso

(equipamento) com uma respectiva entidade de software, formando uma entidade

virtual espelhada no recurso ‘real’ (i.e. emulado) 6.

Deste modo, cada Resource-HL seria composto pelo recurso emulado e seu

respectivo recurso virtual 6. Com isso, cada Resource-HL indicaria seus estados

através dos subholons Attributes (atributos) e teriam suas ações requisitadas por

intermédio dos subholons Methods (métodos). Na figura 4 demonstra-se esta estrutura.

Ademais, os Resource-HLs são classificados como Transporte Padrão (e.g.

Robô AGV e Puma 560) ou Processador-Armazém Padrão (e.g. Mesa1 e Máquina de

Ferramentas). Esta classificação é decorrente implementação do framework CON,

desenvolvida por Banaszewski em 6, seguindo o definido por Simão 6.


PR

Figura 4: Atributos e Métodos para os Resource-HLs 6.

Subsequentemente, implementou-se o meta-modelo proposto por Jean M. Simão

para o Controle Holônico (CH). Tal solução de CH possui certa inspiração nos Sistemas

Baseados em Regras (SBR) com entidades de controle chamadas Rules. Outrossim, o

meta-modelo foi inicialmente aplicado com uma abordagem orientada ao processo, na

qual não ocorre a participação de Product-HLs 6.

Mais precisamente, na abordagem de CH orientado ao processo, as relações

causais são tratadas por entidades ou holons chamados de Rules. Estas entidades são

notificadas pelos Attributes (pertinentes) sobre os estados dos Resource-HLs. Caso as

condições necessárias para a aprovação de uma dada Rule sejam satisfeitas, a mesma

Rule delibera ações relativas aos Resource-HLs, o que ocorre por meio da ativação de

Methods 6. A Figura 5 apresenta o exemplo de uma Rule.

Figura 5: Representação de uma Rule [8].


PR

Na verdade, as deliberações ou inferências das Rules ocorrem por uma cadeia

de notificações, a qual só é possível através da composição Rules e Resource-HLs na

forma de ‘agentes’. De fato, isto ocorre por um mecanismo baseado em subagentes de

Rules e Resource-HLs, conforme demonstrado nas figuras 6 e 7 [14]. Em suma, os

Attributes notificam mudanças de estado às Premises (Premissas) e estas notificam as

Conditions (Condições). Por sua vez, quando uma Rule é aprovada, as Actions (Ações)

instigam as Instigations (Instigações) e, estas, os Methods (Métodos).

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 6: Mecanismo Colaborativo de Notificações 6.

Figura 7: Estrutura das Rules e seus colaboradores 6.


PR

Algumas das vantagens resultantes deste tipo de inferência para o CH são: alta

reatividade, desacoplamento dos elementos, resolução de conflitos, determinismo e a

compatibilidade/equivalência com o formalismo das redes de Petri 66. Este meta-

modelo de CH, também denominado atualmente de Controle Orientado a Notificações

(CON), foi inicialmente implementado na forma de um framework em C++ para o

ANALYTICE II 66. Posteriormente, para facilitar a criação de Rules orientadas ao

processo, desenvolveu-se uma ferramenta no formato de um wizard 6666. Esta

ferramenta é apresentada no decorrer deste relatório.

3.1.3 O Meta-modelo de Controle Orientado ao Produto

O controle orientado ao produto é considerado uma tendência na busca por

agilidade por meio do desacoplamento dos pedidos de produção e suas execuções.

Neste contexto, as intervenções de Resources-HLs ocorrem mediante solicitação

explicita de Product-HLs. Nesta abordagem, no âmbito no meta-modelo de CH citado,

as negociações entre Resources-HLs e Product-HLs são organizadas diretamente por

Rules aprimoradas, capazes de identificar conflitos na utilização de recursos e evitar

redundâncias. Ademais, tais Rules também impedem comportamentos impróprios no

sistema e suas execuções dependem do interesse explícito de Product-HL na sua

utilização. De certa forma, cada Product-HL utiliza as Rules agindo como um tipo de

especialista 666.

De modo a atender as demandas da sociedade por personalização, cada produto

apresenta um plano de processo em que são definidas as etapas de produção. Neste

contexto de meta-modelo orientado ao produto, um plano de processo representa um

conjunto de Rules capazes de levar o Product-HL a alcançar seus objetivos 666. Para

alcançar o cumprimento de seu plano de processo, cada Product-HL busca a alocação

de uma Rule adequada (de acordo com as etapas do plano) que permita que a ação

necessária seja executada. Para solucionar possíveis conflitos na utilização de um dado

Resource-HL, pode ser utilizado como critério de escolha a prioridade de execução do

Product-HL, de modo a respeitar a ordem de solicitação. Na Figura 9, observa-se na

forma de um diagrama de classes a interação entre Rules e Product-HLs 666.


PR

Figura 8: Classes Rule e Product-HL 6.

Salienta-se que um plano de processo pode possuir mais de uma Rule

adequada para o cumprimento de uma etapa. Desta forma, este Product-HL escolheria

a Rule mais conveniente, baseando-se em seu próprio conhecimento ou, até mesmo,

em dados de outros Product-HLs 6. Ademais, o controle orientado ao produto possui

outras vantagens como a possibilidade de se determinar alguns parâmetros essenciais

para a execução de métodos genéricos do Product-HL. Isto proporciona regras mais

concisas, pois parte do conhecimento das Rules está nos Product-HLs 666.


PR

Por fim, este meta-modelo foi primeiramente implementado por Simão, sobre o

ANALYTICE II, na forma de um framework em linguagem C++, permitindo inclusive a

instanciação de controles orientados ao produto e a realização de testes sobre esta

abordagem 6. Subsequentemente, re-implementou-se o framework em uma nova

versão e elaborou-se uma ferramenta denominada wizard que inicialmente era

habilitada somente para criação de Rules orientadas ao processo [7]. Posteriormente

esta ferramenta foi adequada para a elaboração de Rules também orientadas ao

produto 66. Na próxima seção, este wizard é apresentado de forma detalhada.

3.1.4 A Ferramenta wizard

Neste contexto de meta-modelo/framework de Controle Holônico e do simulador

ANALYTICE II, foi verificada a dificuldade para a instanciação de Rules via código.

Assim, inicialmente Jardel Lucca 666 e, posteriormente, Fernando A. Witt 66 buscaram

desenvolver uma ferramenta capaz de criar controles de forma mais fácil e prática. Esta

ferramenta permite a instanciação de Rules no formato se então através de um

conjunto de interfaces gráficas e é comumente denominada de wizard ou ‘mágico’.

Inicialmente, a interface wizard compreendia controles orientados somente ao

processo [7][8][9]. Assim, para a composição de Rules eram listados Attributes e

Methods referentes aos Resource-HLs. Dessa forma, o usuário poderia compor

Premises e Conditions utilizando Attributes adequados. Outrossim, a instanciação de

Instigations e Actions ocorreria por meio da seleção dos Methods. Ademais, os dados

referentes a cada célula ou sistema de manufatura eram integrados ao wizard, sendo

importados do simulador ANALYTICE II.

Posteriormente aos esforços de Lucca, Witt 66 modificou a citada interface e o

respectivo meta-modelo/framework do CON de forma a abrangerem também a

orientação ao produto. Neste novo wizard era possível a criação, também no formato se

então, de Rules orientadas ao processo e ao produto. Neste último caso, também havia

a possibilidade de se compor planos de processo de Product-HLs por meio da adição

de Rules do tipo produto. Na Figura 9 é exibida a janela do novo wizard destinada à


PR

composição dos planos de processo de Product-HLs de um dado tipo. Neste exemplo,

é parameterizado um plano de processo para o tipo de produto chamado A.

A utilização deste novo wizard estava condicionada a importação de um arquivo

XML com uma base de fatos, chamada de FBEs (Fact Base Entities). Estas FBEs eram

formadas pelos Resource-HLs disponíveis na célula de manufatura. Por sua vez, cada

Resource-HL era composto por um recurso (emulado) e respectivo ‘agente’, o qual era

criado por meio do referido framework ou por meio do cowizard descrito em [5].

Tal base de fatos poderia ser exportada diretamente a partir do ANALYTICE II,

conforme descrito em 66. Entretanto, devido ao fato do novo wizard ser independente

do simulador, a interface poderia utilizar FBEs que fossem provenientes de outras

fontes, como outros simuladores, desde que as bases de dados fossem elaboradas em

um formato igual ao utilizado pelo novo wizard.

Dentre outras inovações, o novo wizard também passou a permitir a definição

algumas opções para cada Product-HL, como a prioridade (que determina a

organização na alocação de Rules entre Product-HLs concorrentes) e a possibilidade

de inclusão de parâmetros.

Figura 9: Janela para a parametrização dos Tipos de Produto.


PR

Por fim, para a utilização no ANALYTICE II, tanto as Rules quanto os planos de

processos criados no novo wizard, precisavam ser exportados. Neste processo eram

criados arquivos XML que continham as informações necessárias ao simulador. Deste

modo, para a execução do CH orientado ao processo devia-se importar um arquivo de

Rules. Em se tratando de um controle orientado ao produto, importavam-se dois

arquivos: um arquivo contendo as Rules e outro os planos de processo de Product-HLs.

Em ambos os casos, era necessária a compatibilidade com os FBEs em questão.

3.2 Métodos

Esta subseção é dedicada à apresentação dos chamados Métodos. Mais

precisamente, ela apresenta a elaboração da interface amigável (wizard) evoluída de

modo a permitir a possibilidade de emergência (i.e. criação) de Agentes-Regra ou

Rules automaticamente a partir dos Planos de Processo dos Agentes-Produto ou

Product-HLs.

3.2.1 A Elaboração da Ferramenta Wizard Evoluído

Devido à complexidade e a consequente improdutividade na instanciação de

Rules a partir do framework via código C++, Jardel Lucca (inicialmente) [7][8][9] e

Fernando A. de Witt (posteriormente) 66 concentraram esforços no desenvolvimento de

uma interface amigável capaz de criar controles de forma mais fácil e prática. Esta

ferramenta foi chamada de wizard ou ‘mágico’.

Apesar dos avanços obtidos, observou-se que a composição das Premises e

Instigations continuava dependendo da adição de comandos provenientes da FBEs e

que são específicos de cada Resource-HL. Com isso, era necessário um considerável

conhecimento do funcionamento da célula de manufatura por parte do usuário para a

elaboração das Rules. Ademais, a constituição dos planos de processo de Product-HLs

dependia da composição prévia e manual de um conjunto de Rules, as quais deveriam

levar os Product-HLs a alcançar seus objetivos de produção 6.

Neste contexto, este relatório busca apresentar as modificações que tornaram

possível, na forma de um wizard evoluído, o desenvolvimento de uma técnica para

emergência (i.e. criação) de Rules automaticamente a partir dos planos de processo


PR

dos Product-HLs. Assim, buscou-se tornar a utilização da ferramenta wizard mais fácil,

por exigir menos conhecimentos, e ágil, por não ser mais necessária criação manual

das Rules.

Com o objetivo de desenvolver um conjunto de algoritmos capazes de permitir a

emergência automática das Rules, inicialmente buscou-se estabelecer uma solução

que mantivesse a flexibilidade da ferramenta wizard e que fosse compatível até mesmo

com FBEs provenientes fontes que não o ANALYTICE II.

Com o objetivo de aprimorar esta solução inicial, optou-se pelo desenvolvimento

de uma solução assaz genérica mas que foi válida em uma célula de manufatura

específica1 composta pelos seguintes equipamentos2: Armazém, Puma 560, Mesa1,

Mesa2, Mesa3, KUKA 364, Máquina de Ferramentas, Robô AGV, ER III, Torno

Mecânico1,Torno Mecânico2. Esta célula de manufatura padrão pode ser observada na

Figura 10(b).

Neste contexto, ao clicar no botão ‘Banco de Dados’ do Wizard evoluído, o qual

pode ser observado na Figura 11, o usuário habilita um conjunto de informações

referentes a estes Resource-HLs, propiciando a elaboração de Rules. Ainda, neste

cenário, foram estabelecidos passos para o processamento dos produtos A, B e C.

Tipicamente, todos os Produto-HLs são inicialmente alocados no Armazém. Em

seguida, as peças do tipo A são levadas até a Mesa 1 na posição um, depois, são

levadas para a Máquina de Ferramentas e, por fim, conduzidas à Mesa 2 na posição

um, local onde são retiradas da célula de manufatura. As peças do produto B executam

um roteiro muito semelhante ao produto A, entretanto, ao invés de seguirem para a

posição um da Mesa 2, são transportadas para a posição zero desta mesma Mesa.

Para o produto C, foram criados dois planos de processo, que diferenciam-se

pelo Torno que utilizam: o primeiro faz uso do Torno 1, enquanto que o segundo, o

Torno 2. Assim, em ambos os casos, a partir do Armazém, as peças são transportadas

para a Mesa 1 na posição zero e, posteriormante, são conduzidas para a Mesa 3 na

1 No decorrer deste relatório, é utilizado o termo célula de manufatura padrão para se referir a esta célula de manufatura específica.

2 As Mesas apresentam todas duas posições para alocação de produtos (Pos0 e Pos1), enquanto que o Armazém apresenta nove. O Puma 560 movimenta peças entre o Armazém e a Mesa1, o KUKA 364 transporta itens entre as Mesa1, Mesa2 e Máquina de Ferramentas, o ER III transfere peças entre os equipamentos Torno1, Torno2 e Mesa3 e o AGV transporta produtos entre as Mesas1 e Mesa3. A Máquina de Ferramenta e os Tornos 1 e 2 processam e modificam as peças respectivamente.


PR

posição zero. Subsequentemente, cada peça é guiada para o seu respectivo Torno e,

depois, levada de volta para a Mesa 3 na posição 1, local onde são retiradas da célula

de manufatura. Na figura 10(a), é possível observar os passos para o processamento

desses três produtos.

Figura 10: (a) Passos para a Produção dos Produtos A, B e C. (b) Equipamentos Existentes na Célula de Manufatura Padrão.

Para viabilizar a utilização da técnica emergência automática, foi estabelecida a

aba Emergência – Produtos, conforme apresentado na Figura 12. Esta apresenta

alguns recursos semelhantes aos desenvolvidos para o novo wizard. Dentre eles,

podem ser citados: a possibilidade de composição de planos de processo para três

tipos de produtos (A, B e C), a definição da prioridade e o estabelecimento de

parâmetros para cada Product-HL. Contudo, salienta-se que a ferramenta é expansível

de modo a possibilitar a composição de um número ilimitado de Product-HLs, tornando

a solução mais adequada ao contexto de produção personalizada.

Ademais, este wizard evoluído apresenta uma estrutura muito semelhante à

versão anterior. Assim, também é possível a utilização da interface conforme

desenvolvida por Fernando A. Witt 66, sem as alterações concebidas na pesquisa

contida neste relatório. Ainda, observa-se que não é permitida a utilização em conjunto

de ambas as soluções, de modo a evitar conflitos de edição do mesmo plano de

processo.


PR

Figura 11: Aba Emergência - Produtos do wizard evoluído.

Outrossim, o desenvolvimento da técnica de emergência automática também

exigiu modificações no ANALYTICE II. Acrescentou-se à base de dados exportada do

simulador dados referentes à classificação dos equipamentos, conforme implementado

por Banaszewski 6, seguindo o definido por Simão 6. Deste modo, o arquivo XML

passou conter informações sobre a classificação dos Resource-HLs (i.e. se um

equipamento era do tipo Transporte Padrão ou Processador-Armazém Padrão).

Ainda referente às mudanças no arquivo contendo a FBEs, oriundo normalmente

do ANALYTICE II, decidiu-se por organizar os equipamentos através de uma rede de

grafos, a qual passou a ser exportado juntamente com os demais dados existentes na

FBEs. Nesta rede, cada equipamento corresponderia a um nó e teria uma conexão com


PR

outro nó quando ocorresse um relacionamento entre eles. Observa-se que esta

conectividade ocorre sempre entre um equipamento do tipo Transporte Padrão e outro

do tipo Processador-Armazém Padrão e visa essencialmente ao transporte dos

Product-HLs de uma posição para outra. Na Figura 12, pode ser observada esta rede

de grafos desenvolvida com os equipamentos bem como a classificação atribuída a

cada equipamento.

Figura 12: Rede de Grafos Elaborada com os Resource-HLs.

A técnica de emergência automática desenvolvida baseia-se principalmente nas

modificações realizadas na FBEs importadas do ANALYTICE II e em dados extras a

respeito dos Resource-HLs habilitados pelo usuário uma vez pressionado o botão

‘Banco de Dados’.

Assim, para a criação de um novo plano de processo é necessária a seleção da

posição em que o produto será alocado quando iniciada a simulação no ANALYTICE II.

Para tanto, busca-se na FBEs um equipamento do tipo Fonte e Sumidouro (i.e. um

equipamento que possua métodos capazes de alocar peças na célula de manufatura).


PR

ArmazémClassificação: Armazém-Padrão

Puma 560Classificação: Transporte-Padrão

Mesa 1Classificação: Armazém-Padrão

Robô AGVClassificação: Transporte-Padrão

KUKA 364Classificação: Transporte-Padrão

Mesa 2Classificação: Armazém-Padrão

Máquina de FerramentasClassificação: Armazém-Padrão

Mesa3Classificação: Armazém-Padrão

ER IIIClassificação: Transporte-Padrão

Torno 2Classificação: Armazém-Padrão

Torno 1Classificação: Armazém-Padrão

Na célula de manufatura padrão, particularmente, o único local em que é

permitida a criação de produtos é o Armazém. Isto dito, para a alocação das peças

neste equipamento, deve-se clicar no botão ‘Pos. Inicial’. Dessa forma, escolhe-se as

posições deste Resource-HL em que cada peça será criada. Com isso, são elaboradas

automaticamente duas Rules: a primeira dispara um informa ao sistema quando o

Armazém encontra-se vazio e a segunda Rule, gera a reposição das peças. Na Figura

13, observa-se a janela em que são escolhidas as posições de alocação de cada

produto.

Figura 13: Janela destinada a alocação dos produtos no Armazém.

A partir da seleção da posição inicial do Product-HLs, podem ser adicionados

outros equipamentos aos planos de processo. Para isso, deve-se escolher uma das

alternativas exibidas no campo ‘Opções’ da aba Emergência – Automática. Desta

forma, determinam-se especificidades de cada Resource-HL (e.g. para qual das

posições de uma Mesa um produto deve ser movido, o processamento dos Product-

HLs em um Torno etc).

Com base nestas escolhas, o algoritmo utiliza-se da rede de grafos para

encontrar um equipamento do tipo Transporte Padrão que se relacione com os

Resource-HLs de origem e destino da peça. Caso exista mais de um equipamento


PR

capaz de realizar a movimentação, o usuário é informado dessa possibilidade e pode

escolher o equipamento que julga mais adequado para efetuar o transporte.

A Rule criada automaticamente com o objetivo de movimentar as peças entre os

equipamentos é composta por um conjunto de Premises e Instigations pré-elaborados

relativos a cada Resource-HL. Este modelo foi proposto com o objetivo de criar

Condictions e Actions adequadas, dispensando-se qualquer interferência do usuário na

sua constituição.

Na Figura 14, por exemplo, pode-se observar o formato desta estrutura. Neste

exemplo, através da rede de grafos, o algoritmo percebeu que o ER III é o Resource-HL

adequado à movimentação dos Product-HLs entre a Mesa 3 e os Torno 1 ou Torno 2. A

partir desta informação busca-se dentre Premises e Methods pré-elaborados para o ER

III, os adequados às escolhas do usuário (destino) e à posição em que a peça se

encontra (origem).

Figura 14: Premises e Methods pré-elaborados para a composição Rules de transporte entre os Resource-HLs Mesa 3, Torno 1 e Torno 2 .

ER IIIORIGEM: DESTINO:MESA 3 Premises: Estado = OCUPADO MESA 3 Premises: Estado = LIVRE

... ...

Methods: NotificarRemoçãoPeça Methods: NotificarCriaçãoPeça

... ...TORNO 1 Premises: Peça em Posição = Falso TORNO 1 Premises: Peça Processada = FALSO

... ...Methods: NotificarRemoçãoPeça Methods: NotificarRemoçãoPeça

... ...TORNO 2 Premises: Peça em Posição = Verdadeiro TORNO 2 Premises: Peça Processada = FALSO

... ...Methods: NotificarRemoçãoPeça Methods: NotificarCriaçãoPeça

... ...


PR

A célula de manufatura padrão possui três maquinários: Máquina de Ferramenta

e Tornos 1 e 2. Quanto um destes Resource-HLs é incluído no plano de processo são

criadas Rules para levar os produtos até estas máquinas e, além disso, são

instanciados meios que promovam a interação dos Product-HLs com estes

equipamentos. Isto se dá porque cada um destes Resource-HLs é o destino potencial

de Product-HLs a partir de um Resouce-HL do tipo Processador-Armazém Padrão

conectável via um Resource-HL Transporte Padrão.

Isto dito, no caso da Máquina de Ferramenta é criada a Rule Processa Peça e no

caso dos Tornos 1 e 2 instancia-se a Rule Modifica Peça. Na Figura 13 pode-se

observar a Rule Processa Peça referente ao equipamento Máquina de Ferramenta e a

Rule Modifica Peça referente ao equipamento Torno 2.

RULES

MÁQUINA DE FERRAMENTAPROCESSA PEÇA

TORNO 2PROCESSA PEÇA

SE

MÁQUINA DE FERRAMENTA ESTADO = LIVRE PORTA FECHADA = FALSO EM POSIÇÃO = VERDADEIROKUKA 364 ESTADO = LIVRE

SETORNO 2 ESTADO = LIVRE PEÇA PROCESSADA = FALSO EM POSIÇÃO = VERDADEIROER III ESTADO = LIVRE

ENTÃOMÁQUINA DE FERRAMENTA: FECHAR A PORTA NOTIFICAR FECHAR PORTA EXECUTAR

ENTÃOTORNO 2 EXECUTAR COMANDO COMPOSTO PEÇA PROCESSADA = VERDADEIRO

Figura 15: Rules criadas para realizar a interação dos Product-HLs com equipamentos

Máquina de Ferramentas e Torno 2.

Uma vez concluída a formulação dos planos de processo e das Rules, ambos

podem ser exportadas diretamente nesta aba, Emergência - Produtos. Assim, são

criados dois arquivos XML que posteriormente podem ser importados pelo simulador.

Por fim, tem-se que com a evolução da ferramenta wizard foi possível a

emergência automática de Rules a partir dos planos de processo dos Product-HLs.

Com o objetivo de gerar Rules que não necessitem da interferência do usuário para sua

elaboração, decidiu-se pelo desenvolvimente de uma técnica voltada a FBEs que fosse

composta pelos Resource-HLs apresentados na Figura 10(b). Com isso, obtiveram-se

resultados satisfatórios, justificando as decisões tomadas.


PR

3.2.2 Comparação entre Agentes-Regras criados automaticamente e Agentes-Regra elaborados manualmente

Após a finalização da ferramenta, foram instanciados dois conjuntos de Rules. O

primeiro conjunto foi formado por Rules elaboradas manualmente e foi baseada em

uma instância de controle desenvolvida por Witt 66. No segundo conjunto, utilizou-se o

wizard evoluído sem qualquer intervenção por parte do usuário.

Neste cenário, foram criados planos de processo para os produtos A, B e C, que

deveriam seguir as etapas de produção conforme apresentado na Figura 10(a). Desta

forma, espera-se verificar a equivalência entre os dois conjuntos de instâncias de

Rules. Os detalhes e conclusões desta comparação serão descritos na seção 4.2.


PR

4. Resultados

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

desenvolvimento do wizard evoluído. Outrossim, Rules elaboradas manualmente e por

meio da técnica de emergência automática são comparadas com o objetivo de validar o

novo método.

4.1 - Quanto à Ferramenta wizard evoluído

A ferramenta wizard evoluído, mais precisamente, a janela Emergência –

Produtos, mostrou-se funcional visto que foi capaz de instanciar automaticamente

Rules a partir dos planos de processo. Deste modo, desempenhou sua função de

facilitar a elaboração de Rules que antes eram feitas manualmente e exigiam esforço

por parte do usuário.

Com o intuito de validar as evoluções na ferramenta em questão, controles

orientados ao produto foram criadas de forma manual e por meio do processo de

emergência automática. Como foram obtidos resultados equivalentes, foi validada a

técnica de emergência do wizard evoluído.

4.2 - Quanto ao Comparativo entre Controles Elaborados Manualmente e por Meio da Nova Técnica de Emergência Automática.

De modo a validar a técnica de emergência automática de Rules, foram

elaborados dois conjuntos de planos de processo. O primeiro conjunto era composto

por Rules criadas manualmente, enquanto que, no segundo, as Rules eram elaboradas

através da nova técnica. Os passos para a produção de cada Product-HL foram

apresentado na figura 10(a).

Na figura 16 pode-se comparar Rules criadas manualmente e pelo processo de

emergência automática. Neste caso, nota-se diferença somente na sequência das

Premises. Entretanto, esta desconformidade não causa prejuízos, pois todas Premises

devem ser satisfeitas para aprovação de uma Rule, não importando a ordem com que

são apresentadas. Ao observar as Actions, percebe-se a equivalência de ambas,

corroborando a validação da técnica de emergência automática.


PR

REGRA 1: TRANSPORTE (ARM. PosX, MESA 1 Pos1)

EMERGÊNCIA AUTOMÁTICA PROCESSO MANUAL

SE SE

MESA 1 ROBÔ PUMA

POS 1 = FALSO ESTADO LIVRE = VERDADEIRO

ROBÔ PUMA MESA 1

ESTADO LIVRE = VERDADEIRO POS 1 = FALSO

ARMAZÉM ARMAZÉM

ESTÁ CHEIO = VERDADEIRO ESTÁ CHEIO = VERDADEIRO

ENTÃO ENTÃO

ROBÔ PUMA ROBÔ PUMA

ABRIR GARRA ABRIR GARRA

MOVER ARMAZÉM POS X MOVER ARMAZÉM POS X

COMANDO COMPOSTO COMANDO COMPOSTO

FECHAR GARRA FECHAR GARRA

MOVER PEÇA MESA 1 POS 1 MOVER PEÇA MESA 1 POS 1

ABRIR GARRA ABRIR GARRA

MESA 1 MESA 1

NOTIFICAR CRIAÇÃO PEÇA POS 1 NOTIFICAR CRIAÇÃO PEÇA POS 1

ROBÔ PUMA 1 ROBÔ PUMA 1

MOVER POS INICIAL MOVER POS INICIAL

ARMAZÉM ARMAZÉM

REMOVER PEÇA POS X REMOVER PEÇA POS X

Figura 17: Comparação entre as Rules TRANSPORTE (ARM. PosX, MESA 1 Pos1) criadas manualmente e criadas automaticamente.

Da mesma forma, as Rules criadas por meio de emergência automática para os

maquinários presentes na célula de manufatura provaram-se equivalentes aos

comandos compostos manualmente. Isso porque, os controles desenvolvidos

manualmente também diferem-se somente pela ordem com que as Premises são

apresentadas. De fato, isso pode ser observado comparando-se as Figuras 15 e 18.

COMANDOS INSTANCIADOS MANUALMENTE

REGRA 5: PROCESSA PEÇA REGRA 15: MODIFICA PEÇA

SE SE

MÁQUINA DE FERRAMENTA ER IIIESTADO = LIVRE ESTADO = LIVREPORTA FECHADA = FALSO TORNO 2EM POSIÇÃO = VERDADEIRO ESTADO = LIVRE

KUKA 364 PEÇA EM POSIÇÃO = VERDADEIRO


PR

ESTADO = LIVRE PEÇA PROCESSADA = FALSO

ENTÃO ENTÃO

MÁQUINA DE FERRAMENTA TORNO 2FECHAR PORTA EXECUTARNOTIFICAR FECHAR PORTA COMANDO COMPOSTOCOMANDO COMPOSTO PEÇA PROCESSADA = VERDADEIROEXECUTAR

Figura 18: Rules PROCESSA PEÇA E MODIFICA PEÇA instanciadas manualmente.

Os exemplos apresentados neste relatório validam a técnica de emergência

automática desenvolvida, pois as Rules elaboradas através do novo método provaram-

se equivalentes aos comandos feitos manualmente. Ademais, a automacidade na

instanciação de tais agentes tornou utilização da ferramenta wizard muito mais rápida e

fácil e, deste modo, atingiu-se o principal objetivo do esforço de pesquisa descrito neste

relatório.

4.3 - Quanto ao Cumprimento do Plano de Atividades Proposto

O Plano de Atividades foi adequado às mudanças ocorridas no decorrer do

último ano, visto que este trabalho foi inicialmente desenvolvido pelo aluno Rômulo M.

Góes que teve de deixá-lo (em dezembro de 2010) para estagiar em universidade

canadense.

Em consquencia dito, o aluno Vagner Vengue assumiu o plano de atividades no

lugar de R. M. Góes, permanecendo até fevereiro de 2011, quando aceitou um estágio

na indústria. Por fim, o autor deste relatório assumiu em março deste ano, dando

continuidade ao plano de trabalho, o qual é constituído pelas seguintes atividades:

Atividade 1 – Revisão do simulador ANALYTICE II, Meta-modelo de Controle

Holônico orientado a Agentes-Regra (Notificantes) e Agentes-Produto e do novo Wizard

do Controle Holônico. Neste estudo foi prevista atenção especial a possibilidade de

emergência (i.e. criação) de Agentes-Regra automaticamente a partir dos Planos de

Processo dos Agentes-Produto.

Atividade 2 – Definição de uma técnica para permitir tal emergência e a evolução

do Wizard em questão para comportar o dado método.

Atividade 3 – Desenvolvimento de (pelo menos) um controle orientado a

Agentes-Regra e a Agentes-Produto, usando o Wizard evoluído e o ANALYTICE II.


PR

Este controle seria normalmente o equivalente a uma instância cujos Agentes-Regra

foram criados manualmente. Isto validaria a viabilidade da técnica de emergência no

Wizard evoluído.

Atividade 4 – Comparação qualitativa da instância com Agentes-Regras criados

manualmente e a instância com Agentes-Regras criados por emergência.

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

As atividades 1, 2, 3 e 4 foram executadas durante o evolução deste trabalho e

estão descritas neste relatório, estando concluídas. A atividade 5 foi cumprida com a

redação deste relatório e de um artigo apresentando os resultados da pesquisa que foi

submetido ao evento SICITE 2011.

5. Considerações

A evolução da ferramenta wizard descrita neste relatório possibilitou a

emergência automática de Agentes-Regra ou Rules a partir dos planos de processo,

resultando em uma colaboração para o Laboratório de Sistemas Inteligentes (LSI) da

UTFPR. O desenvolvimento desta técnica tornou mais fácil e rápida a criação de tais

agentes, possibilitando que o usuário concentre seus esforços na utilização destas

Rules.

Para a validação deste wizard evoluído buscou-se comparar Rules instanciadas

através da nova técnica e manualmente. Os resultados obtidos demonstram a

equivalência destes agentes, legitimando as evoluções da ferramenta.

Não obstante as dificuldades encontradas, a possbiliade de estar em contato

com um ambiente de pesquisa acadêmico, adquirir novos conhecimentos e auxíliar no

desenvolvimento de tecnologias foi gratificante ao autor deste relatório.

Por fim, prevê-se dentre os trabalhos futuros a elaboração de uma técnica que

possibilite também a emergência de Plano de Processo para Agentes-Produto ou

Produt-HLs a partir da confrontação (i.e. negociação) entre as necessidades de

produção destes e as capacidades de produção dos Agentes-Recurso.

6. Referências Bibliográficas


PR

[1] 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.

[2] Bongaerts L.: Integration Of Scheduling And Control In Holonic Manufacturing

Systems. Ph. D. Thesis. PMA / Katholieke Universiteit Leuven. Leuven (Belgium)

1998.

[3] Da Silveira, G.; Borenstein, D.; Fogliatto, F.S.: Mass customization: literature

review and research directions. Int. Jour. of Production Economics, 72(pp1-13),

2001.

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

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

[5] Goes, R. M.: Modelo de Composição Facilitada de Resource-HLs no Meta-

Modelo de Controle de um Simulador de Sistemas de Manufatura Holônico.

Relatório de Iniciação Científica. PIBIC/UTFPR, 2010.

[6] Koscianski, A.; Rosinha, L. F.; Stadzisz, P. C.; Künzle, L. A.: FMS Design and

Analysis: Developing a Simulation Environment. In Proceedings of the 15th

International Conference on CAD/CAM, Robotics and Factories of the Future,

vol.2. (p.25 - 210). Águas de Lindóia (Brazil) 1999.

[7] 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.

[8] 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.

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

de Controle Holônico sobre o Simulador ANALYTICE II e Comparações de

Políticas de Controle de Manufatura. Simpósio Brasileiro de Automação

Inteligente – SBAI, 2009.


PR

[10] Maří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. In 6, pp. 365-376.

[12] Morel, G.; Grabot, B. (Eds.): Intelligent Manufacturing. Special issue of

Engineering Applications of Artificial Intelligence, vol. 16 (4), 2003.

[13] Muhl, E.; Charpentier, P.; Chaxel, F.: Optimization of Physical Flows in an

Automotive Manufacturing Plant: some experiments and issues. In: 6, pp. 293-

305.

[14] 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.

[15] 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.

[16] Simão, J.M., Stadzisz, P.C. Inference Process Based on Notifications: The

Kernel of a Holonic Inference Meta-Model Applied to Control Issues. IEEE

Transactions on Systems, Man and Cybernetics. Part A, Systems and Humans,

Vol. 39, Issue 1, 238-250, Digital Object Identifier

10.1109/TSMCA.2008.20066371, 2009a.

[17] Simão, J.M., Stadzisz P.C., Tacla, C.A. Holonic Control Meta-Model. IEEE

Transactions on Systems, Man and Cybernetics. Part A, Systems and Humans,

Artigo

aceito, 2009b.

[18] 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.


PR

[19] 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.

[20] 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.

[21] Simão, J. M.; Tacla, C. A.; Stadzisz, P. C.: Holonic Control Metamodel. IEEE

Transactions on Systems, Man and Cybernetics. Part A, Systems and Humans, v.

39, p. 1126-1139, 2009.

[22] 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.

[23] Witt, F. A.; Banaszewski, R. F.; Lucca, J.; Stadzisz, P. C.; Simão, J. M.:

Evolução do Wizard sobre Meta-Modelo de Controle Holônico do Simulador

Analytice II e Comparações de Controle Orientado ao Processo e ao Produto.

Resumo Est. no Seminário de Iniciação Cient. e Tecn. (SICITE) - UTFPR, 2008.

[24] 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


PR

Viabilidade de Emergência de Agentes-Regra a partir do ...Final]_F_Marx_Benghi_2011.pdf ·...

Documents

Transcript of Viabilidade de Emergência de Agentes-Regra a partir do ...Final]_F_Marx_Benghi_2011.pdf ·...