spi phys
Universite De Metz 
  
Koyama Ferreira 
  
Mauro 
  
Monsicur Ferreira 
  
Koyama Mauro 
  
Monsieur Lbrahima Sakho 
  
Monsieur Joâo 
  
Codirectcur Mauricio Rosario 
  
Monsicur François B Vernadat 
  
Prof Aos Meus 
  
Mauricio Joâo 
  
Rosârio 
  
Prof Fabius Marcius 
  
no Brasil Henriques De Carvalho 
  
Prof B François 
  
Na Vernadat 
  
França 
  
Aos Professores 
  
Jean-Marc Faure 
  
Manuel De 
  
Jesus Mendes 
  
Antonio Batocchio 
  
Paulo Corrêa Lima 
  
Prof. Ibrahima Sakho 
  
Ao Prof 
  
Didier Anciaux 
  
Dr Daniel Ao 
  
Roy 
  
Mauro Koyama 
  
Ferreira 
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

O tema enfocado por esta tese é a construçâo de Arquiteturas de

Indice

Problemâtica

Esta-se vivendo uma era de grandes mudanças, talvez uma das mais aparentes seja a crescente globalizaçâo da economia. Nâo é incomum a utilizaçâo no dia a dia de produtos das mais diversas origens geogrâficas: feitos no pais, nos vizinhos ou em paises distantes.

Esta presença de produtos manufaturados importados ilustra bem o aumento da competividade entre as empresas, que passou de um nivel regional ou nacional para o nivel internacional.

A constataçâo é de que esse é um movimento sem retorno, principalmente depois que os contra exemplos do capitalismo, as economias soviética e chinesa se transformaram parcialmente e que houve a reunificaçâo da Alemanha, cujo decênio foi comemorado no ano 2000.

A globalizaçâo da economia é suportada por uma crescente malha de telecomunicaçôes, cuja Indristria enfrenta, por seu lado, a revoluçâo da lnternet, com reflexos que vâo desde a demrbada dos custos de conexôes internacionais até a mudança de costumes de consumo.

Estas mudanças na economia comandam outras, nas estrufuras produtivas e na organizaçâo das empresas.

No aspecto gerencial as linhas de mudanças sâo variadas, passando pelas técnicas incrementais de melhoria de qualidade exemplificadas no Kaizen [mai 86], pela reengenharia de processos de negôcios [Hammer 94] e, entre outras tantas pela lnovaçâo de Processos [Davenport e3l.

Capitulo I Evoluçâo das empresas

O modelo de produçâo de bens de consumo padronizados em massa encontra-se em declinio. Este descenso é especialmente perceptivel a partir de meados da década de setenta quando afirma-se um novo modelo de consumo, onde hâ uma busca por mais funcionalidade e diversidade.

Alvin Toffler em seu livro "A Empresa Flexivel" [Toffler 85] analisa o caso da corporaçâo AT&T e aponta uma série de motivos para esta transiçâo. As mudanças sâo fruto da evoluçâo da prôpria sociedade industrial, mesclando efeitos sociais, culturais e de mercado. Dentre os fenômenos de mercado citados aparece claramente a digitalizaçâo da informaçâo, que começa a ser transmitida também por meios alternativos para a época, como o satélite e os cabos de banda larga ( neste riltimo caso trata-se de sinais de televisâo).

Os fenômenos sociais e culturais sâo exemplificados pela maior participaçâo feminina na composiçâo da mâo de obra, pelas reivindicaçôes das minorias étnicas demandando serviços diferenciados e por um crescente conflito de interesses entre as forças de mercado e as organizaçôes governamentais e sociais.

Evidentemente a demanda por bens de consumo nâo decresceu, muito pelo contrârio, o que acontece é uma mudança na qualidade do consumo. Os bens de consumo possuem um ciclo de vida cada vez mais curto, devido à crescente necessidade de inovaçâo e de melhoria de qualidade, exigidas pelos consumidores.

A definiçào de produto estâ mudando, para incluir também serviços e informaçâo (ou conhecimento). Segundo Toffler [Toffler 85] isto caracreriza uma mudança de paradigma, da sociedade industrial para o de sociedade superindustrial ( usando seus termos na época).

Outros autores confirmam estas mudanças em seus escritos. Peter Senge em seu livro "The Fifth Discipiine" ISenge 94] apresenta o conceito da organizaçâo que aprende, pontificando que o conhecimento contido em uma empresa é seu maior patrimônio. Esta tese jâ era sugerida por Toffler quando este mostrava a evoluçâo da produçâo, que jâ foi baseada na posse da terra (sociedade pré-industrial), no trinômio trabalho/ matérias-primas / capital (sociedade industrial) e finalmente na informaçâo (sociedade pôs-industrial).

Para este trabalho inleressa profundamente a ênfase de Senge na "Quinta Disciplina", por ele chamada de "Pensamento Sistêmico" ( Systems Thinking). Segundo ele, é esta visâo sistêmica que permite uma anâlise mais apurada das empresas. A visâo dos componentes de um problema isoladamente geralmente nâo permite a compreensâo do problema como um todo. Seu exemplo didâtico é o da chuva, percebida antes de ocorrer pelas suas manifeslaçôes tais como nuvens negras que se acumulam e folhas tremulantes nas ârvores. Antes mesmo da chuva ocorrer jâ pode-se também antecipar seus efeitos, pode-se supor que o volume dos riachos irâ aumentar temporariamente e que, apôs esta chuva, o céu se limparâ.

Tentar ver o todo ao invés de ver apenas os detalhes, ver a floresta e nào apenas as ârvores.

O trabalho de Senge é orientado para as pessoas, pois sâo elas que detêm o conhecimento, outra disciplina citada por ele sâo os modelos mentais. Estes modelos podem nâo ser conscientes mas influenciam fortemente a capacidade das pessoas de lidar com situaçôes diversas.

Mesmo quando a participaçâo humana é intencionalmente minimizada, como acontece nos sistemas automâticos de produçâo, visâo sistêmica e modelos sâo importantes ferramentas de anâlise e projeto, como buscar-se-â demonstrar neste trabalho.

l.l Conjuntura do Mundo Industrial

Em resposta aos estimulos do mercado as empresas de manufafura modifrcam-se. As estruturas de produçâo passam das grandes sériesda produçâo em massa, para as pequenas séries e produçâo sob medida e sob demanda. Ressalta-se a crescente importância da Tecnologia de Grupo e da Manufarura Celular.

Jâ nâo parece futurista a possibilidade da produçâo de um cerlo bem (unitârio) visando atender as especificaçôes de um dado consumidor, mesmo que este bem nunca mais venha a ser produzido. Dependendo do bem, as limitaçôes para sua produçâo hoje sâo apenas econômicas e nâo técnicas.

Mesmo no momenlo atual. onde ainda hâ uma predominância da produçâo em massa, a produçâo em pequenas séries e por pequenas empresas, apresenta um crescimento constante.

Existe uma necessidade de aprimorar os mecanismos de produçâo e de controle da produçâo, para alender os requisitos desle tipo de demanda, a qual apresenta cada vez mais variabilidade e restriçôes de qualidade eprazo de entrega. Charles Savage em seu livro "5th Generation Management" [ Savage 96] aponta a necessidade de se dominar o conhecimenlo e o processo de conhecer (knowledging). Seu enfoque é mais prôximo da manufatura, ele tece criticas ao modelo de CIM, que em realidade nào promove a integraçào pois deixa o elemento humano fora da equaçâo.

Seu trabalho apresenta também uma revisâo breve das restruturaçôes organizacionais, vista sob diversas ôticas e com diversos nomes como: Sistemas Holônicos, Empresa Fractal, Organizaçôes Virtuais para citar apenas os que apresentam maior interesse. Estes sâo esforços na direçâo de mudar o paradigma de gerência, outros esforços, provavelmente mais numerosos, sâo no sentido de informatizar as estruturas existentes.

Uma das conclusôes de Savage é de que nâo basta informatizar o que jâ existe, é preciso repensar a organizaçâo. Ele traça um paralelo com o desenvolvimento dos computadores, que enfrentou o chamado "Gargalo de Von Neumann". Este gargalo foi superado com o advento da computaçâo massivamente distribuida e das redes de computadores, no que foi chamado Computaçâo de Quinta Geraçâo. O foco de Savage é em formar uma rede de conhecimentos (lvtowledge networking) permitindo a passagem para a Gerência de Quinta Geraçâo.

De Savage interessa este enfoque na transmissâo de conhecimentos, nâo basta apenas conectar partes, é preciso definir interfaces que permitam que elas interoperem de maneira integrada ( grifou-se os elementos do discurso de Savage).

1.2 Supen'isâo e controle de châo de fâbrica Muito jâ foi escrito sobre a Manufatura Integrada por Computador (CIM), hoje sabe-se que algumas das crenças que esravam por trâs da sigla CIM foram invalidadas, como por exemplo o da empresa sem papéis e o da fâbrica sem operârios [ Savage 96].

No entanto outros aspectos dele, como a informatizaçào da produçâo e adoçâo de sistemas flexiveis de manufatura, foram melhor sucedidos e permitiram um aumento na produtividade das empresas.

Nesta tese hâ um interesse em pequenas e médias empresas, com uma produçâo diversificada. Relevante é pois a evoluçâo dos sistemas flexfveis de manufatura, decorrente dos trabalhos em Tecnologia de Grupo e dos avanços dos sistemas informâticos ( redes de computadores, bancos de dados, interfaces homem-mâquina, sistemas de supervisâo, etc.), do material de suporte ( computadores, controladores programâveis, robôs, etc.) e do material produtivo proPriamente.

Smith e Joshi [ Smith 95] argumentam que 50-75% dos componentes manufaturados nos Estados Unidos sâo fabricados em lotes pequenos e médios. Dizem também que apesar da tecnologia CIM surgir como um facilitador para esta produçâo ela ainda nâo atingiu os beneficios esperados, devido aparentemente a problemas de integraçâo' Talvez estes problemas sejam decorrentes da complexidade dos sistemas de manufatura.

Fala-se em sistemas Flexiveis de Manufanrra, mas mesmo a definiçâo do que é flexibilidade é ârdua, como bem apontam Sethi e Sethi [Sethi 90] que indicam que "ao menos 50 termos para vârios tipos de flexibilidade podem ser encontrados na literatura de manufatura". Em seu levantamento sobre flexibilidade eles discorrem sobre os aspectos econômicos, organizacionais e de manufarura e propôem uma organizaçào de tipos entre os quais pode-se citar as flexibilidades: de processo, de roteamento, de produto, de volume e de expansâo. uma definiçâo interessante apresentada por eles é a de Flexibilidade de Produçâo, a qual é descrita como: "Flexibilidade de Produçâo é o universo de tipos de componentes que o sistema de manufatura pode produzir, sem adicionar maior capital em equipamentos". Argumentam que através de investimentos menores, tais como novas ferramentas pode-se, talvez as custas de "setups" considerâveis, aumentar a produçâo.

A Flexibilidade de Produçâo, segundo eles, necessita da concorrência de diversos meios, como "variedade e versatilidade das mâquinas, flexibilidade do sistema de transporte e do sistema de informaçâo e controle em uso". É imporfante ressaltar a necessidade de integraçâo entre esles meios, para que a produçâo flexivel seja realizada. Integraçâo estâ intimamente ligada à tomada de decisâo, como verifica-se no trinômio "Sistema de Decisâo / Sislema Fisico/ Sistema Operante" da arquiterura GRAI-GIM (vide Capirulo 2), na qual o elemenlo "Sistema de Informaçâo" aparece como elemento de suporte destes três comPonentes.

Thierauf [Thierauf 82] considera que os sislemas de decisâo possibilitam a gestâo dos recursos disponiveis da empresa ( homens, mâquinas, materiais e capital) através do uso dos sistemas de informaçâo. Um sistema de controle de châo de fâbrica é parte integrante do sistema de decisâo da empresa e é fundamental que haja um fluxo de informaçôes entre os niveis mais altos de decisâo e este sistema, nos dois sentidos, para que a gestâo dos recursos seja efetiva.

Infelizmente os modelos de gerenciamento de empresa, segundo Savage, em sua maior parte sâo baseadas em hierarquias profundas (steep hierarchies). O Châo de fâbrica aparece entâo como camadas inferiores destas hierarquias. Da mesma maneira como as estrufuras organizacionais estâo sendo forçadas a modificar-se, as estruturas de controle, até sob influência daquelas, também o estâo.

Caminha-se para o fortalecimento da capacidade de decisâo do châo de fâbricam, uma mudança necessâria para permitir à empresa uma adaptaçâo râpida e eficiente às variaçôes de demanda e de suprimento do mercado.

Conclusâo

Neste capitulo apresentou-se a evoluçâo das empresas ao longo do tempo, mostrando que estâ-se em pleno processo de transiçâo, do paradigma da produçâo em massa para o de produçâo sob medida, da idéia de produto como bem de consumo fisico e palpâvel à idéia de produto também como serviço ou conhecimento.

Os sistemas de produçâo apresentam os reflexos desta transiçâo. A Manufatura Integrada por Computador (ClM) trouxe ganhos significativos na década de oitenta, mas nào chegou a realizar plenamenle seus objetivos naquela época, possivelmente por estar atrelada a estruturas antigas de produçâo.

Os Sistemas de Controle de Chào de Fâbrica, parte da estratégia CIM, é onde se pode observar ganhos concrelos em produtividade, devido ao crescente nivel de informatizaçào e automaçâo. Mesmo assim esles sistemas nâo estâo adaptados às novas exigências de mercado, que pedem capacidade de resposta râpida, qualidade, diversidade e custo reduzido.

Acredita-se que os trabalhos de Toffler [Toffler 85], Senge ISenge 94] e Savage [Savage 96], mesmo tendo como foco os elementos organizacionais, aponlam o caminho da mudança: a gestâo do conhecimento da empresa. Para realizar esta gestâo é necessârio adquirir uma visâo sistêmica, que considere o maior nrimero possivel de aspectos e as fases de evoluçâo temporal.

O problema de integraçâo da manufatura é extremamente complexo, o que permite abordâlo é a utilizaçâo de modelos, que sâo transformados em elementos de diâlogo entre as pessoas que devem realizar este projeto de integraçâo. Como Savage aponta, nâo basta apenas conectar subsistemas, é preciso integrâ-los e para isto sâo necessârias interfaces.

O châo de fâbrica reproduz a problemâtica com a qual as empresas se deparam; assim como estâo sendo pesquisadas novas estruturas organizacionais (Fractal, Holônica, Virhral ...) também devem ser pesquisadas novas arquiteturas de controle, a partir da premissa de que o conhecimento (e a capacidade de decisâo decorrente dele) juntamente com a partilha (comunicaçâo) do mesmo devem ser os elementos bâsicos de projeto.

No capitulo seguinte serâ mostrado o estado da arte em sistemas de controle de châo de fâbrica, em modelagem de integraçâo e arquiteturas de referência e haverâ uma discussâo sobre sistemas de informaçâo considerando explicitamente as disciplinas de infra-estrutura de integraçâo, padrôes industriais de comunicaçâo e sistemas multi-agentes. l0 Capitulo 2

Supervisâo e Controle de Châo de Fâbrica

Como mostrado no capitulo anterior, as mudanças nos perfis de consumo engendram outras nas estrufuras produtivas. Nesta tese o interesse é no elemento final de produçâo, o Châo de Fâbrica. Para propor um enfoque de desenvolvimento de estruturas de controle / arquiteturas adequadas à nova realidade, serâ mostrado um panorama do estado atual de conhecimento sobre "Supervisâo e Controle de Châo de Fâbrica", sobre a integraçâo das funçôes de controle dentro do âmbito maior das "Arquiteturas de Referência" e finalmente serâo revisadas um conjunto de disciplinas que apresentam interesse para arealizaçào deste trabalho, que sâo as "Infra-estruturas de Inlegraçâo", os protocolos de comunicaçâo industriais e os Sistemas Multi-Agentes.

2 Supervisâo e Planejamento da Produçâo A Arquiterura NBS teve uma grande projeçâo e foi estendida através do "Modelo de Automaçâo de Fâbrica" da ISO (lnternational Organisaîionfor Standardization)'

Tipos de Produçâo

Antes de continuarïnos com a discussâo sobre arquiteturas é preciso fazer uma distinçâo breve entre os diferentes tipos de produçâo. A produçâo pode ser continua, quando existe um fluxo continuo de material entre os meios de produçâo, ou discreta, quando este fluxo for discreto ou seja, realizar-se por unidades fisicamente reconheciveis.

Um exemplo de produçâo continua é uma Refinaria de Petrôleo, que recebe petrôleo bruto e fornece derivados como gasolina, querosene e outros. Para a produçâo discretizada interessa saber o tamanho dos lotes de produçâo e a variaçâo no tipo de produtos. A produçâo em massa consiste em produzir lotes muito grandes. Considerase neste trabalho uma produçâo diversificada, que conterâ lotes de menor tamanho e com uma grande gama de Produtos. Numa segunda fase buscou-se uma maior abstraçâo na descriçâo dos relacionamentos dentro da empresa, quebrando as barreiras funcionais, dentro de uma linha de descriçâo por processos de negôcios (BP). O grande expoente desta lendência é o projeto CIMOSA (ESPRIT Project 688) ICIMOSA 93] sendo que este projeto ressalta a importância de se considerar a empresa sob diversas vistas.

Arquiteturas de Referência

Serâo descritas brevemente algumas arquiteturas de referênciapara integraçâo de empresa. O método GRAI baseia-se no uso de duas ferramentas. GRAI Grid e GRAI Nels [ Doumeingts 87].

GRAI Grid é usada para descrever hierarquicamente a estrutura de decisâo de um Sistema de Gerência de Produçâo, consisle em uma matriz na qual as linhas representam os centros de decisâo, classificados de cima para baixo de acordo com os critérios de Horizonte e Periodo de Decisâo. Horizonte de decisâo (H) é um intervalo de lempo em que os estados do sistema sâo conhecidos e estâ relacionado aos seus ciclos (de fabricaçâo" de compras, etc. A Figura 2.8 apresenta um exemplo de cadeia de processo que permite ilustrar as vistas usadas em ARIS.

Esta cadeia consiste numa seqûência de proôessos individuais que transformam informaçôes, sendo que cada processo é iniciado e concluido sob à açâo de eventos.

A modelagem de empresa segundo ARIS envolve quatro vistas: funçâo, informaçâo, controle e organizaçâo.

A Vista de Funçâo descreve uma hierarquia de funçôes especificadas como estruturas e môdulos de programas que tornar-se-âo côdigo de programa.

A Vista de Informaçâo contém modelos semânticos de dados definidos na forma de diasramas entidade-relacionamento. 

Descriçâo de lmplementaçâo

Cadeia de processo "processamento de pedidos" Unidade organizacional Figura 2.8: Cadeia de processos ARIS : lScheer 941 A Vista de Organizaçâo estabelece departamentos e pessoas relacionadas a cada processo, topologia de redes de comunicaçâo etc.

A Vista de Controle relaciona-se às três outras vistas e contém as cadeias de atividades ou processos de neg6cios implementadas como seqûências lôgicas de programas computacionais No entanto esle suporte nâo se reflete na descriçâo clara de uma infra-estrutura de integraçâo.

CIJ\IOSA (Open Sysrem Architecture for CIM)

A arquitetura CIMOSA foi desenvolvida na Europa, através do Consôrcio AMICE que contava com a participaçâo de diversas empresas (Digital, IBM, HP. etc.) e centros de pesquisa (GRAI, V/ZL,INRIA ...) ICIMOSA 93]. Seu objetivo é "permitir a modelagem de empresa para a exploraçâo eficiente do conhecimento da mesma".

CIMOSA utiliza três conceitos para permitir a modelagem de empresas:

-Quadro de referência (contendo Arquitetura de Referência, Arquitetura Particular, Modelo da Empresa).

-Ciclo de Vida do Sistema e Ambientes de Engenharia e Operaçâo' -Infra-estrutura de Integraçâo. Glossârios -"terminologia usada em engenharia de empresa definida em linguagem natural".

Meta-modelos -"modelos conceituais do componente de terminologia das linguagens de modelagem". Descreve os conceitos e seus relacionamentos.

-Teorias ontolôgicas -"modelos formais de conceitos usados na representaçâo de empresa". Descrevem a semântica das linguagens de modelagem utilizadas.

PEMs (Partial-enterprise models) "capruram caracteristicas comuns a muitas empresas dentro ou através de um ou mais setores industriais" ISO 98]. Estes sâo modelos de referência reutilizâveis, os processos de engenharia de empresa podem basear-se nestes componentes testados para construir um modelo especifico de empresa [ Vemadat 96].

EETs (Enterprise Engineering Tools) "implementam uma metodologia de engenharia de empresa e suportam as linguagens de modelagem" permt'tindo a geraçâo dos ENIs (Enterprise Models), modelos particulares de empresa.

EMOs (Enterprise modules) "sâo blocos construtores implementados ou sistemas que podem ser usados como recursos comuns na engenharia e integraçâo de empresa". A Infraestrutura de Integraçâo é composta por um conjunto destes môdulos.

EOSs (Enterprise-operalional syslems) "suportam a operaçâo de uma empresa especifica.

Contém todo o hardware e software necessârios para cumprir os objetivos e metas da empresa" uso e8l.

Na descriçâo de GERAM hâ um item intitulado "Conceitos orientados à Tecnologia", onde se discute o suporte de tecnologia de informaçâo para a engenharia e integraçâo de empresas.

Neste item é apresentada, em carâter ilustrativo a infra-estrutura EMEIS (Enterprise Model Execution and Integration Services) sobre a qual discorrer-se-â em mais detalhe no item Infraestrufuras de Integraçâo".

Disciplinas Relacionadas

As 

Serviços do MMS

Serâo descritos os serviços do MMS, agrupados de acordo com sua funcionalidade em: suporte do VMD, gerenciamento de dominios, execuçâo remota de programas, gerenciamento de contexto/conexâo, acesso a variâveis, comunicaçâo com o operador, gerenciamento de eventos e alarmes, gerenciamento de semâforos, gerenciamento de periôdicos e gerenciamento de arquivos.

Quando for relevante serâo listados ou explicados os serviços, caso contrârio descrever-se-â apenas o grupo.

Suporte do VMD

Estes serviços permitem a um cliente MMS a determinaçâo das caracteristicas e condiçôes gerais de um servidor MMS.

Status -Informa a um cliente MMS as condiçôes gerais do servidor MMS, estas condiçôes englobam os aspectos lôgicos (serviços disponiveis) e fisicos (estado do hardware). A resposta deste serviço inclui detalhes de padrôes associados.

IJnsolicitedstatus -'il gerado espontaneamente pelo servidor MMS para informar as suas condiçôes; no mais é idêntico ao serviço de Status.

GetNumell'sl -Através deste serviço um cliente MMS pode solicitar, ao servidor MMS, a devoluçâo de uma lista de nomes de objetos que cumpram os requisitos especificados no serviço. Estes requisitos devem incluir, por exemplo, a classe do objeto (Named Variable, Semaphore, etc.).

Identify -Fomece a informaçâo de identificaçâo do servidor MMS, a qual contem: o nome do fabricante, nome do modelo e o nivel de revisâo de sistema em utilizaçâo.

Rensme -Usado por um cliente MMS, para pedir a modificaçâo do identificador de um objeto, para um novo identificador especificado.

Gerenciamento de dominios

Um dominio representa um subconjunto de recursos de um VMD que é usado para um propôsito especifico. Exemplos de dominios sâo programas, variâveis e dados. 

Gerenciamento de contexto/conexâo

Estes serviços permitem que os pares de Processos de Aplicaçâo(o iniciador e o receptor da comunicaçâo) negociem, mantenham, liberem e abortem uma conexâo lôgica.

Comunicaçâo com o operador

Estes serviços permitem a comunicaçâo com uma estaçâo de operador, que aceite entrada de dados, apresentaçâo de dados ou ambas as coisas.

Gerenciamento de eventos e alarmes

Permitem gerenciar eventos e alarmes.

Serviço de gerência de semâforos

Estes serviços permitem a sincronizaçào, controle e coordenaçâo de recursos compartilhados entre usuârios do MMS.

Gerenciamento de periôdicos

Existem para prover facilidade no armazenamento e recuperaçâo de informaçâo cronologicamente ordenada que diz respeito a eventos, variâveis associadas a eventos ou ambos e texto, que é utilizado como anotaçâo explicativa ou comentârio.

Gerenciamento de arquivos

Sâo utilizados na leifura de arquivos, para gerenciar armazenadores de arquivos, renomear e apagar arquivos. Nâo sâo utilizados para acesso aleatôrio ou modificaçâo nos arquivos. Os serviços existentes no MMS para gerenciar arquivos sâo um subconjunto da norma ISO FTAM (File Transfer, Access and Management).

Os mecanismos para a criaçâo dos padrôes associados podem ser usados também para a criaçâo de um VMD de um dispositivo qualquer, assim Rondeau [Rondeau 95], criou VMDs que foram usados pela Companhia de Metrô de Paris, através de um aprimoramento da anâlise dos objetos sob a ôtica da metodologia entidade-relacionamento.

lnfr a-estruturas de Integraçâo (IEI)

O objetivo das IEI é dar suporte para a integraçâo de sistemas, permitindo a integraçâo de recursos heterogêneos e provendo meios para controlar os processos envolvidos ICIMOSA 93].

Em prover informaçôes de estado das Funçôes Operacionais e das Entidades Funcionais alocadas às Funçôes Operacionais.

alocar e liberar Recursos de e para as Funçôes operacionais Gerência de Informaçdoprovê acesso ao sistema global de informaçôes e aos serviços eletrônicos de trocas de dados (por ex. : EDI, STEP e SGML).

-
Repositôrio "Run-Time" de Modelosmantém um registro (no momento da execuçâo -Run-Time) das entidades envolvidas na execuçâo de modelos.

c) Serviços Compartilhados

Sâo compostos pelos serviços que sâo relevantes para os Serviços de Desenvolvimento de Modelos e Serviços de Execuçâo. Eles sâo os serviços de:

Conftabilidade, Segurança, Contrato e Inlermediaçdo, Encapsulamento, Distribuiçdo de Modelos.

Sistemas Multi-agentes

Sistemas Multi-agentes (SMAs) sâo um dos ramos da Inteligência Artificial, sendo esta uma ârea do conhecimento onde ainda persistem indefiniçôes de nomenclatura, talvez por coexistirem enfoques conceituais oriundos de âreas diversas. O interesse é na aplicaçâo de sistemas multi-agentes nos sistemas de manufatura, os conceitos, definiçôes e exemplos relacionados a esse dominio serâo objeto de atençâo'

Tentar-se-â delinear um quadro conceitual que permita posicionar os sistemas multi-agentes de maneira a apontar os aspectos mais relevantes para o seu uso em um sistema de supervisâo e controle de produçâo. Organizaçâo) e a partir deles pode-se construir modelos parciais (adequados à uma classe de empresas) e destes modelos parciais pode ser instanciado um modelo particular adequado à uma empresa especifica.

Os Blocos Funcionais CIMOSA e GERAM existem para a construçâo de modelos. Como foi visto pretende-se que estes modelos possam vir a ser interpretados ou compilados, de maneira a permitir a execuçâo do côdigo equivalente, através de uma infra-estrutura de integraçâo apropriada. A questâo que colocada foi se seria possivel desenvolver Componentes Genéricos que pudessem desempenhar um papel anâlogo aos Blocos Funcionais, mas dentro do contexto de infra-estrutura de integraçâo, e com a reduçâo do escopo do nivel de Empresa paru o nivel de Châo de Fâbrica.

Estes Componentes Genéricos nâo buscam compatibilidade com as Arquiteturas CIMOSA ou GERAM, apesar de dai colherem vastos subsidios para sua elaboraçâo. Isto se deve ao fato de se buscar um enfoque pragmâtico, tentando propor elementos para facilitar a um projetista o desenvolvimento de uma arquitetura de supervisâo e controle.

Neste enfoque buscou-se unir o projeto de baixo para cima (botlom-up), considerando os elementos reais existentes no châo de fâbrica, com o projeto de cima para baixo (top-down) qure considera uma vista mais ampla do mesmo setor. Como nâo hâ ainda uma validaçâo e aceitaçâo ampla, pela comunidade de usuârios industriais e acadêmicos, de qualquer IEI (incluindo-se ai CIMOSA e GERAM), e considerando ainda, a emergência na riltima década, de importantes evoluçôes nos sistemas distribuidos e nos modelos de desenvolvimento de programas, surgiu a opornrnidade de propor uma contribuiçâo conceitual e experimental ao problema.

Os Componentes Genéricos estâo, ao nivel da IEI , dando suporte para a implementaçâo de Arquiteturas para Supervisâo e Controle do Châo de Fâbrica. Eles poderâo servir de "tijolos" que permitirâo construir a "Arquitetura Particular" que permita resolver um problema especifico de uma empresa.

2 Arquitetura ExPerimental

No capitulo anterior posicionou-se o Châo de Fâbrica no contexto de gerenciamento e controle da produçâo, através da Um dos propôsitos gerais deste trabalho é permitir uma maior autonomia do Châo de Fâbrica, considera-se que nâo é prudente tentar obter esta autonomia diretamente a partir da definiçâo de uma arquitetura, mas sim a partir dos componentes associados por meio dela.

Decidiu-se assim utilizar o conceito de Sistema Multi-Agentes (SMA) para a construçâo dos componentes e da arquitetura. Como visto no capitulo anterior o conjunto de vantagens apresentados pelos SMAs, quanto ao grau de autonomia permitido a um sistema especifico, depende de decisôes do projetista. Tais decisôes nâo podem ser antecipadas, mas podem ser suportadas através de uma definiçâo adequada dos Componentes Genéricos. As mensagens podem chegar de fora ou internamente ao agente. Os protocolos de comunicaçâo dependem deste par Cliente / Servidor, uma parte do protocolo é realizada no lado Cliente e outra no lado Servidor; para fins de descriçâo do agente pode-se chamar de protocolos locais as partes que sâo realizadas pelo agente.

Assim na Figura 3.5 hâ dois protocolos locais, SCRP e SSRP, eles fazem par com outros dois protocolos locais definidos nos agentes com os quais se comunicam. Este protocolos locais podem ser descritos através de mâquinas de estado, cada parte da transaçâo (Cliente ou Servidor)

terâ usa prôpria mâquina. Acredita-se que este enfoque (KIF + KQML), apesar de ter sido utilizado em alguns projetos na ârea de manufatura, por exemplo no PACT [ Tenenbaum 92], nâo é ainda apropriado para os sistemas de supervisâo e controle de châo de fâbrica por :

ser demasiado genérico, ainda restam por desenvolver as ontologias que permitam um diâlogo padronizado relativo ao châo de fâbrica e planejamento da produçâo.

nâo considerar a interface com os padrôes industriais existentes, MMS e Fieldbuses.

nâo ser formalmente bem definido, segundo Lesperance et al. fLesperance 96] Neste sentido a proposta deste trabalho é desenvolver um sistema de mensagerts "ad hoc", que considere os protocolos industriais de comunicaçâo como referência geral e que ao mesmo tempo deixe abertura para adequar-se aos novos protocolos que deverâo ser desenvolvidos, talvez na linha (KIF + KQML).

O sistema de comunicaçâo engloba duas partes, a primeira estâ relacionada com as regras paru a comunicaçâo, descrita através de um protocolo de comunicaçâo, a segunda estâ relacionada com a estrutura sintâtica das mensagens, que permite que elas sejam transmitidas e reconhecidas por sistemas heterogêneos.

Modelo de Protocolo

Os agentes se comunicam através de mensagens, a chegada de uma mensagem em um agente que estava inativo dâ inicio a uma nova transaçâo (ou conversaçâo), o decorrer desta transaçâo é subordinado ao protocolo utilizado. O protocolo é dividido em duas partes, uma Cliente e a outra Servidor, cada uma delas é descrita por uma mâquina de estados. Cada mâquina de estados é descrita usando técnicas de desenvolvimento de sistemas de tempo real [V/ard 85],

[Hatley 88], considerando:

-Pré Condiçôes -Açôes

-Pôs Condiçôes

As pré e pôs condiçôes sâo ativadas baseadas em eventos internos ou externos (por exemplo chegada de mensagens de um certo tipo). As açôes contém o tratamento esperado para o evento recebido.

Sistema de mensagens

Existem duas visôes necessârias para desenvolver o sistema de mensagens, a visâo semântica e a visâo sintâtica.

A Neste sentido utiliza-se também uma descriçâo com Diagrama de Fluxo de Dados (DFD) , que permite uma explicitaçâo mais realista da troca de mensagens e um refinamento em niveis se necessârio.

Em UML sâo utilizados Diagramas de Uso (Use Cases) que mostram quais sâo as funçôes bâsicas executadas pelo sistema e como elas se relacionam. Os relacionamentos sâo do tipo herança, extensâo, comunicaçâo, etc. Eles permitem começar a estruturar as classes de objetos envolvidas no projeto.

A Figura 3.9 mostra um Diagrama de Uso, extraido de [ Douglass 98]. Comportamentoquanto ao comportamento dos objetos, UML prevê a utilizaçào das "statecharts" desenvolvidas por Harel [Harel 87], que também lazparte do grupo que desenvolve as especificaçôes UML. Descrever um sistema complexo através de mâquinas de estado simples pode ser uma tarefa dificilima, devido ao nrimero de estados envolvidos. A idéia por trâs das "statecharts" é permitir uma estruturaçâo hierârquica do sistema, com respeito 'a evoluçâo dinâmica de seus estados.

Problemas da especificaçâo das "Statecharts", tais como uma certa indefiniçâo semântica dos grâficos e simbolos ("Statecharts" é uma ferramenta visual), foram sendo resolvidos, pelo A seqùência que serâ utilizada é baseada na metodologia de projeto apresentada no capitulo anterior. Utilizar-se-â como alvo para este prot6tipo a plataforma PIPEFA [ Rosârio 96],

composta por uma célula de montagem e desmontagem e equipamentos e aplicativos associados (vide Figura 4.6).

A PIPEFA permite a montagem ou desmontagem de uma variedade de 26 produtos, que podem ser produzidos em forma unitâria ou em pequenos lotes. A alimentaçâo de matéria prima nos alimentadores e a retirada dos produtos acabados (ou rejeitados) dos depôsitos é feita manualmente, porém todo o restante da produçâo e verificaçâo de qualidade do produto é feita automaticamente sob controle computadorizado.

Esta plataforma é representativa dos problemas reais encontrados em Sistemas Flexiveis de

Produçâo, pois contém dispositivos reais de sensoriamento e atuaçâo, bem como aplicativos de supervisâo e controle da produçâo disponiveis comercialmente. Em vista disso acredita-se que a derivaçâo de uma Arquitetura de Supervisâo e Controle para a PIPEFA serâ de grande valia para dimensionar a qualidade do trabalho desenvolvido com os Componentes Genéricos e a Arquitetura Experimental.

Inicialmente serâo apresentadas duas arquiteturas referenciadas na literatura e que sâo aplicâveis à PIPEFA. Discorrer-se-â rapidamente sobre a questâo de algoritmos de escalonamento adequados a essa aplicaçâo e far-se-âo algumas observaçôes sobre como considerar as restriçôes colocadas pelo mundo real de sistemas de produçâo.

Partir-se-â entâo para projetar uma arquitetura adequada à PIPEFA, seguindo a metodologia especificada e desenvolvendo os Componentes Genéricos e Arquitetura Experimental.

Mostrar-se-â o estado atual da implementaçâo e far-se-â uma avaliaçâo dos resultados disponiveis.

Seleçâo de uma Arquitetura

Dentre os exemplos descritos na literatura de Sistemas de Supervisâo e Controle baseados em SMAs, foram selecionados dois, considerando os critérios:

aplicabilidade a um Sistema Flexivel de Produçâo de pequeno porte ( Célula) real.

disponibilidade de documentaçâo adicional além dos artigos de referência. 

Arquitetura selecionada

Os dados obtidos das duas arquiteturas que foram estudadas em mais detalhe nâo permitem decidir da superioridade de uma sobre a outra, devido ao fato de que nâo se dispûnha do mesmo conjunto de dados de controle, mesmo conjunto de algoritmos de escalonamento e da mesma estrutura fisica de produçâo para comparâ-las.

Ambas as arquiteturas sâo baseadas no conceito de SMAs, com as vantagens associadas a este enfoque.

Elas também usam o conceito de agente Recurso para encapsular as funcionalidades do sistema fisico de produçâo.

As duas usam uma forma de representaçâo do conhecimento sobre o produto através de um agente Produto.

Um m$dulo externo de escalonamento é usado por SYROCO, sendo que a execuçâo e controle do escalonamento é realizada pelo agente Supervisor, enquanto PHOCS / PARSIFAL usa um agente de escalonamento (PARSIFAL) e outro de controle (PHOCS).

SYROCO utiliza um agente Meta Objeto para gerar dinamicamente outros agentes, neste sentido tem uma complexidade estrutural maior do que PHOCS / PARSIFAL.

Decidiu-se pela utilizaçâo de uma estrutura baseada na arquitetura SYROCO, esta escolha deveu-se a:

ela prevê o uso de ferramentas externas, sendo projetada de maneira modular e expansivel (através destas ferramentas)

desenvolvimento e experimentaçâo de algoritmos pode ser feito sem modificar a arquitetura (eles sâo fornecidos pelas ferramentas externas).

a estruturaçâo de SYROCO lembra o modelo NBS, facilitando sua compreensâo pelo pessoal do châo de fâbrica a cooperaçâo acadêmica existente entre a Universidade de Campinas e a Universidade de Metz facilitaria o uso da arquitetura.

Contudo, devido à maior complexidade de SYROCO, algumas modificaçôes estruturais foram feitas, visando adaptâ-la ao problema de controlar a célula de produçâo da PIPEFA.

A experiência da FEM-Unicamp em conjunto com o ITI, com sistemas reais e com a PIPEFA, aponta para a necessidade de arquiteturas enxutas, facilmente explicâveis ao usuârio e compativeis com os recursos reais existentes. Neste sentido foi proposta uma modificaçâo que aproxima SYROCO das hierarquias de sistemas de controle de châo de fâbrica existentes, sem no entanto desvirtuar sua filosofia de distribuiçâo e reatividade. agente Célula de SYROCO-2 pode ser derivado do agente Opcional da Arquitetura

Experimental.

agente Recurso de SYROCO-2 mapeia-se no agente Recurso da Arquitetura Experimental A Figura 4.3 apresenta esquematicamente a derivaçâo de SYROCO-2. No lado esquerdo estâ a Arquitetura Experimental e no lado direito a Arquitetura derivada SYROCO-2.

SYROCO-2 herdarâ as capacidades de comunicaçâo e interfaceamento existentes na

Arquitetura Experimental, os fluxos de mensagens entre os seus agentes componentes deverâo ser redefinidos a partir dos existentes na Arquitetura Experimental, de acordo com a metodologia proposta no capitulo anterior e que serâ ilustrada neste capitulo.

A cardinalidade dos agentes é: Um Supervisor, Um Meta Objeto, vârias Células e vârios Recursos. Na prâtica serâ adotada a simplificaçâo de permitir apenas uma Célula ativa.

C1

Figura 4.3: Derivaçâo de SYROCO-2 4.2 Seleçâo de Algoritmo de Escalonamento "Escalonamento é a alocaçâo de recursos no tempo para realizar uma coleçâo de tarefas" [Baker 74]. Antes do escalonamento ser realizado, é preciso que a resposta para três questôes de planej amento estejam respondidas:

que produtos ou serviços deverâo ser providos? em que escala eles serâo providos? quais recursos estarâo disponiveis?

A partir destas respostas o problema de escalonamento procura determinar as questôes:

qual recurso serâ alocado pararealizar cada tarefa? quando cada tarefa serârealizada?

I1

Mostrou-se no Capitulo 2, Figura 2.1 "Planejamento da Produçâo Tradicional", como estâ organizada a relaçâo entre as fases de planejamento execuçâo da produçâo. Tradicionalmente pressupôe-se que as questôes de planejamento citadas estejam resolvidas, um escalonador, ainda no nivel de planejamento, determina entâo a alocaçâo fisica e temporal das tarefas, cabendo ao châo de fâbrica a execuçâo deste escalonamento.

Neste esquema tradicional a obtençâo de um escalonamento pode levar horas ou dias fNewman 88], o que o torna incompativel com as necessidades atuais de sistemas de produçâo diversificada em pequenos lotes (mesmo que eventualmente ainda possa ser usado em outras aplicaçôes).

A tendência corrente é de "fortalecer" o châo de fâbrica, transferindo-lhe parte das atribuiçôes de escalonamento, as arquiteturas PHOCS/ PARSIFAL e SYROCO sâo representativas desta tendência.

As novas arquiteturas que estâo sendo desenvolvidas, para melhorar a resposta do châo de fâbrica às perturbaçôes, necessitarâo também de novos algoritmos de escalonamento. Na atualidade, nos poucos casos em que hâ um escalonamento de curto prazo, sâo utilizadas heuristicas. para fazer um escalonamento dinâmico um "despachador" utiliza desde regras simples de prioridades, até heuristicas mais complexas e regras de decisâo I Newman 88].

Lin e Solberg [Lin 9l] argumentam que é possivel melhorar o desempenho de um sistema de produçâo se for adicionada flexibilidade nos planos de processo (significando que a seqÛência de operaçôes nâo é fixa). Para permitir uma resposta râpida sâo usadas "regras de despacho", um total de nove foram testadas. Este tipo de enfoque nâo usual estâ sendo possivel devido à evoluçâo das arquiteturas e dos recursos computacionais.

Um extenso levantamento de algoritmos de escalonamento da produçâo, passiveis de serem aplicados à sistemas heterârquicos, foi realizado em [ Baker 98]. Sem drivida serâo necessârios adaptar os algoritmos existentes e inventar novos, como afrrma Baker. Acredita-se que é possivel inovar nas arquiteturas, trazendo poder de decisâo ao châo de fabrica, através do uso de algoritmos simples e eficazes, jâ amplamente testados na prâtica.

As estruturas de decisâo e controle estâo deixando de ser puramente hierârquicas, passando a ser hibridas ou heterârquicas. Rolstadas [Rolstadas 94] afirma que "para realizar o sistema de planejamento e controle de produçâo da prôxima geraçâo, técnicas de modelagem serâo importantes", este trabalho é um primeiro passo neste sentido.

Para cumprir o objetivo, os algoritmos de escalonamento sâo meios e nâo fins, neste sentido optou-se pela arquitetura SYROCO, na qual a funcionalidade do escalonamento estâ disponivel em um môdulo externo, permitindo entâo testar diversas possibilidades sem modificar a arquitetura.

Lin e Solberg [Lin 91] usaram regras de despacho, Bongaerts [Bongaerts 98] usou um algoritmo para minimizar o atraso, Roy [Roy 98] usou um algoritmo baseado no "simulated annealing". O môdulo de escalonamento aparece entâo como mais um elemento de experimentaçâo.

Neste sentido a primeira versâo deste môdulo deverâ utilizar um algoritmo de "Busca

Local" desenvolvido em [Claudio 00], baseado em algoritmos divulgados na literatura [ Pirlot 96],

[ Fadil 97]. O algoritmo desenvolvido possui ordem quadrâtica e seu mecanismo de busca local procura evitar 6timos locais, através da anâlise de um maior nûmero de vizinhanças.

Projeto e ImPlementaçâo

Usualmente as fases de Projeto e Implementaçâo sâo executadas separadamente, no entanto neste caso técnicas de prototipagem foram usadas, de forma que estas fases foram combinadas.

As especificaçôes foram transferidas para um Sistema Multi-agentes, desenvolvido usando a linguagem Java [Flana gan 97].

A intençâo foi de procurar caracteristicas genéricas que poderiam permitir a reutilizaçâo dos resultados do projeto em aplicaçôes subsequentes. Este é um primeiro esforço com o propôsito de desenvolver blocos genéricos que facilitem a integraçâo da manufatura.

Descrever-se-â a Arquitetura Experimental e como ela pode ser configurada para gerar a Arquitetura Particular SYROCO-2. Deve ser observado que Java nâo é projetada para aplicaçôes de tempo real, mas hâ uma tendência de usâ-la em projetos de controle de châo de fiâbrica. Considerou-se que os requisitos especificos de tempo real desta aplicaçâo podem ser satisfeitos por programas dedicados de Supervisâo e Controle e pelos Controladores Programâveis jâ existentes no ambiente PIPEFA.

Sistema OPeracional

V/indows foi escolhido como sistema operacional. Espera-se que as aplicaçôes em desenvolvimento rodem também em ambiente Unix devido ao c6digo em Java.

Definiçâo de Requisitos

Nesta fase a reatividade foi enfatizada. O sistema deve ser capas de responder a eventos imprevistos, vindos tanto do nivel mais alto (planejamento da produçâo) quanto do nivel inferior, na forma de notificaçôes de quebra de mâquinas.

Os seguintes requisitos gerais foram levantados:

-Orientado à pequena e média empresas -Capaz de escalonar localmente a produçâo -Totalmentedistribuido -Configurâvel e facilmente atualizâvel -Portâvel e multi-plataforma -Interface com Sistemas e Aplicaçôes jâ existentes.

-Tolerante à falhas

Projeto Funcional

No Projeto funcional foram desenvolvidas as caracteristicas gerais dos agentes, sendo estes:

Meta-Objeto, Supervisor, Célula e Recursos. Tais agentes interagem com entidades externas (nâo pertencentes à arquitetura) do tipo Ferramentas (de reescalonamento da produçâo ou reestruturaçâo do châo de fâbrica), Base de Dados, Planejamento da Produçâo (Global) e Recursos Reais.

Buscou-se desenvolver uma especificaçâo funcional que pudesse ser mais genérica, isto é capaz de ser reutilizada em problemas semelhantes.

Foi utilizada a metodologia proposta pela linguagem de modelagem UML (Unified Modelling Language) aplicada a problemas de tempo real [ Douglass 98]. Tal metodologia prevê uma combinaçâo entre diferentes técnicas de descriçâo, dentre as quais foram especialmente utilizadas as State Charts [Harel 87] e os diagramas de seqûência.

No entanto a lalta de uma ferramenta automâtica baseada em UML nâo permitiu uma verificaçâo extensiva do Projeto. agentes Célula e Recurso, que sâo pur:" nte reativos, sâo adicionadas mensagens que eqûivalem a respostas à requisiçôes nâo Solir-;l.rtlas i. ' I tr tipo de mensagem foi inspirado na norrna MMS, onde elas sâo usadas para avis*i ,,"r, uùorrência de eventos imprevistos e permitir uma reaçâo râpida do sistema.

É mais facil compreender as mensagens no contexto de funcionamento do sistema, assim no item seguinte serâ mostrado como os objetos se interrelacionam através da troca de mensagens, explicitando-as.

Descriçâo dos Agentes

O agente Supervisor é responsâvel pela execuçâo das ordens de produçâo. Ele pede ao Planejamento da Produçâo, usando solicitaOrdem, um conjunto de ordens de produçâo para 9r serem executadas. Recebe as ordens via mensagem recebeOrdem e passa a gerenciar a execuçâo das mesmas.

Ele pode gerenciar muitas células, apesar de no protôtipo ter sido usada apenas uma, e é responsâvel pela sincronizaçâo entre elas. Ele pode trabalhar de duas formas, a primeira gerenciando a execuçâo de ordens previamente otimizadas (recebidas do Planejamento da produçâo) ou mapeando objetivos de produçâo em novas ordens geradas internamente (esse caso nâo é considerado na atual implementaçâo).

O agente Meta-Objeto age sob demanda do Supervisor que lhe solicita a criaçâo (lôgica) de uma nova célula para a execuçâo de uma certa ordem de produçâo (mensagem criaCelula). Ele cria agentes Célula (de acordo com a estrutura dos produtos), consulta planos de processo na Base de Dados de Produçâo através de solicitaBDP / respostaBDP e instancia os roteiros de fabricaçâo (caminhos) a serem seguidos pela Célula criada. Este agente gera um escalonamento para cada produto, através do uso do môdulo externo Ferramentas, usando as mensagens solicitaFerramenta / respostaFerramenta.

Como ele usa ferramentas externas de escalonamento, ele pode ttatat diferentes tipos de sistemas produtivos, através da seleçâo de algoritmos de escalonamento adequados.

Os agentes Célula recebem do agente Supervisor sua configuraçâo ( que foi criada pelo Meta-Objeto) mensagens comandoProduçâo, sabendo entâo qual produto deverâ ser fabricado e quais recursos serâo utilizados. Os agentes Célula estâo associados conceitualmente com um produto especifico e sâo responsâveis por seu ciclo de fabricaçâo. O conceito de célula aqui considerado é o de célula virtual e nâo de célula fisica, isto significa que qualquer recurso do châo de fiibrica pode ser utilizado pelos agentes Célula.

No final da produçâo do produto requisitado o agente Célula informa o Supervisor através da mensagem infoCélula. Durante a produçâo também podem ser recebidas outras mensagens comandoProduçâo, que conterâo uma ordem para fornecimento do estado da produçâo, neste caso a Célula responde com a mensagem infoCélula contendo o estado requisitado. No caso da ocorrência de um imprevisto na produçâo, a Célula pode informar o Supervisor através de uma mensagem infoNSCel , para que este tome as providências cabiveis enquanto a Célula continua a produzir (se possivel).

Os agentes Recursos sâo ligados aos recursos fisicos, tipicamente mâquinas. Eles guiam a operaçâo dos equipamentos e provêem todas as informaçôes de estado relacionadas à célula virnral (mensagens comandoRecurso, infoRecurso e infoNSRec) . Sua ligaçâo com os recursos fisicos depende do grau de inteligência destes, eles podem ser embutidos nestes equipamentos fisicos ou podem formar uma camada de empacotamento para os recursos fisicos, provendo uma interface para o sistema de controle'

Operaçâo Normal

Durante a operaçâo normal do sistema os agentes Recurso executam as operaçôes, controlando os recursos fisicos disponiveis, e mantém o agente Célula informado através da troca de mensagens comandoRecurso / infoRecurso ou infoNSRec. A Célula informa o Supervisor sobre o fim de cada operaçâo, significando que a quantidade demandada de produto foi produzida (mensagem infoCélula). O Supervisor mantém o controle da produçâo, verificando que o escalonamento estÉ sendo realizado, e informa o estado da produçâo ao môdulo Planejamento da produçâo quando solicitado (mensagens comandoSupervisor / infoSupervisor).

Falha de Mâquina

Quando uma falha ocorre em uma mâquina o agente Recurso que supervisiona aquela mâquina toma ciência do ocorrido. Ele informa ao agente Célula a ocorrência da falha, através da mensagem infoNSRec. O agente Célula, por sua vez, informa o agente Supervisor (mensagem infoNSCel )o qual irâ ativar um processo de reescalonamento dinâmico da produçâo.

O Supervisor requisita ao Meta-Objeto para gerar um novo escalonamento, este baseandose no estado atual da produçâo, requisita ao môdulo externo Ferramentas a execuçâo de um algoritmo adequado de reescalonamento. Apôs receber o novo escalonamento o Meta-Objeto geru a configuraçâo de um novo agente Célula, que serâ responsâvel pela continuaçâo da produçâo do produto que tiver sido afetado pela falha. O Supervisor recebe esta nova configuraçâo ( que contém também o c6digo do novo agente Célula), via mensagem novaCélula.

Ele decide em qual computador disponivel as novas Células serâo ativadas, termina a operaçâo da Célula que estava em falha, usando uma mensagem comandoProduçâo ( parâmetro "terminar", resposta infoCélula) e ativa a nova Célula usando comandoProduçâo com o parâmetro de "iniciar". A ordem de ativaçâo das Células é baseada no novo escalonamento que foi gerado. lJmavez a nova Célula ativada o sistema retorna à operaçâo normal.

Chegada de pedido prioritârio

Uma outra possibilidade de perturbaçâo pode ocorrer quando uma nova ordem (pedido) é inserido no sistema, com prioridade de produçâo.

Neste caso o Supervisor reconhece que a ordem ( obtida via comandoSupervisor) é prioritâria e determina ao Meta-Objeto para reescalonar a produçâo, considerando esta restriçâo.

Neste caso ele nâo interrompe a fabricaçâo do produto corrente, e espera até que ele termine.

Enquanto o produto estâ sendo terminado o Meta-Obj eto realiza o novo escalonamento (como descrito para o caso anterior), que irâ inserir a ordem recebida como a primeira a ser realizada,modificando as outras de acordo com as possibilidades.

Quando a célula informar que o produto estâ terminado ( mensagem infoCélula com parâmetro "fim") o Supervisor irâ ativar a Célula seguinte, que serâ responsâvel por realizar a ordem prioritrâria. A partir dai a operaçâo segue normalmente, de acordo com o novo escalonamento.

Para qualquer um dos casos de operaçâo pode ocolrer que o escalonamento nâo possa ser gerado (pelo môdulo Ferramentas) devido à recursos indisponiveis (mâquinas, matérias primas, etc.), neste caso o Supervisor avisarâ ao Planejamento da Produçâo ( infoSupervisor em resposta ao comandoSupervisor que determinava iniciar a produçâo) para que este corrija os parâmetros necessilrios na BDP e tome outras medidas adequadas.

4.3.4Implementaçâo -Protôtipos dos Agentes

A Figura 4.5 mostra a configuraçâo de teste do sistema. Os agentes bâsicos sâo derivados diretamente da especificaçâo funcional (vide Figura 4.4), eles sâo: Supervisor, Meta-Objeto, Célula e Recurso.

Da mesma especificaçâo funcional, identificou-se as entidades externas Planejamento da Produçâo, Ferramentas, Recursos Reais e Base de Dados de Produçâo -BDP, as quais interagem com os agentes. Os agentes podem estar em um mesmo computador ou espalhados na rede. A arquitetura nâo é rigidamente ligada a uma configuraçâo fisica determinada, no entanto, para fins deste protôtipo, os agentes devem ter conhecimento prévio da existência dos outros ( seus endereços de rede IP).

Encontra-se no Anexo I uma descriçâo de alguns cenârios de uso e diagramas mais detalhados que ilustram a metodologia de projeto.

4.3.4.1O ambiente Industrial emulado pela PIPEFA

A plataforma PIPEFA foi o alvo para a implementaçâo. Ela é usada para fazer experimentos em técnicas de integraçâo e usa aplicativos e componentes comerciais, buscando compatibilidade com o nivel de maturidade tecnolôgica das PMEs, sendo um de seus propôsitos a transferência de tecnologia para estas empresas.

Ela é um cooperaçâo entre quatro instituiçôes:

-Faculdade de Engenharia Mecânica da Unicamp, encalregada do Châo de Fâbrica (Automaçâo e Mecatrônica).

-Instituto Nacional de Tecnologia de Informaçâo -ITI, encarregado da Infra-estrutura de integraçâo, Planejamento da Produçâo e Modelagem de Empresa.

-LIISI do ISMCM -CESTI, Toulon, França, encarregado da Modelagem de Empresa (Sistemas Reativos, Sistemas de trocas de Conhecimentos).

-LGIPM, Universidade de Metz, França, encarregado da Modelagem de Empresas e do desenvolvimento de novas arquiteturas para supervisâo e controle de châo de f,ibrica, em conjunto com o ITI.

A Figura 4.6 apresenta a interaçâo entre os parceiros do projeto PIPEFA. ITI, no lado esquerdo atua como o gerador dos Planos de Produçâo, eles sâo entregues para serem produzidos na célula de manufatura da Faculdade de Engenharia Mecânica da Unicamp, do lado direito.

Estas instituiçôes estâo separadas por uma distância de dez quilômetros e sâo conectadas No caso de falha de recursos fisicos ou da chegada de novos pedidos, a arquitetura detecta os eventos e reconfigura a produçâo. Para fins de sincronizaçâo, é necessârio que SYROCO-2 informe ao sistema de supervisâo que a produçâo foi mudada, jâ que este nâo acessa o BDP, isto é feito com uma mudança nos arquivos de configuraçâo do sistema de supervisâo.

Avaliaçâo da Implementaçâo

Testes foram realizados usando dois computadores, sem usar recursos reais (postos de trabalho). O tempo de resposta foi da ordem de um segundo.

Muitos problemas relacionados à linguagem Java surgiram. A comunicaçâo usando as portas TCP/IP, em Java, mostrou-se restritiva e insuficiente, mesmo sendo fâcil de programar, É necessârio haver suporte para comunicaçâo assincrona baseada em intemrpçôes, nâo disponiveis em Java até o momento.

O esquema global de comunicaçâo foi fortemente baseado em temporizaçôes para verifrcar a chegada de mensagens. Tal esquema nâo é suficientemente confiâvel para esta classe de aplicaçâo.

Outra dificuldade é relacionada com a geraçâo dinâmica de agentes, necessâria durante a reconfiguraçâo do sistema. É necessârio transferir o côdigo do agente e ativâ-lo. Java tem fortes restriçôes de segurança que dificultam este tipo de instanciaçâo, mesmo nâo sendo proibido pela linguagem. Uma segunda contribuiçâo foi no desenvolvimento de uma Metodologia de Projeto para sistemas de supervisâo e controle. Tal metodologia engloba procedimentos clâssicos e atuais, dentro de uma 6tica de projeto de sistemas de tempo real. Ela contribui com a proposiçâo de um balanço entre estes métodos, mostrando a utilidade de se usar diagramas de fluxo de dados em niveis mais altos de abstraçâo, em conjunto com os diagramas de estado (Statecharts) para extrair a dinâmica do sistema, a qual entâo é detalhada de forma complementar em UML e em mâquinas de estado. Verificou-se que esta metodologia se presta bem para fazer uma reengenharia de sistemas existentes, permitindo modelâ-los mesmo que eles nâo sejam "orientados a agentes" ou "orientados a objetos".

A terceira contribuiçâo, ainda incompleta, estâ na disposiçâo de um protôtipo de uma arquitetura particularizada de supervisâo e controle, chamada SYROCO-2, que serâ aplicada à plataforma PIPEFA e permitirâ a realizaçdo de diversas pesquisas, algumas das quais serâo sugeridas ainda neste texto. Este trabalho insere-se num contexto maior que é o de Modelagem de Empresa, que continua a ser desenvolvido no ITI, LGIPM e LIISI, e que potencialmente pode se beneficiar dos resultados a serem obtidos na pesquisa sobres IEI.

Desenvolvimento de algoritmos de escalonamento

Mostrou-se que os algoritmos de escalonamento sâo fornecidos por um m6dulo ou ferramenta externa. Foi desenvolvida uma maneira de "agentificar" este môdulo, para que o mesmo possa comunicar-se com os componentes criados.

Assim serâ possivel, para um mesmo caso industrial, real ou simulado, comparar-se o desempenho de diversos algoritmos, permitindo adquirir conhecimentos sobre quais sâo mais adequados ao problema enfrentado.

t17

Estes algoritmos permitirâo que uma mesma arquitetura ( por exemplo SYROCO-2) possa ser utilizada em uma variedade de casos, através da seleçâo adequada do algoritmo de escalonamento. A seguir, Figura A.2, é apresentado um exemplo de cenârio de falha de um dispositivo, durante a produçâo de um certo produto que fazparte de uma ordem de produçâo em andamento.

l. Recurso em falha sinaliza sua situaçâo à Célula através de uma mensagem nâo solicitada de informaçâo ( isto significa que a Célula nâo precisa ficar monitorando o Recurso, através de seguidas consultas ao seu estado).

Z. Célula informa a ocorrência da pane ao Supervisor, também através de uma mensagem de informaçâo nâo solicitada. Ela fica em um estado de EXCEÇÂO (anteriormente estava em um estado de PRODUÇÂO).

3. Supervisor sabe que serâ necessârio reescalonar a produgâo. Para isto ele solicita MetaObjeto a criaçâo de uma nova Célula, através da mensagem creerCellule.

4. MetaObjeto irâ utilizar uma inteligência externa para fazer o escalonamento, através da requisiçâo de uma ferramenta externa de escalonamento, mensagem sollicitationOutil 5. Môdulo de ferramentas externas irâ realizar o escalonamento, com o algoritmo que estiver programado no momento e irâ devolver o resultado ao Metaobjeto, mensagem reponseOutil.

6. MetaObjeto irâ organizar as informaçôes recebidas na forma de uma configuraçâo de célula virtgal de produçâo, que serâ enviada ao Supervisor, mensagem nouvelleCellule.

7. Supervisor irâ analisar a configuraçâo recebida, no caso ele verifica que a Célula que estâ em exceçâo pode continuar a trabalhar com um novo recurso equivalente, o qual foi atribuido no t34 novo escalonamento. Ele envia entâo um comando de produçâo, com parâmetro de modificar, para a Célula, mensagem ordreProd.

8. Célula envia uma ordem para o Recurso em falha, determinando que ele se termine, mensagem ordreRessource 9. Recurso responde com uma mensagem de informaçâo, confirmando seu término, mensagem infoRessource.

10. A Célula que estava no estado de EXCEÇÂO passa para o estado de PRODUÇÂO e continua a produzir a partir do ponto onde estava, através de uma mensagem ordreRessource enviada ao novo Recurso atribuido.

I 1. Recurso responde que estâ executando a produçâo através de uma mensagem infoRessource.

12. Célula informa ao Supervisor que a produçâo continua. Os agentes que compôem Syroco-2 sâo obtidos através de herança do agente SyrAgent.

Eles possuem protocolos Cliente e Servidor, que sâo obtidos através de herança das classes SSProtocol (Servidor) e SCProtocol (Cliente), é necessâria uma especializaçâo das classes para implementar as diferentes mâquinas de estado associadas a cada protocolo.

Mostrar-se-â, na Figura A.4, um rastreamento das mensagens trocadas para um cenârio especifico de operaçâo. Aparecem em destaque os estados internos dos agentes (referentes aos protocolos utilizados) e os detalhes de nomenclatura de cada protocolo gerado por herança. 

Abstrsct

This work focuses on building architectures for shop floor conhol, aiming at enhancing integration of shop floor to the enterprise. Basic building blocks, called Generic Components, are developed. They can be combined to create conhol architectures. It is possible to define a building sfiategy, using the generic components and a project methodology, that shall be used in each specific industrial case. From successive applications of the technique, architectural patterns may emerge, making possible to compose libraries of shop floor's partial models. The process of elaborating Generic Components and associated methodology, enforced reuse and modularity characteristics, to allow creating such libraries. One practical application, on "Plataforma Integrada de Pesquisa, Ensino e Formaçâo em Automaçâo -PIPEFA", that contains one assembly and disassembly cell, will be presented, illustrating the whole process of architecture development.

Keywords: Automation, Shop Floor Control, Enterprise Integration

Palavras Chave: Automaçdo, Controle de Chdo de Fabrica, Integraçdo de Empresas

  Supervisâo e controle de châo de fâbrica 1.3 Conclusâo Supervisâo e Controle de Châo de Fâbrica 2 Supervisâo e Planejamento da Produçâo 2.1 Arquiteturas para Supervisâo e Controle 2.1.1 Tipos de Produçâo 2.1.2 Tipos de Arquiterura 2.2lntegraçâo das funçôes de Supervisâo e Controle de Châo de Fâbrica.2.2.1 Arquiteturas de Referência

  Bâsicos da Arquitetura 3.3.1 Modelo do Agente 3.3.2 Metodologia de construçâo de aplicaçôes. 3.4 Robustez e flexibilidade da arquitetura 3Anâlise dos Experimentos e dos Resultados

  Figura 2.1: Planejamento da Produçâo Tradicional Figura 2.2: Classificaçâo deDilts et al.

Figura 2. 3 :Figura

 3 Figura 2.3: Modelo de Referência GRAI Figura 2.4: GRAI Grid Figura 2.5: GRAI Net Figura 2.6: Arquitetura PERA Figura 2.7: Arquitetura ARIS Figura 2.8: Cadeia de processos ARIS Figura 2.9: Quadro de Modelagem CIMOSA Figura 2.10: Visâo Geral dos Conceitos CIMOSA Figura 2.11: ComPonentes de GERAM Figura 2.12 Relaçâo Cliente/Servidor no MMS Figura 2.73 : lnfra-Estrutura de lntegraçâo CIM OSA Figura 2.14: EMEIS Figura 2.15: Influências sobre os sistemas multi-agentes' Figura 2.16: Vantagens dos Sistemas Multi-agentes Figura 2.17: Aspectos da Arquitetura dos SMAs Figura 2.18: ComPosiçâo dos SMAs Figura 2.19: Comunicaçâo entre Agentes Figura 2.20: Coordenaçâo/ Negociaçâo entre Agentes iv

É

  Figura 2.1: Planejamento da Produçâo Tradicional

  l3 2.7.2 Tipos de Arquitetura O trabalho de Dilts et al. "The Evolution of Control Architectures Jbr Automation Manufacruring Sltslsrns" [Dilts 91]apresenta e compara diversas arquileturas. criandoum quadro de referência para posicionar arquiteturas exislentes e novas propostas. As arquiteruras espelham os mecanismos de tomada de decisôes. Na Figura 2.2 ê reproduzida a classificaçâo de Dilts er al. Duffie e Prabhu [Duffie 96] apresentam também uma classificaçâo que vai da forma hierârquica à heterârquica, passando por formas oligârquicas e semi-heterârquicas.

Figura 2. 2 :

 2 Figura 2.2: Classificaçâo de Dilts et al. : lDilts 91]

  Figura 2.3, na qual quatro entidades sâo distinguidas: Sistema de Informaçâo, Sistema de Decisâo, Sistema Fisico e Sistema Operante. Tais sistemas sâo decompostos segundo uma hierarquia de niveis, de tal forma que dentro de cada nivel pode-se aplicar recursivamente a decomposiçâo em sistemas informâtico, de decisâo, fisico e operante.

[

  Scheer 92],[Vernadat 97 a].Essa arquitetura conta com o suporte de ferramentas computacionais comercializadas pela empresa IDS Scheer e permitem projetar, avaliar e aplicar processos de negôcio à empresa. ARIS também éutilizada em conjunto com o software R3 da SAP [Scheer 94], fatores que a tornam a arquitetura com o melhor suporte computacional.

  Execuçâo remota de programas Entre os vârios objetos definidos no MMS, para o modelo do VMD, existe o que se chama Invocaçdo de programa, que é o agrupamento de um ou mais dominios na forma de um programa executâvel. Os serviços que sâo oferecidos para o cliente gerenciar estes programas sâo listados a seguir: C r eatePr ogr a mI nv o c ati o n, D e lele Programl nvoc atio n, Slarl, Stop, Resume, Reset, Kill, G etP r o gr a m I nv o c atio nA tlrib utes Acesso às variâveis O objetivo dos serviços de acesso às variâveis do MMS é permitir a leitura e escrita de variâveis contidas em um VMD. Os serviços bâsicos sâo: R e ad, ll/rite, I nfo r matio n Rep ort, Existem serviços complementares para definir caracteristicas das variâveis.

  Figura 2.13: Infra-Estrutura de Integraçâo CIMOSA :[CIMOSA 931

  de Apresentaçâoprovêem as funçôes necessârias para controlar a execuçâo da Funçôes Operacionais pelos recursos da empresa, os quais sâo do tipo mâquinas, pessoas e aplicaçôes. A funcionalidade destes serviços permite:

Figura

  Figura 2.14: EMEIS : [prEItlV 991

  Figura 2.1 (Planejamento da Produçâo Tradicional). Verificouse entâo que o Châo de Fâbrica tem uma interface com os môdulos superiores de planejamento da produçâo, os quais serâo denominados daqui por diante simplesmente de Planejamento da Produçâo. O Châo de Fâbrica recebe do Planejamento da Produçâo os objetivos ou ordens de produçâo e deve, no momento adequado, executar estas ordens, mantendo o Planejamento da Produçâo atualizado sobre o estado atual da produçâo (quantidades, qualidade, problemas etc.). A parcela de inteligência que o Châo de Fâbrica possui em relaçâo ao sistema produtivo pode ser avaliada pelo grau de detalhamento das instruçôes (objetivos ou ordens de produçâo) recebidas do Planejamento da Produçâo. Assim, se forem recebidas ordens detalhadas com todos os passos e tempos, pode-se supor que este Châo de Fâbrica é pouco inteligente (aqui equivalente a pouco autônomo); por outro lado se forem recebidos objetivos de produçâo contendo por exemplo datas limite e quantidades a produzir, sem no entanto haver a fixaçâo dos tempos e dos roteiros, podese supor que o Châo de Fâbrica é capaz de completar o trabalho de escalonar a produçâo, sendo portanto mais inteligente (autônomo).

3.2. 1

 1 Figura 3.1: Relacionamento do Planejamento da Produçâo e Châo de Fâbrica

3. 3

 3 .1.1 Sistema de Comunicaçâo A comunicaçâo entre agentes pressupôe que eles possuam uma linguagem de comunicaçâo em comum (nâo precisa ser comum a todos os agentes mas ao par que estâ em conversaçâo)' O desenvolvimento correto da comunicaçâo depende nâo apenas dos mecanismos fisicos de entrega das mensagens mas também dos mecanismos lôgicos de interpretaçâo das mesmas. A interpretaçâo das mensagens estâ associado à semântica (ou significaçâo) das mesmas. Como jâ foi visto no capitulo anterior (Aspectos relevantes da arquitetura dos SMAs -Comunicaçâo) ainda estâ por ser definida a questâo de padronizaçâo da terminologia ou de ontologias para o gerenciamento da produçâo; devido a este fato deixa-se ao projetista do Sistema de Supervisâo e Controle a especificaçâo consistente da interpretaçâo de sua linguagem de comunicaçâo. Observa-se no entanto que para a comunicaçâo com o châo de fabrica jâ existe o protocolo MMS [MMS 90] o qual serve como referência, num sentido amplo, para a definiçâo das mensagens Para este ambiente. No âmbito dos SMAs, existem trabalhos no sentido de desenvolver uma Linguagem de Comunicaçâo entre Agentes (ACL Agent Communication Language), estes trabalhos sâo na linha de utilizaçâo das linguagens KIF e KQML [Finim 93], existe uma tentativa de padronizaçâo destes esforços por meio da FIPA (Foundation of Intelligent Plrysical Agents htp://www.fipa.org) .

  Figura 3.9: Diagrama de Uso :[Douglass 981 

  Esta arquitetura conta com os agentes: Meta-Objeto, Supervisor, Célula e Recursos. A modificaçâo consiste em incorporar o agente Produto dentro da Célula, isto faz sentido pois células (fisicas) sâo organizadas de acordo com as familias de produtos que elas podem gerar. Tal modelo remete de imediato ao bem conhecido modelo NBS [Mcl-ean 83], facilitando o diâlogo com o meio industrial. Do ponto de vista de desempenho, a eliminaçâo de um nivel de distribuiçâo e os caminhos de comunicaçâo associados, deve levar a uma melhoria global do sistema, quando se consideram sistemas de produçâo organizâveis em células, como aqueles representâveis na PIPEFA. A necessâria reatividade do sistema foi entâo preservada, através da possibilidade de reescalonar localmente a produçâo. 4.1.4 Derivaçâo da Arquitetura Particular A partir da Arquitetura Experimental pode-se derivar a Arquitetura SYROCO-2 (O 2 indica uma modificaçâo da arquitetura original) da seguinte forma: -SYROCO-2 possui dois agentes que fazem interface com o Planejamento da Produçâo, o Supervisor e o Meta Objeto., eles podem ser derivados do tipo Supervisor da Arquitetura ExPerimental.

4. 3

 3 .1 Decisôes Tecnolôgicas. Das fases de Especificaçâo e Projeto pode-se derivar alguns atributos os quais se mapeiam em tecnologias existentes, -Sistema Multi-agente -Usa a linguagem Java. -Interfaceia com outras linguagens. -Orientado à troca de mensagens. -Cliente -Servidor -Especializaçâo através de môdulos externos -Reutiliza o conhecimento existente Para contemplar estes requisitos foi proposto um sistema multi-agentes como soluçâo de implementaçâo. Juntamente com a linguagem Java ele permite satisfazer a esse conjunto de especificaçôes. Exemplos de sistemas aparentados, usando a linguagem Java para suporte de SMAs, sâo: JAFMAS [Chauahan 97], JATLITE I Jatlite 971 e UMASS [Horling 98]. 4.3.1.1 Linguagem de Programaçâo Java foi a linguagem escolhida, devido à suas caracteristicas de legibilidade, portabilidade e ligaçâo em rede. Ela tem também pontos negativos, como por exemplo uma performance inferior quando comparada às linguagens compiladas. Mesmo assim pensa-se que o balanço geral de Java é positivo o que justifica sua seleçâo.

A

  Figura 4.4: Diagrama Geral de Syroco-2

Figura

  Figura 4.5: Prot6tipo dos Agentes

  Figura 4.6: PIPEFA

Figura 4. 7 :

 7 Figura 4.7: Estratégia de Migraçâo

6.1. 5

 5 Figura A.l: Diagrama Geral de Syroco-2

  failure, failResource, failProduct #3 = failProduct, nf, tf #4 : search, (Agenda, Shop, ProcPlan) #5: +, Solution #6 = *, ml, m3, m4, ml l, cellObject #7 : modifu, failProduct, list of resources #8 : stop #9 = *, resState #10 : duration, failProduct, newResource, #ll = +, resState #12 = +, phaseNumber phaseNumr, precResource

Figura 4. 2 :

 2 Figura 4.2: Cenârio de Falha de Equipamento

Figura

  Figura A.3: Diagrama de Classes de Syroco-2

O

  Cliente da Célula recebe a mensagem infoRessource e percebe o problema, tanto pela indicaçâo do parâmetro pane como também por perceber a queda da conexâo com o Recurso (que se terminou, causando uma falha na rede). O Servidor da Célula é informado pelo seu Cliente e entra no estado de EXCEÇÂO, transmitindo a mensagem infoCellule com uma indicaçâo de pane ao Supervisor. O Cliente da Célula é terminado, pois o Recurso ao qual estava conectado jâ nâo existe. O Servidor da Célula foi também terminado (neste caso esta Célula especifica nâo aceita a possibilidade de modificar a produçâo). O Supervisor (nâo indicado no rastreamento), demanda o escalonamento da produçâo. Apôs receber a resposta do MetaObjeto irâ criar uma nova Célula para continuar a produçâo. Esta nova Célula foi ativada na mesma mâquina na qual se encontrava a outra e é criada a partir da chegada da mensagem ordreProd (Fabriquer), com as portas 4444 1058. A nova Célula ativa um Cliente (SCCRProtocol 1059 4445), para se comunicar com o novo Recurso, o qual serâ criado na mesma mâquina onde se encontrava o anterior. O Servidor da Célula entra entâo no estado de PRODUÇÂO, continuando a produzir (possivelmente a partir do 139 ponto onde estava anteriormente, isto depende das decisôes da ferramenta extema de escalonamento). A troca de mensagens continua normalmente até o fim da produçâo, quando os agentes envolvidos sâo desabilitados. r40 Architecture de pilotage d'atelier de production à base de composants génériques Mauro FERREIM KOYAMA Résumé Ce travail de thèse consiste à mettre en place une architecture pour le pilotage d'ateliers, dans le but de parvenir à I'intégration . Les blocs de construction élémentaires, appelés Composants Génériques aont été développés. Ils peuvent être combinés pour créer des architectures de pilotage. Il est possible de définir une stratégie de construction, utilisant des composants génériques et une méthodologie de projet qui puisse ête utilisée dans chaque cas industriel spécifique. En répétant plusieurs fois cette technique, des patrons architecturaux peuvent émergés, rendant possible l'élaboration de librairies de modèles partiels d'ateliers. Le processus d'élaboration de composants génériques et de leur méthodologie associée renforce la réutilisation des caractéristiques modulaires, pour permettre la mise en place de telles librairies. Une application pratique sur "Plataforma Integrada de Pesquisa, Ensino e Formaçâo em Automaçâo -PIPEFA" qui comporte une cellule d'assemblage et = de désassemblage est présentée, pour illustrer le processus du développement de I'architecture dans son ensemble. Mots-clés : Automatisation, Pilotage d'Ateliers, Intégration d'Entreprise

  Arquiteturas para Supervisâo e Controle de Châo de Fâbrica e as Arquiteturas de

	Interessa em especial investigar dois assuntos relacionados com estas arquiteturas e que
	serâo relevantes para este trabalho: Suporte para Integraçâo e Sistemas Inteligentes Distribuidos.
	O primeiro jâ foi referenciado quando foram distinguidos quais eram os suportes para
	integraçâo oferecidos pelas Arquiteturas de Referência, este assunto serâ detalhado agora. O
	segundo aparece claramente como alternativa para a implementaçâo de Infra-estruturas de
	lntegraçâo, em especial os Sistemas Multi-agentes, que serâo objeto deste estudo.
	2.3.1 Suporte para a lntegraçâo
	O termo Infra-estrutura de Integraçâo, no sentido em que é proposto por CIMOSA, tornou-
	se corrente. Existe uma norrna de comunicaçâo industrial, chamada MMS (Manufacturing
	Message Specification -Especificaçâo de Mensagens para a Manufatura) [MMS 90], a qual tem
	uma grande influência quando o assunto é comunicaçâo em sistemas produtivos. Devido à essa
	Referência para Integraçâo de Empresas sâo o resultado de um longo processo de
	amadurecimento de conhecimentos, de métodos e de tecnologias. Hâ um carâter multidisciplinar
	nessa evoluçâo, pode-se visualizar diferentes contribuiçôes, vindas de âreas como Gestâo de
	Empresas, Sistemas de lnformaçâo, Sistemas de Produçâo e outras.
	3l

importância far-se-â um breve relato do que é MMS e posteriormente mostrar-se-âo seus reflexos nas infra-estrufuras de integraçâo, quando forem apresentadas, e na proposta desta tese. 2.3.1.1MMS -Especiticaçâo de Mensagens para a Manufatura O Protocolo de Especificaçâo de Mensagens para a Manufatura (MMS Manufacturing Message Specification) é uma norrna internacional padronizada pela ISO (ISO 9506) [MMS 90]. Seu propôsito é fornecer um conjunto de mensagens que permitam aos dispositivos de manufafura comunicar-se de maneira cooperativa. A arquitetura MAP [MAP 88] utiliza na camada de aplicaçâo o MMS , o qual foi considerado adequado às aplicaçôes de automaçâo industrial. Os serviços MMS sâo extremamente adequados à manufatura, de tal forma que a despeito do projeto MAP nâo ter conseguido aceitaçâo irrestrita, o MMS hoje é utilizado em diversos paises. Os esforços de padronizaçào para o Barramento de Campo (FieldBus), na forma de suas propostas regionais FIP [AFN 90], PROFIBUS [Gôddertz 90] e ISA SP50 utilizam subconjuntos do MMS para definir a camada de aplicaçâo [Pleineveaux 94]. O MMS define com seus serviços um conjunto geral de mensagens para a manufatura; dada a diversidade de dispositivos de châo de fâbrica existentes a ISO criou um conjunto complementar de protocolos, chamados de padrôes associados (Companion Standards) os quais especializam os serviços do MMS para dispositivos especificos como Robôs ou Controladores Programâveis. Alguns autores sâo fontes alternativas de consulta, descrevendo o MMS de maneira menos formal e mais condensada que na norrna. Entre estes pode-se citar: Brill lBrill 91] e Hoekstra [Hoekstra 90]. Na descriçâo da estrutura do MMS a ISO utilizou duas técnicas que atualmente estâo bastante disseminadas , uso da arquitetura Cliente / Servidor e Modelagem por Objetos. Na Arquitetura Cliente / Servidor um dos lados em comunicaçâo faz o papel de Servidor, ou seja o elemento que atende as requisiçôes de serviços, o outro lado é o Cliente, aquele que solicita a execuçâo dos serviços. Serviços sâo funçôes que o MMS disponibilizapara o usuârio. O Cliente representa o dispositivo de manufatura que detém o controle, o Servidor é o dispositivo sob controle [Hoekstra 90]. A Modelagem por Objetos consiste em agrupar os recursos ou funcionalidades dispositivo de manufatura em entidades, chamadas objetos, pelas quais estes recursos funcionalidades serâo acessados por outros dispositivos ou programas de aplicaçâo.

Figura 2.12: Relaçâo Cliente/Servidor no MMS Os serviços MMS sâo modelados para ler e modificar os atributos dos objetos [Hoekstra 90], eles sâo codificados em mensagens MMS que viajam pela rede de dispositivos. do ou Os objetos MMS podem ser manipulados pelos serviços, as operaçôes normalmente possiveis sâo: criar, apagar, modificar ou obter os atributos de um objeto; existem algumas poucas exceçôes, como por exemplo o objeto VMD (Virtual Manufocturing Devicevide item seguinte), que nâo pode ser criado ou apagado. No modelo do MMS o VMD estâ colocado como um Servidor, de acordo com aFiguta2.l2. O Servidor do MMS tem seu comportamento externo modelado pelo objeto VMD (Virtual Manufacturing Device). O VMD toma disponivel para controle e monitoraçâo os recursos e funcionalidade associados ao dispositivo real de manufatura. Os dispositivos reais sâo do tipo Controladores Programâveis (CP), Mâquinas de Comando Numérico (CNC), Robôs e outros; para estes três inicialmente citados existem norrnas complementares ao MMS, chamados de padrôes associados ICPM 89], IROB 90], [CNC 9l] as quais detalham o MMS para o dispositivo especifico relativo à norma.

  ambiente, sendo que os agentes sentem o que acontece e agem sobre este ambiente (através de sensores e atuadores) nâo se comunicando diretamente; a comunicaçâo através de partilha de dados, os chamados "Sistemas de Quadro Negro", onde a comunicaçâo se dâ pela leitura e escrita em uma ârea de dados comum e finalmente pode-se apontar a comunicaçào baseada em mensagens.Um sistema que utilize troca de mensagens necessariamente necessitarâ especificar um protocolo e uma linguagem de comunicaçâo, os quais definem as regps que regem a comunicaçâo e o conjunto de mensagens. Para isso é necessârio considerar os aspectos de estrutura sintâtica das mensagens e também os aspectos semânticos de interpretaçâo das mesmas. Knowtedge euery and Manipulation Language)[Finim 93]. O significado das mensagens sendo trocadas depende do dominio do conhecimento, os mesmos termos podem ter significados diferentes quando sâo usados em âreas / contextos diferentes [Peng 98]' Modelagem dos SMAs estâ relacionada ao paradigma de construçâo dos agentes utilizados. Wooldridge e Jennings ['Wooldridge 94), quando falam de "arquiteturas de agentes", classificam-nas em três classes: Deliberativas, Reativas e Hibridas. De acordo com Vernadat o Projeto PACT é "inovador no sentido em que ele coloca menos ênfase na troca de mensagens e mais na partilha e troca de conhecimentos..." [Vernadat 96].Projeto HOLOS da Universidade Nova de Lisboa, Portugal [Rabelo 95], cuja originalidade é apresentar uma infra-estrutura baseada em agentes parcialmente inspirada na Arquitetura CIMOSA[Rabelo 94a]. Noçâo de Componentes Genéricos As Arquiteturas de Referência CIMOSA e GERAM explicitam em seus quadros de modelagem (Figura 2.9 Quadro de Modelagem CIMOSA) a necessidade de reutilizar resultados e modelos. O eixo de Instanciaçâo de Blocos Funcionais ilustra como isto é feito: parte-se de construtores genéricos, adequados à cada uma das Vistas (Funçâo, Informaçâo, Recursos e

	influências. 2.3.3.4 Aplicaçôes de SMAs modulares 3.1	
	2.3.3.1 O que é um Agente? composiçâo descentralizados / distribuidos modificâveis suportam sistemas comPlexos suportam especifi caçôes incompletas pré-ajustada A aplicaçâo das técnicas de Inteligência Artificial na Manufatura inicialmente centrou-se configuraçâo dinâmica no uso de Sistemas Peritos (Expert Systems). Heragu e Kusiak [Heragu 87] descrevem a estrutura
	Esta é uma questâo tâo polêmica quanto aquela da definiçâo do termo "Inteligência" na ârea de Inteligência Artificial. Segundo Jennings, Sycara e rWooldridge [Jennings 98] este nâo deve ser um grande obstâculo ao progresso na ârea jâ que a Inteligência Artificial desenvolveu-se mesmo sem uma definiçâo precisa do que é Inteligência' Franklin e Graesser [Franklin 96] descrevem vârias definiçôes para qualificar Agentes e Agência e propôem uma taxinomia para os Agentes Autônomos. É desnecessârio polemizar sobre r ealizam tarefas delegadas melhoram as interfaces com usuârios Figura 2.16: Vantagens dos Sistemas Multi-agentes Os SMAs sâo naturalmente distribuidos e essa caracteristica facilita a modularizaçào. A sua autonomia em conjunto com a distribuiçâo permite que lidem com sistemas complexos e eles podem ser atualizados para atender aos novos requisitos de um sistema mutâvel. comunicaçâo coordenaçâo / negociaçâo modelagem Figura 2.17: Aspectos da Arquitetura dos SMAs para formalizar os conhecimentos dentro de uma certa ârea do conhecimento podem ser definidas ontologias [Gruber 93], [Vernadat 96]. No dominio de integraçâo de empresas foram realizados alguns trabalhos [Fox g2], [Uschold 98] mas ainda resta muito por fazer, especialmente quanto à definiçâo das estruturas que representem o châo de fâbrica. A Coordenaçâo , Figura 2.20, estâ relacionada com o comportamento social dos agentes, As Arquiteturas Deliberativas sâo oriundas do enfoque clâssico de Inteligência Artificial, que busca uma representaçâo lôgica do problema em mâos. Descobriu-se que a aplicaçâo diretas das teorias lôgicas nâo era factivel para o caso geral, foram entâo desenvolvidas variantes como por exemplo os Sistemas Baseados em Planejamento e os Sistemas BDI (Belief, Desire, Intention). Os Sistemas Baseados em Planejamento procuram propor alguma forma de decomposiçâo dos objetivos gerais dos sistemas em objetivos locais dos agentes os quais devem seguir determinados planos de açâo. dos sistemas peritos e abordam três aspectos relevantes para os mesmos: Representaçâo de AARIA (Autonomous Agents for Rock Island Arsenal) [Baker 97], [Parunak 97f, é um Da Universidade de Calgary, Canadâ, as contribuiçôes sâo através do "Ambiente para Conhecimento, Aquisiçâo de Conhecimento e Estratégia de Inferência. Eles resenham uma série SMA pa17_ a manufatura discreta de componentes. AARIA combina agentes do tipo Recursos Projeto Concorrente baseado em Agentes" ABCDE [Balasubramaniam 95] e através de Capftulo 3 de sistemas que foram aplicados aos seguintes problemas: Projeto de Componentes, (pessoas, mâquinas, facilidades/, Tipos de Componentes e Processos Unitârios (conceituado uma resenha sobre o estado da arte dos SMAs aplicados à Manufatura [Shen 99]. planejamento de Processos, Seleçâo de Equipamentos, Estruturaçâo Fisica (Layout) de Fâbrica. Ainda Kusiak [Kusiak 88] apresenta mais quatro classes de problemas de manufatura que arquitetura. Flexiveis de Manufatura. adequados às novas estruturas de produçâo estâ sendo desenvolvido conjuntamente com a linguagem para comunicaçâo de agentes KQML [Finin 93]. Seqtienciamento de trajetos de corte, Tecnologia de Grupo e Escalonamento de Sistemas simulaçâo de fâbricas, outro aspecto é que um estudo sobre algoritmos de escalonamento conexâo entre o Planejamento da Produçâo e a execuçâo deste planejamento, além da também se beneficiaram desses sistemas: Seleçâo de trajeto de corte de ferramenta, como sendo o conhecimento de como combinar recursos e componentes para fazer outros componentes). Um aspecto interessante de AARIA é que ele estâ sendo projetado para facilitar a Da Universidade de Maryland veio o Projeto CIIMPLEX [Peng 98] que busca fazer a uma Arquitetura Experimental baseada em componentes
		,a	homogênea
	composiçâo	<-	heterogênea diretivas
	Resoluçâo Distribuida de Problemas Sistemas Multi-agentes conteûdo ./ ArtificialDistribuida \ lnteligência votaçâo \ "r.oo comunicaçâ"( Atos discursivos
			ambiente
	Programaçâo Orientada a Objeto Figura 2.18: Composiçâo dos SMAs suporte partilha de dados mensagens Figura 2.202 Coordenaçâo/ Negociaçâo entre Agentes
	Projeto de Interface Homem Computador Figura 2.15: Influências sobre os sistemas multi-agentes. Adaptado de [Jennings 98] ârea de Trabalho Cooperativo Suportado por Computador (CSCW). A Figura 2.15 ilustra estas em [Wooldridge 94]. apresentar a lista da Figura 2.16 Esta opiniâo também é compartilhada por Gasser [Briot 98], que adiciona a influência da I protocolos / linguagens sobre suas prôprias açôes e estados internos"' 2.3.3.2 Vantagens dos Sistemas Multi-agentes Bradshaw [Bradshaw 97], apresenta uma introduçâo aos Agentes de Software, onde destaca algumas vantagens dos SMAs, combinando-se com a discussâo de Parunak [Parunak 98] pode-se A Comunicaçâo (Figura 2.19) pode ser classificada pelo seu conteirdo e pelo suporte que a permite (ou forma de comunicaçâo). Quanto ao conterido ela pode ser baseada em diretivas (ou ordens) que determinam o que deve ser feito; por alguma forma de votaçâo ou pela emissâo de ^\ semântica sintaxe Figura 2.19: Comunicaçâo entre Agentes A questâo da cooperaçâo e coordenaçâo requer que os agentes sejam capazes de comunicar-se, através de umas das formas descritas anteriormente. O relacionamento entre eles pode ser do tipo cooperativo ou competitivo, em ambos os casos serâ necessârio o uso de um protocolo de comunicaçâo, que terâ também a funçâo de coordenaçâo/ negociaçâo. O "Protocolo As Arquiteturas Hibridas contém caracteristicas de deliberaçâo e reaçâo, buscando obter para articular estes componentes e formar uma Arquitetura Experimental a partir da qual um melhor desempenho do sistema. Usualmente os componentes reativos estâo mais prôximos do O Projeto PACT [Tenenbaum 92) é uma federaçâo de agentes que permite a disposiçâo de podem ser derivadas diversas ouffas, mais especificas e adaptadas aos problemas singulares que Da Universidade de Massachusetts vem a arquitetura JAF [Horling 98] baseada em sistema fisico. aplicativos (ferramentas) na Internet. PACT utiliza o conceito de "Facilitador", este é um agente componentes Java com aplicaçâo no projeto de casa inteligente IHOME [Lesser 99]. sejam colocados ao projetista, foi desenvolvida também uma Metodologia de Projeto, calcada nas "atos discursivos" (Speech Acts) lCohen 95] em decorrência dos quais uma atividade desejada pode ou nâo ser realizada, o que os diferencia das diretivas. Michael Wooldridge, em sua tese de de Rede de Contrato s" (Contract-Net Protocof [Smith 80] , em suas variantes , é um dois mais Vârios exemplos das arquiteturas Deliberativa, Reativa e Hibrida podem ser encontrados especial, através do qual a comunicaçâo entre os demais agentes é realizada (os outros agentes técnicas mais recentes de desenvolvimento de progtamas'
			54

Jennings et al.

[Jennings 98

], posicionam os SMAs dentro da Inteligência Artificial Distribuida, em conjunto com os sistemas para Resoluçâo Distribuida de Problemas. Ao mesmo tempo apontam as âreas de programaçâo Orientada a objeto e Projeto de Interface Homem Computador como tendo influência no desenvolvimento dos SMAs. o tema, partir-se-â de uma definiçâo geral de agente pararealizar este trabalho.

Segundo o "Dicionârio da Lingua Portuguesa"

[Ferreira 1985

], agente é "aquele que trata de negôcio por conta alheia", na quarta acepçâo apresentada para o termo. É interessante observar que na lingua inglesa esta acepçâo â a mais corrente, conforme vê-se em: "A person who acts for, or manages the affairs of, other people in business, politics, etc." apresentada pelo "Oxford Advanced Learner's Dictionary" (oxford university Press 1989). Katia Sycara et al. [Sycara 96J, dizem que "Agentes Inteligentes (de Software) sdo programas que podem agir por conta de seus usuârios...", Charles Petrie [Petrie 96], argumenta que alguns consideram Agentes como sinônimo de "Agentes Autônomos" e que a caracteristica de autonomia é relevante para definir Agentes' para Jennnings, Sycara e Wooldridge [Jennings 98], autonomia significa que "o sistema deve ser capazde agir sem a intervençâo direta humana (ou outros agentes) e devem ter controle Eles podem operar mesmo com especificaçôes incompletas e apresentam uma capacidade de escalabilidade e evoluçâo. Eles melhoram as interfaces com os humanos, realizando automaticamente tarefas que lhes sejam delegadas. 2.3.3.3 Aspectos relevantes da arquitetura de SMAs Apôs uma revisâo da literatura que incluiu entre outros [Parunak 98], [Bradshaw 97], [Jennings 98], [Genereseth 94], [Doran 96], fNwana96f, [Wooldridge 94] buscou-se definir um subconjunto de aspectos dos SMAs, que fossem relevantes para o seu projeto e construçâo, a tônica desta classificaçâo é dada por Parunak [Parunak 98]. Na Figura 2.17 apresentam-se os cinco aspectos bâsicos sobre os quais ocorrerâ a discussâo. A Configuraçâo de um SMA define uma topologia [Parunak 98], indicando como os agentes estâo arranjados uns em relaçâo aos outros. Esta Configuraçâo pode ser estâtica ou dinâmica, neste riltimo caso agentes podem ser adicionados ou retirados do sistema juntamente com suas conexôes com os outros agentes. A Composiçâo (Figura 2.18) indica se os agentes sâo uniformes ou nâo e qual é o seu escopo de atuaçâo. Os agentes podem ser de um mesmo tipo, o que caracteriza um sistema homogêneo ou de tipos diferentes, caracterizando um sistema heterogêneo. doutorado [Wooldridgeg2], fornece uma descriçâo formal para os "atos discursivos" e analisa suas diversas variantes. Em relaçâo ao suporte que permite a comunicaçâo pode-se distinguir a comunicaçâo que usa o prôprio Genereseth e Ketchpel [Genereseth 94] levantam três questôes importantes sobre o desenvolvimento de SMAs: "Qual é uma linguagem apropriada de comunicaçâo para agentes? Como construir agentes capazes de se comunicar com essa lingUagem? Qual arquitetura de comunicaçâo conduz à cooperaçâo?" A resposta sugerida por eles passa por uma linguagem de estruturaçâo do conhecimento chamada KIF (Knowledge Interchange Format) que serve para definir os elementos de comunicaçâo (vocabulârio) os quais sâo trabalhados por uma linguagem chamada KQML (isto é com as relaçôes que sâo desenvolvidas entre eles para atingir os objetivos do sistema. É possivel caracteizâ-la segundo duas visôes, de acordo com o tipo de coordenaçâo, que pode ser baseada na cooperaçâo ou competiçâo entre os agentes, ou de acordo com a estrutura do sistema, que pode ser hierârquica ou heterârquica. As definiçôes de hierarquia e heterarquia apresentadas no item 2.l.2Tipos de Arquitetura, sâo extensiveis aos SMAs. largamente utilizados para coordenaçâo dos SMAs. Parunak [Parunak 98] argumenta que protocolos de negociaçâo (do tipo Rede de Contratos) possuem um conjunto fixo de opçôes e que protocolos baseados em "Atos Discursivos" (Speech Acts) permitem maior generalidade. A Os sistemas BDI procuram atribuir "atitudes mentais" [Rao 95] aos agentes. BDI ("Crença, Desejo e Intençâo") para seus autores, Rao e Georgeff [Rao 95] estâo associados aos aspectos informacionais, motivacionais e deliberativos do sistema. Para Parunak [Parunak 98], "crenças" sâo modelos do mundo em seu estado atual; "desejos e intençôes" têm a ver com o estado futuro para o qual se pretende conduzir o sistema. As Arquiteturas Reativas sâo aquelas que nâo incorporam nenhum tipo de modelo simbôlico de mundo e nâo usam nenhum raciocinio simbôlico complexo [Wooldridge 94]. Os primeiros trabalhos nessa ârea foram realizados por Rodney Brooks do MIT , o qual desenvolveu o conceito de "subsumption architecture" [Brooks 86], [Brooks 89]. Brooks desenvolveu um modelo em camadas, em que cada camada é capaz de realizar uma certa funcionalidade e pode beneficiar-se das outras camadas para atingir seus prop6sitos. Ele demonstrou sua arquitetura utilizando robôs que realizam açôes autônomas. Um histôrico da evoluçâo dos Sistemas Peritos é apresentado em [Gaines 88]. Muitos dos conceitos aplicados ao atuais SMAs começaram a ser pesquisados nessa época (década de 80), por exemplo [Yang 85] apresenta um estudo que se centra nos aspectos de comunicaçâo e controle dos Sistemas de Inteligência Artificial Distribuîda. Nesta mesma época começam a emergir os SMAs com aplicaçôes de controle. Dois exemplos, o DVMT (Distributed Vehicle Monitoring Testbed) e o YAMS (Yet Another Manufacturing System) sâo apresentados em [Parunak 88].

YAMS parte de uma estrutura hierârquica de controle, baseada no modelo NBS, e define seus agentes de acordo com os niveis da mesma. Utiliza um esquema de negociaçâo entre os agentes baseado na Rede de Contratos

[Smith 80

], cada agente que compôe a arquitetura pode pertencer a três classes: Gerente, que identifica a tarefa a ser realizada e a atribui a outro agente para execuçâo; Ofertadores, que ofertam-se para realizar a tarefa e Contratadores, os quais sâo Ofertadores bem sucedidos, isto é aqueles cuja oferta foi aceita pelo Gerente. nâo comunicam-se diretamente). PACT utiliza a linguagem de representaçâo de conhecimento KIF, o protocolo de comunicaçâo KQML e ontologias desenvolvidas no projeto associado 5l SHADE (Shared Dependency Engineering) e foi aplicado a um sistema demonstrativo de projeto de manipulador robôtico. Diversos outros sistemas, de interesse histôrico e/ ou com aplicaçôes industriais, foram resenhados em [Parunak 98] e [Shen 99]. Outros trabalhos apresentam os SMAs em geral, por exemplo fNwana 96] e [fVooldridge 94]. Universidades e Centros de Pesquisa em todo o mundo vêm desenvolvendo pesquisas na ârea de SMAs e assuntos relacionados. pode-se citar o Projeto Aglets da IBM Japâo, relacionado aos agentes môveis [Oshima 98] baseados em Java. Também sâo baseados em Java o Projeto JATLite, desenvolvido na Universidade de Stanford [Jeon 00], [Petrie 96] e o Projeto JAFMAS [Chauhan 97] da Universidade de Cincinnati ambos nos Estados Unidos. Da Universidade de Toronto, Canadâ, destacam-se os trabalhos sobre Modelagem de Empresa (projeto TOVE) [Fox 92], linguagem COOL para coordenaçâo de sistemas Multiagentes [Barbuceanu 96a] e ambiente para construçâo de agentes ABS [Barbuceanu 96b]. Especificamente considerando a problemâtica dos sistemas de produçâo pode-se apontar: Projeto CIM-BIOSYS da Universidade de Loughborough, Inglaterra [Aguiar 94) e o A Universidade Catôlica de Louvain, Bélgica, tem grande contribuiçâo em trabalhos sobre Sistemas Holônicos [Brussel95], [Brussel 98] e aplicaçâo dos seus conceitos no Projeto MASCADA no qual um dos prop6sitos é "desenvolver um sistema de controle da manufatura baseado em agentes e uma metodologia de projeto ..." [Brtickner 98]. A Universidade de Aix-Marselha, França, desenvolveu o Projeto D-CIM [Spinosa 97] e em conjunto com a Universidade Laval, Canadâ, estâ desenvolvendo o Projeto NETMAN [Cloutier 99], [Lyonnais 99] para integraçâo de empresas suportada por SMAs. -A Universidade de Metz, França, desenvolveu o Projeto SIROCO [Anciaux 97], [Roy 98] que serâ objeto de um maior detalhamento no Capitulo 4 desta tese. Listam-se apenas as contribuiçôes mais relevantes para os objetivos deste trabalho, especialmente aquelas que têm demonstrado uma maior persistência na literatura e que se apresentaram de forma mais consistente. No capitulo anterior apresentou-se a problemâtica das Arquiteturas para Supervisâo e Controle do Châo de Fâbrica, sua inserçâo dentro das Arquiteturas de Referência para Sistemas de Manufatura e as disciplinas relacionadas às questôes de operacionalizaçdo destas arquiteturas, as infra-estruturas de integraçâo (IEI), o protocolo de comunicaçâo industrial MMS e os Sistemas Multi-Agentes (SMA).

Neste capitulo serâ mostrado como os conceitos utilizados nas Arquiteturas de Referência podem ser aproveitados na geraçâo de uma Arquitetura Genérica para Supervisâo e Controle, desenvolvida a partir do conceito de componentes Genéricos.

Como foi dito, o problema de supervisâo e controle da produçâo pode ser atacado de diversas formas, podem ser utilizadas por exemplo soluçôes hierârquicas ou heterârquicas; reativas ou reflexivas ou hibridas; baseadas em modelos ou"ad hoc".Devido à essa gama de possibilidades julgou-se mais prudente envidar esforços no sentido de desenvolver componentes bâsicos que pudessem ser usados independentemente da estrutura funcional (hierârquica ou heterârquica) e do nivel de inteligência / independência delegado à arquitetura.

  feita ainda uma distinçâo entre os parâmetros do serviço para o caso de uma requisiçâo ou de uma resposta. A requisiçâo é feita por um Cliente ao Servidor, a resposta é gerada pelo Servidor com destino ao Cliente. Esta estruturaçâo é a utilizada na norma MMS.

	diagramas, até chegar ao nivel de Serâ utilizado este ciclo de vida clâssico, considerando a possibilidade de desenvolver 3.3.2.2 Projeto Fu ncional
	prot6tipos funcionais, os quais permitem validar os requisitos dos usuârios. Tempo Real [V/ard 85].
	Comporta as fases de definiçâo estrutural dos objetos e seu comportamento de acordo com
	A visâo sintâtica relaciona-se com a definiçâo "gramatical" dos termos usados na comunicaçâo e com o seu encadeamento dentro de uma mensagem. A Infra-estrufura de Nâo pretende-se neste instante propor um conjunto de mensagens, pois o mesmo seria 3.3.2 Metodologia de construçâo de aplicaçôes. Serâo descritas as etapas de Especificaçâo de Requisitos e Projeto Funcional, as demais etapas sâo mais dependentes do problema atacado e dos recursos tecnolôgicos disponiveis e nâo Como saida desta fase existirâ uma Especificaçâo de Requisitos, que conterâ uma o proposto em [Douglass 98]. Aqui cabe observar que, como os SMAs nâo sâo Sistemas explicaçâo geral do comportamento do sistema em relaçâo às entidades extemas e o conjunto de Orientados a Objetos, mesmo se possam ser construidos usando estes riltimos, necessitam de uma
	Integraçâo CIMOSA e o protocolo MMS aderem aos formatos e métodos de descriçâo da ISO, julgou-se adequado este procedimento e ele serâ utilizado quando possivel. A estrutura sintâtica proposta para as mensagens é mostrada na Figura 3.6: destino M especulativo e incompleto, no capitulo seguinte mostrar-se-â um exemplo de aplicaçâo dos Componentes Genéricos e da Arquitetura Experimental e para este caso desenvolver-se-â um MMS, com os serviços como: Status,Identifu, Read, Wrile, Start, Slop, Resume, Reset, Kill, seria Existe uma diversidade de métodos para a construçâo de aplicaçôes, do ponto de vista da Figura 3.8: interface com os elementos fisicos do châo de fâbrica, um conjunto de mensagens derivado do especifico. proposta por Ward e Mellor [V/ard 85] e Hatley e Phirbai [Hatley 88], a qual é mostrada na conjunto de mensagens seguindo a estruturaçâo proposta. Observa-se porém que, para o caso da Experimental para atender aos requisitos de um sistema de supervisâo e controle da produçâo para documentar a composiçâo dos dados (entradas e saidas) utilizar-se-â a estruturaçâo etapas serâo exemplificadas. Uma aplicaçâo, para fins desta discussâo, é a adaptaçâo e extensâo da Arquitetura serâo descritas nesse capitulo. No capitulo seguinte serâ apresentada uma aplicaçâo onde as outra mensagens, eventos e fluxos fisicos ou lôgicos trocados com estas entidades. maior ênfase na descriçâo da troca de mensagens entre seus componentes.
	fonte evidentemente adequado (vide 2.2.1.2 MMS -Especificaçâo de Mensagens para a Manufatura). M Engenharia de Software; Pressman no Capitulo I de seu livro [Pressman 92] mostra seu conceito Simbolo Significado Descriçâo
	idMensagem o elemento da esquerda é composto dos elementos da M 3.3.1.4 Composiçâo, Configuraçâo e Coordenaçâo composto de Doc. Implementaçâo direita
	servlço Quanto à Composiçâo a Arquitetura Experimental proposta é um sistema heterogêneo; M Manual do Sistema -r em conjunto com conecta os elementos de um grupo nâo ordenado
	{}	iteraçôes de	ConteudoMens. o a expressâo contida em M{exp} N aparece um minimo de M vezes e um mâximo de N vezes. A ausência de M ou N
			indica o caso indefinido.
	il1	Figura 3.6: Estrutura das Mensagens selecionar um de seleçâo entre um ou mais elementos separados pela barra vertical
	M significa que o campo é obrigatôrio (mandatory) 0 opcional indica uma expressâo opcional, eqûivale a {exp } I
	O significa que o campo é opcional It ll literal os elementos devem ser considerados literalmente
		Figura 3.7: Ciclo de Vida de Projeto
	destino r* :1.	indica o objeto que recebe a mensagem. comentârio
	fonte Em [Douglass 98] o ciclo de vida de desenvolvimento de aplicaçôes UML contém as fases indica o objeto que envia a mensagem.
	idMensagem identificadordamensagem de: Especificaçâo de Requisitos, Definiçâo de Estrutura e Comportamento dos Objetos e Projeto 3.3.2.1 Especificaçâo de Requisitos
	serviço conteudoMens contém os parâmetros complementares. indica aaçào que deve ser executada no destino. do sistema. Em relaçâo à Figura3.7, a qual mostra o ciclo de vida tradicional [Pressman 92] (estendido com a fase de Projeto Detalhado) pode-se fazer o seguinte mapeamento (apenas Nesta fase a questâo bâsica é responder "o que" deve ser feito; a partir do problema Figura 3.8: Composiçâo dos Dados
	O campo conteudoMens pode ser descrito usando o mesmo formalismo para mostrar quais sâo os seus componentes, se eles sâo obrigatôrios, opcionais ou uma seleçâo entre parâmetros, e conceitual): Especificaçâo de Requisitos idêntica à de Douglass, Projeto Funcional engloba a analisado deve-se buscar definir as entradas e saidas do sistema. Em UML é proposto o uso de No item Metodologia de construçâo de aplicaçôes, vê-se que é possivel descrever a definiçâo estrutural e comportamental dos objetos, Projeto Detalhado idêntica ao projeto de um diagrama de contexto em que sâo representados o sistema sendo modelado e as entidades coordenaçâo entre os agentes, no nivel mais elevado, através do uso de Diagramas de Estado sistema de Douglass. externas com as quais ele se relaciona (através de fluxos fisicos e lôgicos). Esta fase tem uma
	seus tipos de dados.	
			70

visâo semântica explicita o significado dos termos utilizados neste sistema mensagens, assim esta visâo estâ relacionada às ontologias para os diversos dominios de do conhecimento. Conforme explicado na introduçâo (item 3.3.1) o estado atual do desenvolvimento na ârea nâo permite aderir a padrôes. É existem duas classes de agentes bem definidos, a classe Supervisor e a classe Recursos. a classe Opcional deve ser criada de acordo com o problema especifico sendo resolvido, utilizando elementos do Componente Genérico e possivelmente das outras classes. Quanto à configuraçâo ela pode ser dinâmica, os agentes podem ser criados e terminados em tempo de execuçâo.

Quanto à Coordenaçâo dos agentes ela é feita através da troca de mensagens. Em um primeiro momento parece adequado o uso de protocolos imperativos que conterâo ordens. Essa escolha permite tornar compativel a arquitetura proposta com as estruturas jâ existentes no châo de fâbrica e com os protocolos utilizados, inclusive o MMS. Nâo hâ qualquer impedimento ao uso de protocolos mais sofisticados, que permitam por exemplo a negociaçâo entre os agentes, sua implementaçâo depende do grau de complexidade que se queira dar ao modelo do agente e terâ impacto na dimensâo e complexidade das mâquinas de estado que ele utilizarâ.

(Statecharts). Estes diagramas podem explicitar protocolos de negociaçâo mais gerais e permitem a decomposiçâo do problema através de uma hierarquia de mâquinas de estado mais simPles. do que é Software e do que é Engenharia de Software, ele apresenta como podem ser feitos sistemas a partir do enfoque de ciclo de vida, desde o clâssico, passando por prototipagem de sistemas, desenvolvimento em espiral e uso de técnicas de quarta geraçâo. Argumenta que é possivel utilizar-se uma combinaçâo destas técnicas para o desenvolvimento de sistemas. Para a classe de problemas enfrentados (supervisâo e controle da produçâo), pertencente ao dominio dos sistemas de tempo real, é realmente ritil combinar técnicas de projeto, especialmente visando o desenvolvimento de protôtipos que possam validar os requisitos das aplicaçôes. Hâ ciência de que o desenvolvimento de SMAs necessita de novas técnicas, possivelmente assemelhadas com o desenvolvimento de sistemas baseados em objetos. A metodologia foi baseada em obras clâssicas do projeto de sistemas de tempo real [

Ward 85

],

[Hatley 88

] e ao mesmo tempo propôe a utilizaçâo da Linguagem UML (Unified Modeling Language)

[Douglass 98

] que fornece construtores adequados para este problema. corespondência com a fase de mesmo nome utilizada no Projeto Estruturado de Sistemas de

  Para uma aplicaçâo simples, a Arquitetura Experimental jâ é suficiente, por exemplo para o controle de uma célula de fabricaçâo baseada em ordens jâ totalmente escalonadas, neste caso os elementos jâ implementados poderâo ser facilmente reutilizados. Componentes Genéricos simples, que podem ser validados e aperfeiçoados, busca permitir a reutilizaçâo de blocos frrncionais, otimizando o projeto de novas arquiteturas particulares, sem que essas tenham de partir da estaca zero é robusta, flexivel e adaptada ao problema de supervisâo e controle de châo de fâbrica No capitulo seguinte serâ apresentado um exemplo de derivaçâo de uma Arquitetura Particular, baseada na Arquitetura Experimental e utilizando a Metodologia de Desenvolvimento de Aplicaçôes preconizada aqui. Serâo mostrados os detalhes da metodologia, por exemplo explicitando as mensagens trocadas entre os agentes e sua formalizaçdo.

	Em um certo nivel de decomposiçâo dos diagramas de estado, chega-se a diagramas simples, os quais podem ser representados e implementados pelas técnicas convencionais tais como aquelas indicadas em [Ward 85] e [Hatley 88]. 3.4 Robustez e flexibilidade da arquitetura pode-se dizer que a robustez da arquitetura é obtida por projeto, jâ que os agentes sâo concebidos para trabalharem de maneira autônoma, isto é umavez recebidos seus objetivos eles buscam realizâ-los de maneira independente. Naturalmente o ponto critico da arquitetuta é a comunicaçâo, os agentes podem necessitar ffocar informaçôes durante a consecuçâo de seus objetivos e se o elo de comunicaçâo estiver intenompido eles poderiam ficar bloqueados. para evitar o bloqueio dos agentes foi previsto um sistema de temporizaçào (Timeout), que permite que os agentes passem para um modo de tratamento de falha. Nâo é possivel antecipar os tipos de falha, jâ que elas dependem da aplicaçâo, mas foi previsto um esquema conservador em O elemento que permite esta flexibilidade é o agente bâsico, o Componente Genérico que pode receber requisiçôes de serviço a qualquer instante, alocando o tratamento deste serviço a um Servidor instanciado dinamicamente. Este Componente Genérico também permite o estabelecimento de conexôes com um nûmero ilimitado de outros agentes (através de seus Clientes), independente de qualquer hierarquia. A definiçâo da configuraçâo é responsabilidade do projetista, que deverâ também prover as definiçôes dos protocolos a serem utilizados. Quanto maior o nrimero de agentes diferentes e de instâncias desses agentes tanto maior serâ a Apresentou-se neste capitulo uma Arquitetura Experimental para supervisâo e controle de châo de fâbrica. Esta arquitetura baseia-se em um Componente Genérico, capaz de aceitar a requisiçâo de serviços e de executâ-los de maneira autônoma. A inspiraçâo para este Componente simplicidade do componente, visando sua aplicaçâo imediata a problemas industriais, nâo foi buscada a compatibilidade direta com estas arquiteturas. A outra fonte de inspiraçâo para este Componente Genérico, a qual aliâs também inspirou a Infra-estrutura de Integraçâo CIMOSA, é o protocolo MMS. Supervisâo e Controle e jâ referenciados no Capitulo 2, é qtre esta Arquitetura Experimental: -desde sua concepçâo busca uma compatibilidade com os problemas imediatos da indûstria, através de sua simplicidade e capacidade de açâo em tempo real -considera a questâo primordial da interface com os Sistemas de Planejamento, no nivel superior e com o Dispositivos Fisicos no nivel inferior -através de Capitulo 4 complexidade do sistema. 3.5 Conclusâo Genérico veio das Arquiteturas de Referência, em especial CIMOSA e GERAM; para manter a Apticaçâo da Arquitetura Experimental

prôprio Harel e por outros, que propuseram extensôes à sua obra. Por exemplo pode-se citar Suraj et al.

lSwaj 97] 

que propôem uma extensâo para a modelagem e especificaçâo dos sistemas de controle da manufatura. Em seu trabalho é de especial interesse a metodologia de prototipagem de um modelo, que praticamente coincide com esta proposta (quanto ao aspecto da dinâmica do sistema). que, apôs o disparo da temporizaçdo de comunicaçâo (espera de resposta), o agente tenta recuperar a conexâo por um certo nûmero de vezes, temporizando cada tentativa. Se apôs estas tentativas o agente nâo conseguir continuar a transaçâo (por falta de comunicaçâo) ele laz tma "limpeza de casa" (termina transaçôes pendentes) e passa para um estado inicial (default). Se a falha de comunicaçâo for intermitente, como é normalmente o caso de redes muito carregadas, o agente pode continuar a trabalhar apôs recuperar a comunicaçâo. Se suas atividades nâo dependerem de comunicaçâo (atividade de computaçâo por exemplo) os agentes operam autonomamenre, ativando a comunicaçâo apenas no momento de responder ao serviço requisitado euanto à flexibilidade da arquitetura, observa-se que a mesma foi mantida muito simples, com poucos componentes bâsicos. Esta simplicidade permite especializâ-la para realizar diversas funcionalidades, permitindo grande flexibilidade em sua configuraçâo. Este Componente Genérico pode ser refinado, inicialmente para fornecer os Agentes Supervisor, Recursos e Opcional da Arquitetura Experimental, e posteriormente para especializar estes agentes ou mesmo criar outros que se façam necessârios. A Arquitetura Experimental é construida a base de Agentes, sendo o Componente Genérico o Agente Bâsico que é utilizado para construir os outros. Este Agente Bâsico foi desenvolvido considerando aspectos de tempo real, em especial suporta a perda momentânea da comunicaçâo e pode recuperar-se, permitindo manter a transaçâo (conversaçâo) em andamento. O que distingue esta Arquitetura Experimental de outros trabalhos que foram desenvolvidos, classificados tanto como Sistemas Multi-Agentes quanto como Arquiteturas de Apôs a definiçâo, no capitulo anterior, de uma Arquitetura Experimental baseada em Componentes Genéricos, serâ mostrado como pode-se derivar outras arquitefuras (particulares), adaptadas aos problemas encontrados em cada empresa.

  hôlon Recurso relaciona-se com os recursos de produçâo do sistema de manufatura. Ele oferece a capacidade e funcionalidade destes recursos aos demais h6lons.O hôlon Produto contém o modelo de produto, relacionando-se com os aspectos de projeto desse produto, tais como: planos de processo, composiçâo e restriçôes de qualidade; ele nâo contém informaçôes sobre o estado atual de produçâo de um produto sendo fabricado. Hôlon de Controle da Manufatura em Tempo Real (PHOCS), aconselhando sobre o escalonamento. Usa-se o verbo "aconselhar" devido ao fato de que o outro h6lon pode recusar o conselho, nâo sendo portanto uma ordem imperativa.As Células podem atuar em diversos Produtos coordenando sua produçâo. Os agentes Produto sâo uma espécie de memôria da célula, contendo os dados do produto tais como roteiros e tempos de fabricaçâo.

	SYROCO, Figura	
	Produtos e Recursos.	
	Hôlon de Escalonamento Reativo I Previsâo Y O Supervisor controla o conjunto de Células e responde por uma reorganizaçâo da I Problemas Objetivos produçâo em funçâo de eventos aleat6rios tais como quebra ou indisponibilidade de recursos ou
	mudanças nos objetivos de produçâo.	
	O hôlon Ordem (Pedido) representa uma tarefa do sistema de produçâo. Ele contém informaçôes e gerencia a produçâo do produto fisico sendo fabricado. A funcionalidade do h6lon Ordem pode ser comparada com os môdulos de monitoramento e despacho de sistema de Definiçâo de Obietivos Hôlon de Controle da Manufatura em Tempo Real Consulta + ____jl_.-I Objetivos de l-O Meta-Objeto gera dinamicamente os agentes Produtos, sob demanda do Supervisor, para L-----lp4!ege--J atender os objetivos de produçâo, mesmo em caso de ocorrência dos eventos citados. Ele faz uso 1 Consulta 2 de ferramentas e de conhecimento externos para tal. Por exemplo uma das ferramentas é um controle tradicionais. programa de geraçâo de caminhos para escalonar localmente a produçâo (môdulo
	Sistema de Escalonamento) e os conhecimentos podem estar contidos em base de dados de processos de
	produçâo (BDOO Base de dados orientada a objetos).	Controle
	Ordem 2	
	O protôtipo dessa arquitetura, desenvolvido em Ç++, foi testado por Bongaerts e mostrou-
	Os sistemas selecionados foram: PHOCS / PARSIFAL [Bongaerts 98] e SYROCO se capaz de controlar reativamente a célula do PMA. Relatôrio 2
	[Anciaux 97], [Roy 98]. 4.1.1 PHOCS / PARSIFAL O grupo PMA (Production Engineering, Machine Design and Automation), do descrito em detalhes na tese de doutorado de Daniel Roy [Roy 98]. Figura 4.2: SYROCO : [Roy 981 Departamento de Engenharia Mecânica da Universidade Catôlica de Leuven, Bélgica, têm um Na Figura 4.1 apresenta-se a Arquitetura PHOCS /PARSIFAL. 4.1.2 SYROCO SYROCO (Système Réactif par Objectif de Conduite) foi desenvolvido no laboratôrio LGIPM (Laboratoire de Génie Industriel et Production Mécanique) da Universidade de Metz e é Sistema Fisico Perturbaçôes <
	importante papel na pesquisa de Sistemas Holônicos e desenvolveu uma Arquitetura de PARSIFAL (PMA Reactive Schedulerfor Flexible Assembly Systems, Leuven) é o Hôlon de
	Referência para Sistemas Holônicos de Manufatura, chamada PROSA [Brussel 98]. PROSA define um conjunto de três h6lons bâsicos: recurso, produto e ordem. Opcionalmente um quarto hôlon, chamado "Sîaî'pode ser utilizado na arquitetura. Seu objetivo é o de ser um sistema de supervisâo e controle de châo de fâbrica modular e Escalonamento Reativo cujo propôsito é escalonar de maneira dinâmica, repetitiva e reativa a reconfigurâvel, permitindo uma reaçâo râpida aos eventos nâo previstos durante o curso da Cada Produto necessita de determinadas classes de Recursos, para poder ter seu roteiro de célula de produçâo do Laboratôrio PMA. Ele foi projetado de maneira a facilitar o experimento produçâo. Ele é baseado em um sistema multi-agentes e para permitir um tempo de resposta mais execuçâo realizado. Os Recursos Reais (mâquinas, transporte, arrnazenamento etc.) sâo de diferentes algoritmos de escalonamento. curto, utiliza uma estrutura hierârquica de controle. encapsulados por agentes Recursos.
	80	

O O h6lon Staff tem o propôsito de assistir aos outros hôlons na realizaçâo de seus trabalhos.

Eles podem ser considerados como "conselheiros" para os hôlons bâsicos, que sâo os que realizam as tarefas de produçâo. Os hôlons Staff permitem a presença da funcionalidade de elementos centralizados na arquitefura, a qual sem eles seria puramente heterârquica.

A partir da Arquitetura PROSA, Luc Bongaerts

[Bongaerts 98

] desenvolveu sua arquitetura de controle de châo de fâbrica. A idéia trabalhada em sua tese é a de que um Escalonador pode operar de maneira concorrente com o controle do châo de fâbrica, sendo que este controle realizariaespecificamente as funçôes do Despachador de acordo com o descrito em [

Bauer 94

].

Assim ao invés de reagir às perturbaçôes através de um reescalonamento total da produçâo o Escalonador Concorrente poderia, considerando o estado afual do sistema, "aconselhar" sobre uma nova seqûência de operaçôes. Este Escalonador necessitaria de novos algoritmos e alguns sâo propostos na tese. pARSIFAL é um h6lon do tipo Staff e guia o Figura 4.1: PHOCS / PARSIFAL : [Bongaerts 981 pHOCS ( PMA Holonic On-line Control System) é o Hôlon de Controle da Manufatura em Tempo Real. Ele também é um hôlon do tipo Stafi é centralizado e auxilia a tomada de decisâo dos hôlons bâsicos (Recursos e Ordens).

é composto pelos agentes: Meta-Objeto, Supervisor, Célula, SYROCO foi testado com um exemplo acadêmico [Roy 98], que nâo utiliza recursos reais, e mostrou-se satisfatôrio, sendo capaz de reescalonar localmente a produçâo quando da ocorrência de eventos aleatôrios. Sua implementaçâo foi feita com as linguagem C e C++, com a comunicaçâo baseada em TCP/IP (Transport Control Protocol / Internet Protoco[). O algoritmo de escalonamento utilizado é do tipo Simulated Annealing.

  Uma soluçâo baseada em caffegamento dinâmico de classes foi encontrada. Mesmo sendo 100% compativel com Java ela pode ter problemas em versôes futuras da linguagem, jâ que parece haver uma tendência dos projetistas da linguagem Java na direçâo de RMI (Remote Method Invocation) e CORBA (Common Object Request Broker Architecture) [Orfali 98]. Do ponto de vista de desempenho do côdigo gerado a avaliaçâo é de que ele é bastante baixo , devido basicamente à codificaçâo em Java, e pode ser melhorado. Trabalho futuros irâo indicar se a linguagem Java é limitante para a melhoria do desempenho e se é necessârio utilizar outra linguagem. No momento ainda nâo hâ uma conclusâo definitiva sobre este assunto. Controle do Châo de Fâbrica), o châo de fabrica é um dos componentes da empresa, é necessârio inseri-lo dentro deste contexto, para que novas arquitefuras de controle possam ser desenvolvidas, aproveitando-se de uma visâo global do sistema e da possibilidade de descentrali zaçâo de decisôes.As Arquiteturas de Referência, se por um lado oferecem um quadro abrangente da empresa, através das diversas vistas preconizadas, por outro lado deixam a desejar no aspecto de implementaçâo de sistemas e detalhamento da operaçâo, em especial do subsistema produtivo.Verificou-se que todas as Arquiteturas de Referência apresentam uma evoluçâo temporal do projeto de integraçâo, o chamado "Ciclo de Vida de Projeto". O ciclo de vida mais completo é aquele que foi originalmente concebido na PERA, e que estâ sendo incorporado nos esforços mais recentes de padronizaçâo, representados por GERAM.É interessante observar que, durante a existência de um empreendimento, diversos ciclos de vida, relativos a aspectos distintos, sâo perceptiveis. O primeiro é o pr6prio "Ciclo de Vida de Projeto de Integraçâo", assunto primeiro das Arquiteturas de Referência. Um outro é o "Ciclo de Vida de Produto", representado na Figura 2.10 (Visâo Geral dos Conceitos CIMOSA), o qual tem diversas ocorrências durante a fase de operaçâo da empresa e além disso possui diversas instâncias (produtos diferentes sâo projetados / produzidos ao mesmo tempo). , notou-se uma lacuna. Somente CIMOSA e GERAM apresentam propostas de Infra-estruturas de Integraçâo e, como viu-se no Capitulo 5, item 2.3.2 "lnfra-estruturas de Integraçâo", os resultados experimentais ainda nâo sâo concludentes.Dessa anâlise das Arquiteturas de Controle e de Referência verificou-se entâo que é necessârio considerar, em um projeto de arquitetura de supervisâo e controle de châo de fâbrica, o questâo do desenvolvimento de um sistema de mensagens adequado à produçâo é campo em aberto. O MMS aparece como referência apenas paru a comunicaçâo com os dispositivos de manufatura, a interface com o Planejamento da Produçâo ainda estâ por ser feita, apesar dos esforços iniciais com ontologias para Produçâo que foram apontados no capitulo 2. Influência das Infra-estruturas de Integraçâo QEIs) Tanto CIMOSA quanto GERAM (através da EMEIS) baseiam suas IEIs no conceito de serviços. É justamente este o conceito que apresenta interesse para esta tese. Os Componentes Como o processo de derivaçâo nâo é rigido, diversas soluçôes para um rinico problema podem ser encontradas. A determinaçâo de qual dentre elas é a melhor nâo é o propôsito deste trabalho, devendo o projetista estabelecer as medidas de comparaçâo que lhe permitam escolher entre diversas alternativas, se houverem. Ciclo de Vida do Projeto de Integraçâo" deve-se considerar o châo de fâbrica em todas as suas fases. Este trabalho procura colocar à disposiçâo elementos de modelagem para auxiliar no projeto de um sistema de operaçâo e controle, estando entâo mais fortemente relacionado com as fases de Projeto, Implementaçâo e Operaçâo ( ou Execuçâo ). e com os quais elas têm comprometimentos. A tendência normal é de tentar incorporar estes sistemas, desde que eles nâo sejam o elemento de degradaçâo da eficiência (o que ocolre se eles forem obsoletos). avaliaçâo é que tal combinaçâo técnica é meritôria nesse caso. Para o caso de um sistema totalmente novo, acredita-se que pode ser usada UML na sua forma pura sem maiores problemas.Acredita-se que esta complexidade nâo é um defeito do modelo, que foi pensado para evoluir dentro de um sistema de geraçâo semi-automâtica de aplicaçôes, mas é um indicador da necessidade de usar sistemas de suporte ao desenvolvimentos de aplicativos (CASE 'Computer' de fâbrica, pode-se supor que é possivel garantir a segurança de acesso por mecanismos convencionais, tais quais determinaçâo de subredes. O ponto de acesso externo é a interface com o môdulo de Planejamento da Produçâo, se for necessârio poderâo ser incorporados mecanismos de segurança para este môdulo.Verificou-se que as Arquiteturas de Referência (para integraçâo de empresas) existentes sâo incompletas no referente ao quesito implementaçâo. Dada a complexidade de tais arquiteturas nâo buscaou-se uma compatibilizaçâo restrita com nenhuma delas, procurando apenas extrair as caracteristicas mais riteis ao objetivo deste trabalho.

	A implementaçâo continua sendo feita, faltando apenas: -a conexâo de SYROCO-2 com o Sistema de Supervisâo e Controle jâ existente, através de uma interface escrita na linguagem C a qual utiliza o recurso DDE (Dynamic Data Exchange) do Windows -a finalizaçio do môdulo de escalonamento, o qual permitirâ a experimentaçâo com o algoritmo de busca local selecionado e poderâ ser expandido para incluir outros. O término desses trabalhos necessita da colaboraçâo com outros pesquisadores, os quais complementario a arquitetura com as suas pesquisas e desenvolvimentos. O espirito da plataforma PIPEFA é justamente o de colocar em contato uma equipe multi-disciplinar, de tal forma que todos ganhem com o intercâmbio de informaçôes. 4.4 Conclusâo Apresentou-se neste capitulo um exemplo de como a Arquitetura Experimental desenvolvida, baseada em Componentes Genéricos que utilizam a tecnologia de Sistemas Multi-Agentes, pode ser particularizada para atender à uma aplicaçâo especifica. No caso a aplicaçâo foi o desenvolvimento de uma Arquitetura para Supervisâo e Controle paru a Plataforma PIPEFA. pIPEFA é representativa da classe de sistemas de montagem e utiliza recursos mecânicos e computacionais tecnologicamente atualizados, podendo portanto servir como prot6tipo para uma implementaçâo na indristria. Foram mostradas duas arquiteturas existentes com possibilidade de servirem de modelo para o controle da PIPEFA, outras poderiam ser desenvolvidas, mas a seleçâo dessas duas tem o propôsito de mostrar que a metodologia desenvolvida permite reaproveitar trabalhos anteriores. Foi selecionada a arquitetura SYROCO, esta foi analisada em detalhes, através de uma cooperaçâo estreita com a Universidade de Metz (estâgio de doutorado sanduiche), e foi desenvolvida uma variante chamada SYROCO-2 a qual foi o ponto de partida para o processo de especializaçâo da Arquitetura Experimental. O desenvolvimento conceitual dos Agentes de SYROCO-2, baseados nos Componentes Genéricos, foi uma fase tranqùila, o maior problema foi a redefiniçâo das mensagens de comunicaçâo, que nâo estavam bem formalizadas. Acredita-se que a formalizaçâo sintâtica desenvolvida dentro da metodologia mostrou-se correta e ritil. Verificou-se também que a descriçâo dinâmica de SYROCO, ao nivel macro, feita com os Diagramas de Estado (StateCharts) apesar de formalmente correta, ainda trazia problemas de compreensâo ao implementador. No mesmo nivel macro, a representaçâo paralela com os Diagramas de Fluxo de Dados propostos por Ward-Mellor colaborou para melhorar a legibilidade das especificaçôes. No nivel micro, de detalhamento das especificaçôes, o uso de mâquinas de estado com um conjunto de pré condiçôes, açôes e p6s condiçôes, mostrou ser uma boa opçâo para facilitar a implementagâo. A linguagem UML foi utilizada de maneira referencial, buscou-se combinar as técnicas propostas para UML por [Douglass 98] com aquelas técnicas mais tradicionais de Ward-Mellor [Ward 85] e Hatley-Phirbay [Hatley 88] . Este enfoque mostrou-se bem sucedido e adequado para o problema de reinterpretar uma arquitetura existente e reprojetâ-la dentro do paradigma proposto dos Componentes Genéricos. A implementaçâo ainda nâo foi totalmente completada e nâo é possivel mensurar o desempenho do sistema, porém se considerarmos que, o ciclo de controle normal do sistema jâ existente na PIPEFA, é de um segundo, e que este tempo é apenas relativo à leitura e escrita de variâveis, pode-se afirmar que: se o tempo de geraçâo de um novo escalonamento for de alguns segundos entâo a arquitetura SYROCO-2 te trazido à PIPEFA uma capacidade de reaçâo bastante rapida e mais do que suficiente para o tipo de produto sendo fabricado. Considerando ainda existente e sem descartar isto serâ feito sem interromper o funcionamento do sistema investimentos jâ feitos no parque instalado de aplicativos e que os l0l mâquinas, entâo pIpEFA poderâ ganhar esta nova capacidade, inexistente até entâo, com custos relativamente baixos. No capitulo seguinte serâ feita uma avaliaçâo global do projeto, considerando as especificaçôes dos Componentes Genéricos e da Arquitetura Experimental e sua aplicaçâo na plataforma PIPEFA, através da Metodologia de Projeto proposta. r02 Capftulo 5 Anâlise dos Experimentos e dos Resultados Neste capitulo o propôsito é fazer uma avaliaçâo critica do processo de desenvolvimento dos Componentes Genéricos, da Arquitetura Experimental baseada nos mesmos e, finalmente, da prototipagem de uma Arquitetura Particular adequada à plataforma PIPEFA, que foi chamada SYROCO.2. A discussâo serâ iniciada avaliando-se a influência das Arquiteturas de Referência (para Integraçâo de Empresa) e suas Infra-estruturas de Integraçâo, a seguir serâo discutidos os Sistemas Multi-agentes e a influência do protocolo para comunicaçâo industrial MMS. Continuar-se-â a discussâo com uma anâlise da Arquitetura Experimental e da metodologia de desenvolvimento ProPosta. A finalizaçâo serâ com a discussâo da aplicaçâo dessa metodologia para desenvolver a arquitetura SYROCO-2. 5.1 Influência das Arquiteturas de Controle e de Referência. O problema em foco é controlar um châo de fâbrica, assim uma necessidade ôbvia era estudar as diversas possibilidades de controle de châo de fâbrica descritas na literatura, sobre este tema versou o item 2.1 do Capitulo 2 (Arquiteturas para Supervisâo e Controle). Observou-se no entanto que o enfoque tradicional é centrado em aspectos de controle e escalonamento da produçâo. Como mostrou-se no item 2.2 do Capitulo 2 (lntegraçâo das Funçôes de Supervisâo e Além disso, como a empresa é um ente dinâmico, podem existir outros ciclos durante a fase de operaçâo. No châo de fâbrica esta dinâmica é bem perceptivel, e esté de alguma maneira associada aos ciclos de vida de produtos, pois quando novos produtos sâo desenvolvidos novas arquiteturas fisicas (layouts) e lôgicas ( de controle) podem ser necessârias. Na menor escala de tempo aparecem também os Ciclos de Produçâo, que sâo relacionados à produçâo dos produtos em lotes especificados nos pedidos enviados ao châo de Fâbrica [Doumeingts 84]. Um outro aspecto comum a todas as Arquiteturas de Referência é a utilizaçâo de eventos para a sincronizaçâo de funçôes, eles estâo mais evidentes na cadeia de processos de ARIS (Figura 2.8, Capitulo 2) e na modelagem de processos de negôcios utilizada em CIMOSA ( a qual nâo foi detalhada nesta tese, vide por exemplo [CIMOSA 93], [Vernadat 96]). Quando se trata de trazer estes conceitos para o campo prâtico, para permitir inclusive a operaçâo da empresacontexto geral da empresa e os três ciclos seguintes: -Ciclo de Vida do Projeto de Integraçâo -para permitir inserçâo no contexto global -Ciclo de Vida do Produto -parapermitir flexibilidade na operaçâo e reconfiguraçâo -Ciclo de Produçâo -para a produtividade, flexibilidade e reatividade Concluiu-se que: um enfoque em modelagem da empresa, no nivel especifico de operaçâo do châo de fâbrica, seria ritil para relacionar esses três ciclos. Tal modelagem deveria ser orientada a eventos, de maneira condizente com os esforços jâ desenvolvidos. 5.2 Arquiteturas de Supervisâo e Controle e Sistemas Multi-agentes. Conforme apresentado no Capitulo 2, os SMAs estâo encontrando aceitaçâo no campo de controle de châo de fâbrica, devido às vantagens lâ citadas. O enfoque foi o de levantar quais aspectos seriam relevantes para o projeto de um SMA, dentro de uma linha de modelagem aderente aos padrôes de desenvolvimento de sistemas informatizados. Os aspectos levantados foram: composiçâo, configuraçâo, comunicaçâo e coordenaçâo / negociaçâo. Buscou-se desenvolver um modelo de Componente Genérico considerando tais aspectos. A comunicaçâo apresentou-se como o aspecto polarizador neste projeto, os componentes interagem através da troca de mensagens, dentro do espirito de sistemas baseados em eventos ( as mensagens caregam eventos e dados ou sua recepçâo / emissâo ativam eventos de importância para o sistema). Nota-se a influência do MMS, do qual foram extraidos auxilios para a formalizaçâo das mensagens na Arquitetura Experimental e para a definiçâo da funcionalidade das mensagens no protôtipo. Outros pontos de projeto podem ser discutidos, por exemplo qual seria a composiçâo e configuraçâo minima possivel para aArquitetura Experimental? A questâo é parecida com aquela da definiçâo das camadas de uma Rede Neural: a resposta depende da aplicaçâo, mas certamente uma Rede Neural terâ uma camada de interface com as entradas (estimulaçôes) e outra com as Da mesma maneira vê-se que o châo de fâbrica possui duas interfaces claras, uma com o planejamento da produçâo e a outra com os dispositivos fisicos. O paralelo com redes neurais nâo é completo aqui, pois têm-se entradas e saidas em ambas as interfaces' Como nâo é possivel antecipar as aplicaçôes foi proposto o modelo com 2 f I camadas (Supervisâo, Recursos e Opcionais). A questâo da coordenaçâo I negociaçâo, também depende da classe de sistema que se pretende desenvolve r paruuma certa aplicaçâo. O modelo proposto de agente é bastante simples e esta simplicidade é intencional, pois pretende-se evoluir a especificaçâo no sentido de gerar ferramentas automâticas de suporte ao desenvolvimento de aplicaçôes' No entanto a simplicidade nâo implica em demasiada perda de generalidade, de vez que' apesar de parecer uma soluçâo baseada em reatividade ( no contexto de inteligência artificial), ainda assim é possivel construir sistemas inteligentes com esta estrutura. Basta lembrar que os sistemas peritos sâo baseados em regras e tais regras podem ser incorporadas de maneira quase imediata no modelo ProPosto. Da mesma maneira a incorporaçâo de protocolos de negociaçâo mais refinados, baseados em contratos (Contract-Nets) [Smith 80] ou em atos discursivos (Speech'Acts) [Wooldridge 92], é possivel dentro do modelo proposto. apresentaçâo. Na EMEIS existem os serviços de execuçâo de modelos, que deverâo ter uma funcionalidade semelhante. Nâo foi o prop6sito fazer nm mapeamento das IEIs CIMOSA ou GERAM, nâo buscou-se nesse momento compatibilidade com as mesmas. No entanto elas tiveram forte influência conceitual, mesmo porque elas sâo uma condensaçâo das melhores prâticas para o desenvolvimento e operaçâo de sistemas abertos. Os aspectos mais influentes das IEIs sobre este trabalho foram a especificaçâo orientada a serviços e a visâo dos componentes genéricos como sendo os atores da execuçâo de modelos, desempenhando o papel de Entidades Funcionais que executam Funçôes Operacionais, numa analogia aos modelos CIMOSA 5.4 Desenvolvimento do Protôtipo e Avaliaçâo da Metodologia No Capitulo 3 apresentou-se o conceito de Componente Genérico e esquematizou-se uma metodologia para desenvolvimento de aplicaçôes baseada nestes componentes. Desenvolveu-se também uma Arquitetura Experimental que utiliza estes componentes e os organiza de uma maneira estruturada e didâtica para ilustrar o problema geral de supervisâo e controle de châo de fâbrica. Esta Arquitetura Experimental visa apenas servir como referência inicial a partir da qual o projetista pode tentar enquadrar o seu problema real, através da derivaçâo de uma Arquitetura Particular adequada à esse problema. projeto da arquitetura acompanhando um ciclo de desenvolvimento. Na primeira fase deste ciclo consta a "Especificaçâo dos Requisitos" da arquitetura, o que implica levantar o estado atual do sistema de produçâo, levando em consideraçâo o chamado "sistema Herdado" (Legacy System). Quanto ao modelo de agente desenvolvido avaliou-se que para o prot6tipo ele se mostrou satisfatôrio. Notou-se no entanto que o detalhamento necessârio de todos os eventos (relacionados às mensagens ou internos ) e das açôes associadas, obtidos dos diagramas de reengenharia do Projeto SYROCO [Roy 98], e foi feita uma programaçâo totalmente nova, a partir da especificaçâo atualizada e adaptada à PIPEFA, que foi chamada SYROCO-2 ( Figura 4.4 do Capitulo 4). A estruturaçâo dos dados proposta na metodologia, a qual jâ havia sido utilizada na pIpEFA, mostrou-se satisfat6ria. A coordenaçâo dos agentes foi representada pelos DFDs e por diagramas de estados (Statecharts). Julga-se que é necessâria uma ferramenta de suporte aos diagramas de estado, para permitir a avaliaçâo dinâmica dos mesmos. As ferramentas mais avançadas disponiveis suportam a animaçâo e simulaçâo dos modelos, o que permite encontrar falhas na especificaçâo de maneira antecipada. O orçamento nâo permitiu dispor dessas ferramentas durante o decorrer deste projeto. Para a implementaçâo foi decidido usar a versâo de Java distribuida pela Sun Microsystems chamada IDK 1.22. Esta versâo jâ suporta RMI (Remote Method Invocation) e interface com CORBA. Como jâ argumentado, optou-se por um c6digo I00o/o, Java mas buscou-se deixar espaço para migrar para soluçôes hibridas. Foram usadas técnicas de prototipagem râpida paft o desenvolvimento dos agentes, as quais permitiram corrigir as especificaçôes funcionais quando necessârio. Sabe-se da literatura que o desempenho de aplicaçôes Java é inferior ao de aplicaçôes escritas em ll0 Cabe ressaltar que um problema encontrado durante a implementaçâo é a existência de via Internet. Este problema deve ser superado quando o protôtipo se estabilizar e puderem ser negociadas portas especificas para conexâo, as quais seriam registradas junto aos organismos Nesta fase inicial nâo foram considerados aspectos de segurança de acesso, pois eles l14 t12 de engenharia. Genéricos e reaplicâ-los, para poder juntar mais evidências favorâveis da eficâcia das propostas quando mostrarem-se adequados, de forma a compor no longo prazo uma biblioteca de soluçôes Serâ necessârio finalizar as interfaces existentes, estabilizar o côdigo dos Componentes permitir o desenvolvimento de modelos experimentais, que possam ser parcialmente reutilizados O sucesso parcial obtido ainda nâo permite antecipar bons resultados em outras aplicaçôes. A proposta de basear o desenvolvimento de arquiteturas em Componentes Genéricos visou competentes. empresa, buscou uma maior aproximaçâo com CIMOSA e GERAM. Engenharia de Empresa [Vernadat 96]. mundo real, enquanto o trabalho citado, que versa sobre uma linguagem de modelagem de Uma maneira de atingir estes propôsitos é através da Modelagem de Empresas e da mecanismos de execuçâo. Uma diferença é que este trabalho é mais orientados à adaptaçâo ao proteçôes de rede do tipo "paredes corta fogo" (Firewalls), as quais dificultam a conexâo remota Metodologia de Projeto, à luz dos resultados jâ obtidos. Este desenvolvimento mostrou claramente a necessidade de utilizar-se ferramentas de suporte do tipo CASE, as quais infelizmente nâo estâo ainda disponiveis para SMAs, sendo objeto de pesquisas e desenvolvimentos. No entanto existem ferramentas UML que podem ser utilizadas de acordo com a metodologia preconizada, em conjunto com ferramentas DFD. A continuaçâo do projeto e finalizaçâo da implementaçâo certamente serâ beneficiada com a aquisiçâo de tais suPortes. Em [Santos 00] encontra-se uma motivaçâo e enfoque parecido a este trabalho, quanto aos O tema que foi abordado nesta tese foi o Projeto e Construçâo de Arquiteturas para Supervisâo e Controle de Châo de Fâbrica. A abordagem adotada buscou contemplar dois aspectos, freqûentemente negligenciados em trabalhos assemelhados: integraçâo com os outros participes da empresa e aproveitamento de conhecimentos adquiridos. Como foi descrito no Capitulo I -Evoluçâo das Empresas, acredita-se que as novas empresas irâo mais e mais necessitar de uma compreensâo e dominio de seu prôprio funcionamento. Esta compreensâo passa pelo "pensamento sistêmico" [Senge 94], pela busca de uma visâo global e nâo departamental da empresa, e pelo processo de auto-conhecimento e gerência do processo de conhecer [Savage 96]. No tocante ao "98]. Devido à essa convicçâo enfatizou-se na metodologia o acompanhamento da evoluçâo do Na fase seguinte, que é de Projeto ( Funcional e Detalhado), sâo exercitados os Componentes Genéricos, na forma dos agentes desenvolvidos na Arquitetura Experimental. implementados em Java de acordo com a Arquitetura Experimental. Para a segunda foi feita uma Neste capitulo foi feita uma revisâo critica das propostas de Componentes Genéricos e ciclo menor que é a execuçâo de uma operaçâo bâsica. A implementaçâo dividiu-se em duas partes, a primeira tratou dos Componentes Genéricos, finalizado, a reconfiguraçâo da PIPEFA serâ feita dentro do "Ciclo de Produçâo" e dentro do 5.4.4 Conclusâo Conclusâo uma matriz binâria 7 I'g) e as dez saidas, cada uma correspondendo a um digito. CIMOSA tem uma influência clara do MMS na especificaçâo de seus serviços de em relaçâo a eles. 5.4.3 Fase de ImPlementaçâo cada posto de trabalho é realizada na ordem de segundos. Assim, quando o protôtipo estiver saidas. por exemplo, para decodificar os digitos (0-9) serâo necessârias as entradas (por exemplo linguagenscompiladas(comoporexemploceC++;.OcôdigointerpretadoJavaéentre5e3 vezes mais lento que o côdigo gerado por estas linguagens apresentadas. O trabalho serâ continuado neste sentido, para, em futuro prôximo, confirmarem-se com mais dados as avaliaçôes. 5.3 Genéricos possuem uma certa funcionalidade que é colocada à disposiçâo na comunidade através da oferta de serviços. O acesso aos serviços é feito através de requisiçôes e respostas, de maneira semelhante ao protocolo MMS. O propôsito foi o de criar um quadro conceitual, suportado por um conjunto minimo de componentes implementados, que permitisse facilitar o trabalho de projeto e implementaçâo de uma arquitetura para controle do châo de fâbrica. Falou-se anteriormente de três diferentes ciclos de vida, o châo de fâbrica serâ posicionado O protôtipo desenvolvido apresentou um tempo de resposta da ordem de um segundo, Aided Software Engineering). Ocorre que, como jâ foi observado no Capitulo 3, item 3.22 Na aplicaçâo foi bem ilustrada esta problemâtica, mostrando que o novo sistema, o qual deveria aportar uma capacidade de reagir aos imprevistos de maneira automâtica, deveria usando duas mâquinas de baixa performance (mas representativas do disponivel nas indristrias), (Agentificaçâo), ainda nâo hâ sistemas de suporte ao desenvolvimento de SMAs. Os sistemas um Pentium 75 Mega-hertz (16 Mega-byes de memôria) e outro de 166 Mega-hertz de relôgio e O acesso para o Banco de Dados de Produçâo, se feito remotamente, poderâ utilizar-se dos Essa lacuna propiciou entâo apresentar a primeira contribuiçâo do trabalho: UML existentes sâo genéricos e para projeto orientado à objetos. 32 Mega-bytes de memôria. mecanismos normais de conexâo SQL (Srrr,rctured Query Language) [Date 89], que baseiam-se conviver com o sistema jâ em operaçâo. em senhas de acesso. Tal possibilidade jâ foi anteriormente exercitada na PIPEFA, com um O desenvolvimento de Componentes Genéricos e de uma Arquitetura Experimental, os O modelo e metodologia desenvolvidos ensaiam ser uma contribuiçâo nesse sentido. A avaliaçâo é de que este tempo, apesar de alto em relaçâo à complexidade da aplicaçâo, é Capftulo 6 quais podem ser particularizados para aplicaçôes especificas e podem ser reutilizados, acesso remoto da FEM ao ITI, as restriçôes de parede corta fogo aplicam-se. 5.4.2 Fase de Projeto bom em relaçâo aos requisitos do sistema real representado pela PIPEFA, onde a operaçâo de diminuindo o custo de novos projetos e facilitando a Engenharia de Empresas.

A

Durante a Operaçâo da Empresa, podem estar em curso mriltiplos "Ciclos de Vida de produto", os quais podem ter fases como: Especifrcaçâo de Requisitos de Mercado, Projeto, Liberaçâo, Fabricaçâo, Distribuiçâo e Vendas. Dentro da fase de Fabricaçâo encontra-se o "Ciclo de produçâo" o qual é regido pela arquitetura de supervisâo e controle, objeto deste trabalho.

5.4.1 Levantamento do Sistema Existente e Especificaçâo dos Requisitos

Esta-se de acordo com Parunak quando este diz que SMAs para aplicaçôes industriais devem ser capazes de enfrentar as fases do ciclo de vida de um projeto de engenharia

[Parunak Os 

Sistemas Herdados sâo importantes para as empresas, pois significam investimentos e treinamentos jâ feitos Este exercicio pode ser feito, num primeiro instante, através da criaçâo de variaçôes de arquiteturas. Por exemplo mostrou-se que, para o caso do protôtipo, duas arquiteturas jâ haviam sido utilizadas em situaçôes semelhantes. O projetista poderia fazer uma prototipagem nâpidas das arquiteturas possiveis, comparando-as, antes de partir para o projeto detalhado final.

Nesta fase, a metodologia propôe a ntilizaçào de UML, em moldes semelhantes ao apregoado em [

Douglass 98

], porém julgou-se que, como apontado anteriormente, é usual a convivência com Sistemas Herdados, tal fato leva a incorporar uma capacidade de anâlise da situaçâo atual da empresa, uma espécie de reengenharia ou engenharia reversa.

Neste sentido foram feitos experimentos com as técnicas clâssicas de projeto de tempo real [

Ward 85

],

[Hatley 88

], especialmente com o uso de Diagrama de Fluxo de Dados, para estabelecer o contexto da aplicaçâo e a interaçâo entre os m6dulos (agentes) principais.

A seqûência e das especificaçôes com diagramas de estado (Statecharts) resultou muito complexa.

Observou-se que, para permitir prototipar a aplicaçâo, muita energia foi investida em m6dulos externos, que nâo estavam ainda disponiveis (na forma necessâria) no sistema PIPEFA. Estes m6dulos foram: Ferramentas de Reescalonamento, Banco de Dados de Produçâo, Planejamento da Produçâo e Recursos Fisicos, como indicado na Figura 4.5 do Capitulo 4 (Prot6tipo dos Agentes). Assim o trabalho de desenvolvimento da arquitetura, que conta com os agentes Supervisor, Meta-objeto, Célula e Recursos, foi praticamente dobrado em extensâo, causando uma aumento proporcional do tempo de implementaçâo. Por outro lado, apôs a frnalizaçâo do protôtipo, a qual deve ocorrer em breve, a PIPEFA contarâ com interfaces padronizadas (via agentes), o que lhe permitirâ interagir mais eficientemente com seus parceiros atuais e futuros. impactariam no desempenho e complexidade do sistema. Como a operaçâo da arquitenrra estâ lll circunscrita ao châo Em geral o enfoque proposto mostrou-se consistente e operacional, nâo observou-se nenhuma inconsistência conceitual no decorrer da aplicaçâo do método ao desenvolvimento do sistema SYROCO-2.

  aplicaçâo em estudo é a criaçâo de Células Simuladas, semelhantes estruturalmente à célula de produçâo da PIPEFA, para que em conjunto com essa riltima possam compor um problema de complexidade maior, o qual permitirâ avaliar o desempenho das arquiteturas para casos mais complexos.6.1.3 Modelagem de Infra-estrutura de IntegraçâoComo foi dito no trabalho nâo procurou-se seguir estritamente os modelos preconizados nas IEI CIMOSA e EMEIS. Os trabalhos de padronizaçào da Arquitetura de Referência GERAM continuam, assim como a necessidade de se dispor de uma IEI que permita executar os processos obtidos através da modelagem da empresa e / ou subconjuntos da empresa.

	O desenvolvimento teôrico realizado e a sua consolidaçâo através do protôtipo de
	SYROCO-2 visou criar uma infra-estrutura que desse suporte à colaboraçâo jâ existente entre a
	Faculdade de Engenharia Mecânica da Unicamp, o Instituto Nacional de Tecnologia de
	Informaçâo -ITI ( Ministério de Ciência e Tecnologia) e os laboratôrios parceiros LIISI
	(Laboratoire d'Ingénierie Intégrée des Systèmes Industriels) em Toulon, pertencente ao ISMCM
	-CESTI I (Institut Supérieur des Matériaux et de la Construction Mécanique -Centre d'Etudes
	Supérieures des Techniques Industrielles ) e LGIPM (Laboratoire de Génie Industriel et
	Production Mécanique) da Universidade de Metz, ambos na França.
	Pode-se apresentar as seguintes possibilidades de trabalhos futuros a serem desenvolvidos
	pelos parceiros utilizando a infra-estrutura da PIPEFA:
	6.1.1 Criaçâo de novas arquiteturas
	IJmavezterminada a implementaçâo poderâo ser criadas arquiteturas alternativas, as quais
	poderâo ser comparadas segundo diversos fatores tais como: desempenho, custo, complexidade
	etc. Existem arquiteturas que consideram o produto como um agente, outras consideram os
	pedidos como agentes; estas diversas possibilidades poderâo ser exercitadas utilizando o
	Componente Genérico e a metodologia desenvolvidos.
	Esta arquitetura diferencia-se suficientemente de seu modelo original, o projeto SYROCO 6.1.2 Simulaçâo distribuida de ambiente de manufatura
	[Roy 98], tanto em estrutura lôgica quanto em especificaçâo funcional (baseada nos
	Componentes Genéricos) e desenvolvimento de interfaces e côdigo, para que seja considerada Um campo emergente de utilizaçâo de Sistemas Multi-agentes é na simulaçâo distribuida
	como uma outra contribuiçâo deste trabalho. aplicada no contexto de sistemas de manufatura. Dependendo do grau de abstraçâo utilizado, os
	Componentes Genéricos podem representar todo um subconjunto produtivo (célula ou fâbrica) e 6.1 Trabalhos Futuros permitem exercitar simulaçôes do relacionamento entre estes subconjuntos. Uma aplicaçâo que jâ
	estâ sendo estudada é a utilizaçâo da estrutura bâsica de agentes ( parte de comunicaçâo e reaçâo

Esta tese foi desenvolvida dentro de um ambiente maior que é aquele definido pela plataforma PIPEFA, a qual desde a sua concepçâo apresentou um carâter multidisciplinar, englobando automaçâo industrial, tecnologia de informaçâo e gerência da produçâo. a eventos) para a simulaçâo distribuida de cadeia de suprimentos.

Outra

Pretende-se acompanhar a evoluçâo do processo de padronizaçdo e contribuir com o desenvolvimento de componentes e blocos funcionais compativeis com a especificaçôes a serem desenvolvidas.

  Na coluna da esquerda encontra-se um agente Célula, derivado da classe SyrAgent e pertencente à classe SyrCell, na coluna da direita estâ um agente Recurso, classe SyrRes.Na Célula a chegada de uma mensagem ordreProd (Fabriquer) ativa um Servidor (caracterizado pelo protocolo SSCProtocol ), identificado pelas portas 4444 1055, este determina a criaçâo de um Cliente ( 1056 4445, protocolo SCCRProtocol) para comunicar-se com o agente Recurso e entra no estado de PRODUÇÂO.No lado do Recurso, a chegada de uma mensagem ordreRessource, enviada do Cliente da Célula, ativa a criaçâo de um Servidor do Recurso (SSRProtocol, portas 4445 1056), este cria um Cliente do Recurso (SCRProtocol, 1057 4448) para comunicar-se com o Recurso Real. . O Recurso envia mensagens ordreResReel ao Recurso Real e recebe respostas infoResReel.Enquanto nâo houver problemas estas mensagens sâo repassadas à Célula e o Recurso continua no estado de PRODUÇÂO. Quando ocorre um problema, no caso a chegada de uma mensagem infoResReel com a indicaçâo de pane, o Cliente do Recurso que se comunicava com o Recurso Real é fechado. O Servidor do Recurso envia uma mensagem infoRessource para a Célula e entra no estado de EXCEÇÂO fechando-se a seguir. Como este Recurso estâ em falha nâo poderâ continuar a ser utilizado.

		>j vi ew /cp :p ..\SyrocoServer ..\SyrCell\SyrCell		>jview /cp:p ..\SyrocoServer
	\	iniSer 44441055 SSCProtocol recMsg ordreProd Fabriquer 44441055	..\SyrRes\SyrRes iniSer 44451056
		iniCli 1056 4445 SCCRProtocol trlocMsg ordreRessource null1056/	,vSSRProtocol recMsg ordreRessource nuil 4445 1056
		4445		iniCli 1057 4448
		SSCProtocol PRODUCTION 4444 1055		SCRProtocol trlocMsg ordreResReel
		SCCRProtocol transMsg ordreRessource null I 056		NIHIL t057 4448
		4445		SSRProtocol PRODUCTION 4445
		SCCRProtocol recMsg infoRessource Status 1056		1056
		4445 SCCRProtocol recMsg infoRessource Panne I		SCRProtocol transMsg ordreResReel NrHIL 1057 4448 + SCRProtocol recMsg infoResReel f
		4445		Status 1057 4448
		SSCProtocol trlocMsg infoRessource Panne 4444	
		1055		SCRProtocol transMsg ordreResReel
		SCCRProtocol EOFException 1056 4445		Consulter 1057 4448
		SCCRProtocol finalize 1056 4445		SCRProtocol recMsg infoResReel
		SSCProtocol EXCEPTION 4444 1055		Panne 1057 4448
		SSCProtocol transMsg infoCellule Panne 4444 1055		SSRProtocol trlocMsg infoRessource
				Panne 4445 1056
		SCCRProtocol a ferme' SSCProtocol trlocMsg infoResNS Panne 4444 1055	SCRProtocol finalize 1057 4448 SCRProtocol a ferme'
		SSCProtocol EOFException 4444 1055 SSCProtocol transMsg infoResNS Status 4444 1055		SSRProtocol EXCEPTION 4445 1056 transMsg infoRessource
		SCCRProtocol finalize 1056 4445		Panne 4445 1056
		SSCProtocol finalize 4444 1055		SSRProtocol finalize 4445 1056
		SSCProtocol a ferme'		SSRProtocol a ferme'
				iniSer 4445 1059
		iniSer 4444 1058		SSRProtocol recMsg ordreRessource
				null 4445 1059
		SSCProtocol recMsg ordreProd Fabriquer 4444		iniCli 1060 4448
		iniCti 1059 4445		SCRProtocol trlocMsg ordreResReel
		SCCRProtocol trlocMsg ordreRessource null 1059		NIHIL 1060 4448
		4445		SSRProtocol PRODUCTION 4445
		SSCProtocol PRODUCTION 4444 t058		1059
		SCCRProtocol transMsg ordreRessource null 105		SCRProtocol transMss ordreResReel
		4445 SCCRProtocol recMsg infoRessource Status 1059		NIHIL 1060 4448 SCRProtocol recMsg infoResReel I
		4445		Status t060 4448
		SSCProtocol trlocMsg infoRessource Status 4444		SSRProtocol trlocMsg infoRessource
		1058		Status 4445 1059
		SSCProtocol transMsg infoCellule Status 4444 1058	SSRProtocol transMsg infoRessource
				444s r0se
				::*'
		r37 Figura A.4: Rastreamento de mensagens 138

Como ponto de partida para a elaboraçâo de GERAM, a Força Tarefa analisou em detalhes as arquiteturas CIMOSA, GRAI-GIM e PERA e propôs uma definiçâo de arquitetura generalizada. Segundo seus autores "GERAM nâo é mais uma proposta para uma arquitetura de

-Gerência de Recursos -Atribuir Recurso para Operaçâo Funcional e Liberar Recurso de Operaçâo Funcional -Controle de Operaçôes -Executar Operaçâo Funcional, Parar Operaçâo Funcional, Reativar Operaçâo Funcional, Abortar Operaçâo Funcional e Terminar Operaçâo Funcional.e) Serviços Comunsprovêem soluçôes comuns para assuntos relacionados com os outros serviços. Estas questôes sâo entre outras a da distribuiçâo de componentes e a da comunicaçâo entre estes componentes. Segundo [Lapalus 95], a funcionalidade destes serviços permite:ativaçào de uma aPlicaçâo estabelecimento de uma associaçâo entre duas aplicaçôes envio e recebimento de requisiçôes e respostas entre as aplicaçôes gerência de comunicaçâo.Do ponto de vista de implementaçâo de sistemas CIMOSA, é relatado o uso de Gerência de Comunicaçâo baseado em protocolos ISO [Lapalus 95].