DÉMARCHE DE L’ANALYSE ET TRI DES FACTEURS EXPLICATIFS 6.2

A integração de vários recursos de máquina com protocolos e funcionalidades diferentes é a chave para uma CFM47, aumentando a flexibilidade da produção e o controle de qualidade (LEITÃO et al., 1996). O maior passo na integração é conectar as máquinas em uma rede de comunicação, permitindo a troca de informações entre as máquinas e os sistemas externos.

A arquitetura proposta por SILVEIRA (1991) de uma célula flexível de manufatura foi adotada como base para a validação do modelo apresentado. Para representar os dispositivos industriais de chão de fábrica foram desenvolvidos softwares que emulam o seu funcionamento. Assim, é possível criar um cenário para simular a troca de mensagens entre os agentes e os dispositivos do chão de fábrica fazendo uso dos protocolos apresentados na proposta. A razão desta adoção e emulação foi a não existência de uma CFM real para a realização de testes. De qualquer forma, os dispositivos industriais são representados/implementados como processos computacionais completamente distribuídos e autônomos, o que dá ao cenário desenvolvido uma situação relativamente realística.

A descrição da CFM á apresentada na forma de uma especificação funcional informal, que objetiva um conhecimento básico sobre os dispositivos que compõem a célula e algumas atividades requeridas durante o processo de produção.

A CFM descrita comporta os seguintes elementos: • Um ou mais centros de usinagem;

• Sistema de transporte e armazenamento de peças (mesa posicionadora); • Dispositivo de manipulação e armazenamento de ferramentas (robô) e • Sistema de controle (agentes).

Na verdade para o fim a que se destina, não é relevante conhecer o fluxo completo de materiais/informações dessa CFM. O que se deseja é ter um ambiente onde os equipamentos de manufatura sejam agentificados e possam se comunicar com outras entidades de forma ágil.

A Figura 20 mostra o layout da CFM adotada como modelo.

O padrão MMS é especificado como um protocolo genérico da camada de aplicação destinado à transmissão de mensagens no ambiente industrial, permitindo o acesso aos dados e a execução e controle de uma vasta gama de sistemas e equipamentos no chão de fábrica.

As organizações de padronização especializadas são responsáveis pela elaboração dos padrões contendo detalhes e aspectos específicos das aplicações de cada equipamento (não cobertos pelo padrão genérico). Tais documentos são referidos como Companion Standards48 na ISO-9506 (padrões associados ao MMS) (LEITÃO et al. 1996).

A especificação do padrão baseia-se numa representação em objetos, onde os elementos são descritos através de objetos abstratos (objetos MMS), contendo características externamente visíveis (atributos MMS) e operações sobre estes objetos (serviços MMS).

Cabe a cada um dos Companion Standards criar serviços específicos e particularizar aqueles definidos pelo padrão genérico quando necessário.

4.2 Os Agentes

Todos os agentes têm a mesma “estrutura”, seja qual for a classe a que eles pertencem. A diferença entre os agentes que pertencem à classe CommonAgent, AgentManager e AgentMachine está na implementação dos métodos descritos nas classes. A Figura 21 ilustra o diagrama de classes dos agentes – UML49 (BOOCH et al. 2000) e (LEE, 1997).

48 _{Companion Standards – padrões contendo os detalhes e aspectos específicos de aplicação para cada}

equipamento não coberto pelo padrão MMS genérico.

A classe Interface(TForm) é responsável pela interface dos agentes com os usuários, permitindo aos usuários (pessoas) interagir com o sistema.

A classe CustomMessageListener é responsável por receber as mensagens externas (definidas pelos usuários/agentes) que chegam aos agentes. Esta classe que invoca os métodos para a tomada de decisão.

Cada agente possui uma lista de agConnections que representa as ligações com outros agentes do sistema, ou seja, esta lista informa quais os agentes é possível a troca de mensagens no sistema multiagente.

A plataforma de comunicação usada no Massyve Kit 3.0 é implementada na classe Tcommunicator, esta classe é responsável pelo suporte/protocolos de comunicação. Os agentes derivam essa classe e implementam os métodos específicos para a sua comunicação na classe TAgentsCommunicator.

A classe Agents é o “corpo” principal do agente. Nesta classe estão implementadas todas as funções para o funcionamento destes.

Se a classe Agents é considerada o “corpo” do agente, a classe TdecisionMaker pode ser considerada o “cérebro”. A classe TdecisionMaker é o local onde é codificada a “inteligência” do agente. Nela são implementas as tomadas de decisões e o agente “sabe” quando e como se comunicar com os demais agentes ou com os dispositivos do chão de fábrica.

Na classe TkqmlMessage são implementados os métodos e os atributos utilizados para manipular o objeto kqmlMessage dentro do agente (ver seção 4.9).

Quando um sistema multiagente ou um agente qualquer quiser utilizar os benefícios de se comunicar com os agentes que representam os dispositivos de chão de fábrica, ou seja, se comunicar com os agentes da classe AgentManager, é necessário incluir as classes CustomMessageListener, TdecisionMaker e TkqmlMessage. Com estas qualquer agente saberá como enviar e receber mensagens aos AgentManager sem a necessidade de fazer grandes alterações nos agentes que não pertencem ao contexto industrial.

4.3 Os AgentMachine

Os AgentMachine são os Agentes responsáveis pela comunicação dos AgentManager com o VMD de cada um dos dispositivos industriais citados a seguir, tornando a comunicação no chão de fábrica transparente. A comunicação do AgentMachine com o VMD (que pode estar em um sistema legado ou diretamente acoplado ao dispositivo industrial) é feita através das IDLs CORBA que servem como interface de mapeamento entre o agente propriamente dito e o VMD através da arquitetura CORBA.

Um arquivo IDL descreve os tipos de dados, operações e objetos que um cliente pode requisitar e que o servidor pode disponibilizar para a implementação de um dado objeto.

Como exemplo, um arquivo IDL poderia descrever uma interface VMD que define os serviços MMS CreateProgramInvocation, DeleteProgramInvocation, Start, DataExchange e Status. Uma aplicação cliente que faz uso desta IDL estaria capaz de fazer requisições para todas as operações disponibilizadas e especificadas na IDL, e um servidor que poderia satisfazer as requisições de um cliente estaria apto a executar o trabalho associado com as operações descritas na IDL.