Projeto MAP
Introdução
O projeto MAP tem como mérito a apresentação de uma proposta concreta para a comunicação no ambiente de fábrica, estabelecendo as condições necessárias para a integração dos componentes de automação de um ambiente segundo a filosofia CIM.
O projeto MAP nasceu no início dos anos 80 por iniciativa da GM (General Motors) que, para competir com as companhias automobilísticas japonesas, queria montar uma rede abrangendo todos os seus escritórios, fábricas, revendedores e fornecedores. A ideia era que, quando um cliente encomendasse um carro em qualquer lugar do mundo, o computador da revendedora transmitiria instantaneamente o pedido para a GM, que então entraria em contato com os fornecedores para ter o material necessário à produção.
Uma parte importante desta rede da GM era a automação de fábricas, no qual todos os robôs seriam interligados. Tendo em vista que os carros se movem através de linhas de montagem a uma taxa fixa, quer os robôs estejam prontos ou não, a GM considerou essencial ter uma LAN no qual o pior tempo de transmissão tivesse um limite superior conhecido previamente (a Ethernet não possui esta propriedade).
Na época, poucos equipamentos na fábrica da GM podiam se comunicar entre si e os custos dessa comunicação eram muitos altos devido às interfaces especiais necessárias em cada equipamento. Além disso já se previa o aumento no número de equipamentos programáveis a serem instalados e que necessitariam de comunicação. Em função disso, o custo de comunicação passou a ser uma prioridade na empresa.
Para solucionar o problema, as seguintes soluções eram possíveis:
• Continuar a produção utilizando máquinas isoladas (stand-alone) de uma variedade de fabricantes e utilizar interfaces especiais para possibilitar a comunicação;
• Fazer aquisição de equipamentos de um único fabricante, acabando com a incompatibilidade;
• Desenvolver uma proposta padronizada que permitisse interconectar todos os equipamentos da empresa.
Dadas às perspectivas de evolução e o grande desenvolvimento dos equipamentos de automação, a primeira proposta era, naturalmente, inviável. Com relação a segunda proposta, era (e continua sendo) impossível encontrar um único fabricante capaz de fornecer todos os equipamentos necessários ao processo de fabricação.
A solução viria, então, pela terceira opção, que foi o ponto de partida para o projeto MAP, através da criação de uma força tarefa reunindo profissionais das diversas divisões da GM, cujo objetivo inicial era investigar a possibilidade de utilização do modelo de referência OSI como base para a proposta padronizada da empresa (para evitar incompatibilidades).
Um ano mais tarde, em 1981, A GM uniu-se à Digital Equipment Corporation (DEC), Hewlettt-Packard (HP) e IBM. O grupo se preocupou então a selecionar alguns padrões de protocolos já definidos para o modelo OSI e que pudessem ser adotados na nova arquitetura.
Esse trabalho conjunto levou ao MAP (Manufacturing Automation Protocol) utilizando o token-bus, que foi rapidamente adotado por muitas companhias no mundo, mas que atualmente está em desuso.
Aproximadamente na mesma época do início do desenvolvimento do MAP, a Boeing estava interessada em padrões de automação de escritório. Como, para ela, não havia requisitos de real-time (os boeings não seguem em linhas de montagem) e já possuía uma enorme base instalada de Ethernet, preferiu este padrão. O conjunto de protocolos resultantes foi denominado TOP (Technical and Office Protocols).
No ano de 1986, o projeto TOP foi incorporado ao MAP gerando o projeto MAP/TOP. Este garante que pelo menos nas camadas intermediárias, ambos os protocolos (MAP e TOP) são compatíveis.
Arquitetura MAP
Uma vez adotado o modelo OSI como referência para a arquitetura de comunicação, o problema era selecionar as propostas a serem implementadas em cada camada. Para as camadas 1 e 2, forma selecionadas, respectivamente, as normas IEEE 802.4 (token-bus) e IEEE 802.2 (LLC).
Do ponto de vista da camada Física, foi escolhido o suporte de comunicação broadband. Tal escolha foi baseada nas seguintes razões:
• Possibilidade de definição de vários canais de comunicação sobre um único meio físico, o que permitiria a coexistência de várias redes, minimizando as modificações dos cabos durante a transição para MAP;
• Permitiria a troca de outros sinais, como voz e imagens (circuito fechado de TV, teleconferência, etc);
• Broadband é parte da norma IEEE 802.4;
• A GM já possuía muitas instalações operando em broadband.
As razões que conduziram à escolha do token-bus foram:
• Inicialmente, era o único método de acesso ao meio suportado para broadband;
• Muitos equipamentos programáveis já eram providos com o protocolo de enlace suportado por broadband e IEEE 802;
• A possibilidade de implementar um esquema de prioridade de mensagens.
Apesar das razões supracitadas para escolha do token-bus, esta foi uma escolha relativamente debatida, principalmente porque a arquitetura MAP é a única a adotá-la e os circuitos integrados implementando IEEE 802.4 são utilizados exclusivamente para esta arquitetura. Além disso, outras propostas tinham sido adotadas pelos grandes fabricantes: Ethernet (IEEE 802.3) no caso da DEC/Intel e IEEE 802.5 no caso da IBM.
A nível da camada de Enlace, embora as funções associadas sejam principalmente a detecção e recuperação de erros, optou-se por um protocolo que não implementasse estes serviços, o LLC tipo 1, deixando estas funções a cargo dos níveis superiores (mais particularmente, o nível Transporte).
O serviço de Rede é sem conexão (datagramas, mais flexível e robusto na conexão de múltiplas redes heterogêneas), cada mensagem sendo roteada individualmente através da rede, conforme a norma ISO 8473. O padrão especifica a forma de endereçamento e como este leva ao roteamento pela rede. O endereço possui 3 subpartes: companhia, LAN e número da máquina. Isto induz a um roteamento hierárquico, com os pacotes sendo roteados para a companhia apropriada, LAN apropriada e máquina destino.
A nível do Transporte, foi adotada a classe 4 do protocolo de Transporte da ISO (TP4, ISO 8072/73), orientado à conexão, com controle de erros. O serviço de Transporte oferece, então, um canal de comunicação confiável, sem perdas, erros, nem duplicação de mensagens. TP4 assegura ainda as funções de fragmentação e montagem de mensagens, o que permite que as mensagens trocadas neste nível sejam de qualquer dimensão.
A norma ISO 8326/27 foi adotada para a camada de Sessão, assegurando as funções de comunicação full-duplex e de resincronização.
Na camada de Apresentação, os problemas de representação de dados são resolvidos com a adoção da sintaxe abstrata ASN.1, que serve de linguagem comum às diferentes formas de representação dos dados, características de cada equipamento.
Dentre as funções oferecidas aos processos de aplicação, foram definidas, na camada de Aplicação, as seguintes normas:
• MMS, para a troca de mensagens entre equipamentos de produção;
• FTAM, para o acesso e a transferência de arquivos;
• RTOS, para a gestão de nomes (diretórios);
• funções de gerenciamento de rede, para a gestão de recursos, medição de desempenho e modificação dos parâmetros da rede.
A figura 1 apresenta as escolhas efetuadas a nível do projeto MAP, incluindo as versões EPA e Mini-MAP. Como a partir da versão 3.0 ocorreu uma unificação dos projetos MAP e TOP, a figura apresenta também as normas adotadas para a arquitetura TOP.
Especificação MAP/TOP 3.0
Figura 1. Especificação MAP/TOP 3.0
Arquitetura MAP-EPA
Dadas as necessidades específicas de cada nível hierárquico de uma empresa, verificou-se que a proposta MAP original não permitia cobrir todos os níveis considerados, sendo mais adequado aos níveis superiores. Uma razão principal disto é que, apesar da excelente qualidade dos serviços oferecidos, a arquitetura a sete camadas oferece um overhead que passa a ser indesejável nos níveis mais baixos das atividades de uma empresa.
Uma primeira solução a este problema foi a definição de uma versão simplificada da arquitetura MAP, denominada MAP-EPA (Enhanced Performance Architecture). A figura 2 apresenta a proposta MAP-EPA.
Esta proposta foi baseada na definição de duas planilhas de protocolos, a pilha normal Full-MAP e a pilha MAP-EPA, desprovida das camadas de Rede, Transporte, Sessão e Apresentação.
Do ponto de vista das camadas baixas, o protocolo IEEE 802.4 continuava sendo adotado, porém sob um suporte de transmissão em base band a 5Mbps.
Nesta arquitetura, um processo de aplicação tem a opção de enviar seus dados através da pilha normal ou, em casos onde o requisito seja um tempo de resposta rápida, pela pilha MAP-EPA. Evidentemente, o fato das camadas 3 a 6 estarem ausentes acarreta a perda dos serviços oferecidos por estas.
Arquitetura MAP-EPA
Figura 2. Arquitetura MAP-EPA
Arquitetura Mini-MAP
Uma terceira opção relacionada com a norma MAP foi a arquitetura Mini-MAP, baseada igualmente na supressão das camadas 3 e 6 para eliminar o overhead dos protocolos daquelas camadas. A arquitetura Mini-MAP é composta unicamente do segmento simplificado de MAP-EPA, e foi assim definida para evitar o alto custo das pilhas de protocolos paralelas de MAP-EPA. Esta nova proposta era dedicada aos níveis mais baixos, permitindo a comunicação em aplicações mais simples como, por exemplo, entre sensores inteligentes.
O fato de não possuir a camada de Transporte fez introduzir um protocolo de Enlace mais sofisticado que o da proposta MAP, o LLC tipo 3, datagrama com reconhecimento.
Os Serviços de Mensagem Industrial (MMS)
MMS (Manufacturing Message Services) foi normalizado pela ISO como sendo o conjunto de serviços de comunicação oferecidos às aplicações industriais, particularmente para viabilizar, dentro do ambiente OSI, as interações entre equipamentos de produção programáveis.
MMS é o resultado dos trabalhos realizados no contexto do projeto MAP, para definição de um conjunto de serviços de comunicação orientados às aplicações industriais.
A primeira proposta de MMS/RS-511 foi apresentada em junho de 1985, na forma de um documento organizado em duas partes:
Manufacturing Message Services: Definição dos Serviços;
Manufacturing Message Specification: Especificação do Protocolo.
Atualmente, MMS tornou-se norma internacional, fazendo parte da camada de Aplicação da versão 3.0 de MAP, publicada em agosto de 1988. Os dois documentos mencionados acima apresentam, de forma geral, como os serviços e o protocolo podem ser aplicados no contexto da utilização de um equipamento de produção genérico, sem levar em conta as particularidades de uma classe de equipamentos específica. Para complementar a norma existente, outros documentos foram e estão sendo produzidos, denominados normas de acompanhamento (Companion Standards) cujo objetivo é levar em conta a particularidade de cada equipamento, tais como robôs, máquinas de comando numérico, sistemas de visão, CLPs e os sistemas de controle de processos.
O objetivo de MMS é fornecer serviços de comunicação que permitam a um sistema aberto (no sentido OSI) acessar os recursos existentes em outros sistemas abertos conectados à rede de comunicação. Eles permitem cobrir grande parte das necessidades de comunicação entre de sistemas de produção, como, por exemplo, o carregamento remoto de programas, o controle remoto de um equipamento, a elaboração de relatórios de produção, etc.
Os programas escritos pelos programadores de aplicação vão acessar (direta ou indiretamente) as primitivas de serviço MMS, que vão manipular objetos virtuais representando os recursos reais disponíveis num equipamento de produção distante.
Projeto TOP
Com objetivos semelhantes ao MAP, foi desenvolvido pela Boeing a partir de 1983 o projeto TOP (Technical and Office Protocol), voltado à redes de automação de áreas técnicas e administrativas. Também é baseado no modelo OSI de 7 camadas e tem como finalidade fornecer aos usuários serviços tais como correio eletrônico, processamento de textos, acesso a base de dados, transferência de arquivos, CAD/CAM distribuído, troca de documentos, transações bancárias, etc.
A partir de 1986 os projetos MAP e TOP passaram a ser coordenados conjuntamente (projeto MAP/TOP).
Comentários
Apesar do MAP possuir vantagens, sua utilização está entrando em desuso e dentre os principais motivos, pode-se destacar:
Esta especificação atende bem os requisitos de comunicação nos níveis superiores da hierarquia porém, por ser uma estrutura robusta, torna o tempo de resposta (200 a 400ms) muito alto quando da necessidade de real-time;
Os níveis inferiores da hierarquia caracterizam-se pela existência de uma grande variedade e quantidade de equipamentos de controle, inviáveis de serem conectados pela arquitetura MAP pelo custo da interface entre eles.
Nenhum comentário:
Postar um comentário