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.
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
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.
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
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
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
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.
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
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.
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
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
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
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].
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
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.
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
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].
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
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
Instigation–SubHL.1
Instigation–SubHL.3
Instigation–SubHL.4
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
Instigation–SubHL.2
Instigation–SubHL.1
Instigation–SubHL.3
Instigation–SubHL.4
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.
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
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.
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
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.
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
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 à
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
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.
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
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
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
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.
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
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.
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
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
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
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).
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
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
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
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
... ...
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
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.
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
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.
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
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.
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
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
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
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.
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
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
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
[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.
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
[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.
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
[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
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