Estudo Dirigido: TeleManufatura Aplicada a Operações de Usinagem

Alberto José Álvares¹

List of Tables

GLOSSÁRIO

DAS ABREVIATURAS E ACROGRAMAS ADOTADOS NO TEXTO

SIGLA	INGLÊS	PORTUGUÊS
AI	Artificial Intelligence	Inteligência Artificial
API	Application Programming Interface	Interface de Programação de Aplicação
BD	DataBase	Base de Dados ou Banco de dados
B-Rep	Boundary Representation	Representação de Fronteira
CAD	Computer Aided Design	Projeto Assistido por Computador
CAM	Computer Aided Manufacturing	Manufatura Assistida por Computador
CAPP	Computer Aided Process Planning	Planejamento de Processo Assistido por Computador
CGI	Comun Gateway Interface	Interface de Porta Comum
CNC	Computer Numerical Control	Comando Numérico Computadorizado
CSCW	Computer Support Cooperative Work	Trabalho Cplaborativo Suportado por Computador
CSG/DSG	Constructive/Destructive Solid Geometric	Geometria Sólida Construtiva/Destrutiva
GUI	Graphical User Interface	Interface gráfica para usuário
DBMS	Database Management System	Sistema de Gerenciamento de Banco de Dados
DXF	Data Exchange Format	Formato de Troca de Dados
FTP	File Transfer Protocol	Protocolo de Transferência de Arquivo
GT	Group Tecnology	Tecnologia de Grupo
HTML	Hiper Text Markup Language	Linguagem de Hipertextos
HTPP	Hypertext Transfer Protocol	Protocolo de Transferência de Hipertexto
IGES	Initial Graphics Exchange Specification	Especificação de Intercâmbio de Gráficos Inicial
IP	Internet Protocol	Protocolo Internet
JDBC	Java Database Connectivity	Conectividade deBanco de Dados
JDK	Java Development Kit	Kit de Desenvolvimento Java
JVM	Java Virtual Machine	Máquina Virtual Java
KBE	Knowledge Based Engineering	Engenharia Baseada no Conhecimento
MIME	Multipurpose Internet Mail Extensions	Extensões Multipropósito para Correio na Internet
NC	Numerical Control	Comando Numérico
NTSC	National Television Standards Committee	Comitê Nacional de Padrões de Televisão
ODBC	Open Database Connectivity	Conectividade de Banco de Dados Abertos
OODB	Object Oriented Database	Banco de Dados Orientado a Objetos
PC	Personal Computer	Computador Pessoal
PDES	Product Data Exchange using STEP	Intercâmbio de Dados de Produto usando STEP
PDM	Product Data Management	Gerenciamento de Dados de Produto
RDBMS	Relational Database Management System	Sistema de Gerenciamento de Banco de Dados Relacional
SQL	Structured Query Language	Linguagem de Pergunta Estruturada
STEP	Standard Exchange of Product Model Data	Padrão de Intercâmbio de Dados do Modelo do Produto
TCP	Transmission Control Protocol	Protocolo de Transmissão Controle
UML	User Datagram Protocol	Protocolo de Datagramas de uUsuário
URM	Unified Modeling Language	Linguagem de Modelagem Unificada
URL	Uniform Resource Locators	Localizador de Recursos Uniforme
VRML	Virtual Reality Modeling Language	Linguagem de Modelagem de Realidade Virtual
WWW	World Wide Web	Rede Mundial de Computadores

1. Introdução

1.1 Considerações Iniciais

Esta disciplina de Estudo Dirigido, ``TeleManufatura Aplicada à Operações de Usinagem'', tem por objetivo dar subsídios ao desenvolvimento da tese de doutorado do aluno Alberto José Álvares nos aspectos referentes à manufatura remota baseada na Internet/Web. O tema de tese está associado ao desenvolvimento de ``Uma Metodologia para Integração CAD/CAPP/CAM Voltada para Manufatura Remota de Peças Rotacionais Simétricas Baseada na Internet (Web)", bem como a sua implementação computacional.

Esta é a segunda disciplina cursada como estudo dirigido a fim de completar os créditos refe-rentes ao seu doutoramento. Esta disciplina aborda os aspectos computacionais relacionados às linguagens de programação voltadas à Internet, basetypeset@protect @@footnote SF@gobble@opt Base de Dados pode também ser designado por Banco de Dados. Neste trabalho utiliza-se a terminologia Base de Dados. de dados relacional, shells de sistemas especialistas, sistemas multi-agentes, arquitetura cliente/servidor, sistemas distribuídos, lógica fuzzy, Unix, modelagem sólida utilizando Java e ACIS®, entre outras. Com estas duas disciplinas cursadas no formato de estudo dirigido, acreditá-se que grande parte dos aspectos referentes à revisão bibliográfica necessários ao exame de qualificação estarão cobertos. A data prevista para realização do exame de qualificação é Dezembro de 2002.

A ementa e o programa associados à disciplina são apresentados a seguir.

EMENTA: Internet e World Wide Web (WWW). Arquitetura Cliente/Servidor. Protocolos TCP/IP e HTTP. Aplicações em Java para a WWW. Java Server Pages (JSP), Servlets e Common Gateway Interface (CGI). Base de dados relacional (MySQL) e seu uso em aplicações WWW. Uso da WWW para projeto e manufatura. Exemplos e Análise de Aplicações em Telemanufatura: metodologias e arquiteturas desenvolvidas. Hardware para Telemanufatura: redes de computadores, máquina CNC com arquitetura aberta e proprietária, teleoperação e captura de imagem e vídeo (câmera web) Largura de banda de redes de computadores para telemanufatura. Metodologias de telemanufatura para operações de torneamento. Formato VRML para visualização remota de peças. Segurança em operações de telemanufatura. Sistemas Multi-Agentes (MAS) no Planejamento do Processo, e seu uso num ambiente WWW. Sistemas Especialistas em ambiente WWW. Metodologias e Sistemas CAD/CAPP/CAM Via Internet.

PROGRAMA:

Manufatura Remota e Manufatura Virtual.
TeleManufatura.
Internet e World Wide Web (WWW).
Formato VRML para visualização remota de peças.
Aplicações em Java para a WWW.
Orientação a Objetos.
Applets: AWT e Swing.
Java Server Pages (JSP), Servlets e Common Gateway Interface (CGI). Implementação de programas ilustrando a sua utilização.
Manufatura Remota: Teleoperação.
Arquitetura Cliente/Servidor. Protocolos TCP/IP e HTTP.
Metodologias e Sistemas CAD/CAPP/CAM Baseados na Web.
Hardware para Telemanufatura: redes de computadores, máquina CNC com arquitetura aberta e proprietária, teleoperação e captura de imagem e vídeo (câmera web).
Largura de banda de redes de computadores para telemanufatura.
Uso da WWW para projeto e manufatura.
Exemplos e Análise de Aplicações em Telemanufatura: metodologias e arquiteturas desenvolvidas.
Metodologias e Sistemas CAD/CAPP/CAM Via Internet.
Sistema de Telemanufatura WebOxiCorte.
Segurança em operações de telemanufatura.
Ferramentas Computacionais para CAPP,
Base de dados MySQL, e seu uso em aplicações WWW. Exemplos de sua utilização.
Sistemas Especialistas em ambiente WWW.
Sistemas Multi-Agentes (MAS) no Planejamento do Processo, e seu uso num ambiente WWW.
Metodologias de telemanufatura.
Implantação de uma infra-estrutura computacional para desenvolvimento de atividades de CAD/CAPP/CAM. Instalação de gerenciadores de bases de dados, servidor Web, shell para sistemas especialistas, sistema CAD/CAM.

1.2 Bibliografia Consultada

Para realização deste estudo dirigido foi consultado uma grande quantidade de material bibliográfico disponível em diversas mídias (journals on-line/Internet, journals impressos, livros, teses e dissertações on-line e impressas, sites da Internet, etc). O material consultado através de arquivos (pdf, html, txt, doc, etc) está disponível em: ftp://omega.enm.unb.br/pub/doutorado. Este servidor armazena cerca de cinco gygabytes de informações de interesse para o doutorado, tanto para esta disciplina quanto para a primeira disciplina de estudo dirigido.

A seguir é apresentada a bibliografia básica definida no programa da disciplina:

D.C. Comer, "Redes de Computadores e Internet", Bookman, 2a Edição, 1999.
D.K. Fields, M.A. Kolb e S.Bayern, "Web Development with Java Server Pages", Manning, 2a. Edição, 2001.
C.S. Horstmann e G. Cornell, "Core Java 2 - Volume 1 - Fundamentos", Makron Books, 2000.
C.S. Horstmann e G. Cornell, "Core Java 2 - Volume 2 - Recursos Avançados", Makron Books, 2000
B. Eckel, "Thinking in Java", Prentice-Hall, 2a. Edição, 2000.
J. Ablan, "Developing Intranet Applications with Java", Sams.net Publishing, 1a. Edição, 1998.
S. Zeiger, "Servlet Essentials", http://www.novocode.com/doc/servlet-essentials.
A. Mills, "Collaborative Engineering and the Internet: Linking Product Development Partners Via the Web", SME, 2001.
Telemanufatura de Peças Prismáticas Baseado na Web, http://cybercut.berkeley.edu.
Projeto Cooperativo Baseado na Web, http://www.WebSpiff.org.
``Manufacturing on the Internet: Use 21st Century Techniques to Speed Your Product Cycles", John Wiley & Sons, 2a. Edição, 1997.
Corny, J. Lim, T., ``3D Modeling with ACIS'', Saxe-Coburg Publications, 2a. Edição, 2001.
Shah, J.J. e Mäntÿla, M., "Parametric and Feature-Based CAD/CAM", John Wiley & Sons, 1a Edição, 1995.

1.3 Estrutura do Documento Escrito

Após discussão com o Prof. João Carlos Espíndola Ferreira sobre o conteúdo a ser apresentado neste documento, definiu-se que deveria ter como escopo os aspectos referentes à Telemanufatura, que é um assunto básico na pesquisa de Doutorado. Este trabalho apresenta um levantamento dos trabalhos sendo feitos nesta área, tanto na área de software como de hardware, visando aplicação destas tecnologias no trabalho.

A fim de se ter um estrutura lógica, este relatório é dividido em nove capítulos que cobrem todos os aspectos que compõem o programa da disciplina.

O capítulo dois apresenta uma introdução à Manufatura Remota e à Manufatura Virtual baseada na Internet/Web descrevendo seus conceitos, arquiteturas e suas funções básicas.

O capítulo três apresenta uma revisão sobre a tecnologia Internet, em especial as ferramentas de desenvolvimento voltadas para web.

O capítulo quatro discute a Manufatura Remota apresentando vários sistemas de teleoperação desenvolvidas pelo doutorando na Universidade de Brasília.

O capítulo cinco aborda metodologias e sistemas CAD/CAPP/CAM baseados na Web onde normalmente se utiliza da tecnologia de Projeto por features, sendo as features de projeto e manufatura os elemento de integração entre o projeto e a manufatura.

O capítulo seis apresenta um sistema de Telemanufatura desenvolvido pelo doutorando voltado para o processo de Oxi-corte. Este sistema, denominado de WebOxiCorte, demonstra a filosofia de integração CAD/CAPP/CAM tanto no nível de planejamento e desenvolvimento de produto (geração do código G) quanto no nível de chão-de-fábrica (teleoperação da máquina de comando numérico) a partir da Web.

O capítulo sete apresenta algumas ferramentas computacionais utilizadas no CAPP, derivadas de técnicas de representação do conhecimento e abordagens clássicas.

O capítulo oito descreve algumas ações que foram desenvolvidas para implantação de infra-estrutura computacional para o desenvolvimento das atividades de CAD/CAPP/CAM nas ins-talações físicas do GRIMA (Grupo de Integração da Manufatura). O capítulo nove apresenta as conclusões do trabalho desenvolvido.

2. Manufatura Remota e Manufatura Virtual

Este capítulo apresenta uma discussão sobre Manufatura Remota e Virtual, apresentando conceitos de Realidade Virtual e Teleoperação. O capítulo é baseado em vários projetos e trabalhos publicados pelo doutorando e em um projeto de pesquisa integrado que está sendo desenvolvido pela Rede de Automação da Manufatura (Manet), pertencente à Recope, denominado ``Desenvolvimento de um Sistema Inteligente de Produção com Gestão Remota Via Internet'' (MANET, 2002).

2.1 Manufatura Remota

Segundo MALEK et al. (1998) TeleManufatura ou Manufatura Remota pode ser definida como uma atividade onde uma empresa (cliente) utiliza serviços oferecidos por Centros Especializados (servidores) disponibilizados via rede de comunicação através das supervias da informação (Internet) para executar, em tempo real, operações e processos necessários para o projeto e a produção de bens. Desta forma atividades relativas a TeleManufatura estão presentes em todo o ciclo de desenvolvimento do produto, desde a concepção do produto até a sua fabricação e distribuição (figura 2.1).

**Figure 2.1:** Taxonomia da TeleManufatura (MALEK *et al.* , 1998).
$\resizebox*{13cm}{9cm}{\includegraphics{fig/fig2_1.ps}}$

Atualmente já existem empresas com alto nível de especialização que oferecem serviços em um ambiente voltado para TeleManufatura. Estes centros especializados detêm o estado da arte na Tecnologia de Software (Sistemas CAE/CAD/CAPP/CAM/ERP entre outros), especialidades avançadas e acesso às informações atualizadas em seus campos a fim de auxiliar seus clientes no desenvolvimentos de novos produtos e processos (AHN et al. , 1999 e MALEK et al. , 1998). Sistemas como o CyberCut da Universidade de Berkeley (http://cybercut.berkeley.edu) possibilitam a concepção de uma peça prismática que será usinada utilizando-se de um sistema CAD/CAPP/CAM desenvolvido em Java (BROWN e WRIGHT, 1998). Outro exemplo foi desenvolvido por ÁLVARES et al. (2001) onde o sistema permite a teleoperação de uma máquina de Oxi-Corte CNC, bem como, a geração do programa NC da peça a ser produzida utilizando um ambiente de modelagem CAD/CAM desenvolvido na linguagem Java (http://weboxicorte.graco.unb.br), denominado de WebOxiCorte.

A empresa e-Manufacturing Networks (http://www.e-manufacturing.com) é uma da primeiras empresas focada em soluções a partir de TeleManufatura baseada em Web. A seguir é apresentado uma pequena descrição da empresa obtida de seu site: ``e-Manufacturing Networks permits manufacturers to web enable their factory floor and InterNetwork to Management Information Systems and trading partners. We are the first company to focus on using Ethernet connectivity to make every machine tool, of all makes, a node on the corporate network, and accessible through the Internet. e-Manufacturing Networks unlocks for manufacturers, real-time factory floor Information that is fundamental to gaining a competitive advantage.''

Assim sistemas de Teleoperação de equipamentos industriais enquadram-se no contexto de TeleManufatura (MALEK et al. , 1998) nos aspectos referentes ao controle da manufatura em operações de chão de fábrica (figura 2.1), bem como, ambientes computacionais integrados de CAD/CAPP/CAM para desenvolvimento de produto. Estes sistemas e ambientes de suporte ao desenvolvimento de produto e de teleoperação estão sendo atualmente disponibilizados através da Internet/Intranet sendo baseados nos protocolos de desenvolvimento para Web.

O ambiente de TeleManufatura é normalmente baseado em uma arquitetura Cliente/Servidor, que trabalha de forma interativa e cooperativa, solicitando e provendo serviços, bem como comparti-lhando recursos de forma distribuída (MONACO e GONZAGA, 1999; KAO e LIN, 1996; PRANDHAN e HUANG, 1998 e ADAMCYK e KOCIOLET, 2001). Sistemas de Teleoperação voltados para aplicações em Robôs Industriais e Robôs Móveis são descritos em ÁLVARES et al. (1998; 1999, 2000 e 2001). Em ÁLVARES et al. (1999) é apresentada uma metodologia para desenvolvimento de Sistemas Teleoperados via Internet.

2.2 Manufatura Virtual

É necessário fazer uma distinção do conceito de Manufatura Remota (TeleManufatura), que será utilizado no desenvolvimento do trabalho de doutorado, dos conceitos de Manufatura Virtual e Empresa Virtual que muitas vezes são confundidos.

De acordo com BANERJEE & ZETU (2001), o termo Manufatura Virtual passou a ser utilizado no início dos anos 90, em parte como resultado da iniciativa do Departamento de Defesa dos EUA, pois a evolução tecnológica propiciaria o desenvolvimento da capacidade de se confirmar a manufaturabilidade dos novos sistemas de armas antes de comprometer recursos na sua produção. Até metade dessa década, alguns trabalhos pioneiros nesse campo foram realizados por algumas organizações, principalmente a empresa aeroespacial e a indústria automobilística, além de ser abordado como tema em alguns grupos de pesquisa acadêmica.

Manufatura Virtual pode ser usada em uma grande variedade de contextos de sistemas de manu-fatura, e pode ser definida como a modelagem destes sistemas e de componentes com o uso efetivo de computadores e de dispositivos audiovisuais e/ou sensoriais para simular ou projetar alternativas para um ambiente de manufatura, visando, principalmente, prever problemas potenciais e ineficiências na funcionalidade e manufaturabilidade do produto antes que a manufatura real ocorra, ou seja, ela visa definir um novo método de desenvolvimento do produto através da integração funcional das ferramentas computacionais disponíveis, figura 2.2.

**Figure 2.2:** Paradigmas da Manufatura Virtual Fonte: PORTO & PALMA (2000).
$\resizebox*{13cm}{10cm}{\includegraphics{fig/fig2_2.eps}}$

A Manufatura Virtual pode também ser definida, conforme LAWRENCE ASSOCIATES INC (1994), como ambiente de manufatura sintético, integrado, que utiliza todos os níveis de decisão e controle no projeto de produto e processo, planejamento de processo, planejamento de produção e controle de chão de fábrica, onde:

Ambiente: é o suporte para a construção e uso da simulação da manufatura distribuída, pela sinergia provinda de uma coleção de ferramentas de análise, de simulação, de implementação, de controle, modelos (produto, processo, recurso), equipamentos, metodologias e princípios organizacionais.
Sintético: uma mistura do real com objetos, atividades e processos simulados.
Exercido: executar a simulação da manufatura utilizando o ambiente.
Melhorar: aumentar o valor, precisão e validade.
Níveis: do conceito do produto à sua disponibilização, do chão de fábrica à comitiva executiva, do equipamento de fábrica ao empreendimento e além da transformação de material à transformação de conhecimento.
Controle: predizer os efeitos reais.

A Empresa Virtual é uma rede multi-disciplinar, rapidamente configurável, de pequenas empresas configuradas para projetar e produzir um produto específico (LIN et al. , 1995). Pode ser definida como um consórcio temporário de empresas que juntam competências e recursos, suportados por redes de computadores, para melhor responder às oportunidades de mercado (CAMARINHA-MATOS, 1998), podendo inclusive utilizar-se de conceitos de telemanufatura onde as empresas com maior competência, em determinadas áreas, disponibilizam serviços especializados para as demais empresas, ajudando-as no desenvolvimento de produtos.

Cerca de 70% do custo de um produto é representado pelo seu estágio de projeto. Sob o ponto de vista do ciclo de vida de um produto, o conceito de manufatura virtual proporciona aos profissionais relacionados ao projeto, processo e produção a capacidade de validação de seus projetos, planos de processos associados e planos operacionais em relação à viabilidade técnica e custos. A noção fundamental em Manufatura Virtual é a de um ambiente simulado de desenvolvimento de produto, o qual possibilita que o mesmo possa ser "fabricado virtualmente" antes de ser "fabricado de fato". Simulações realizadas no ciclo de vida das peças proporcionam dados precisos que impedem o desenvolvimento de um projeto que é difícil ou impossível de ser fabricado.

As áreas funcionais do ciclo de vida de produto na Manufatura Virtual incluem a interface homem-máquina (visualização), projeto de produto, desenvolvimento de processo, produção e controle de chão de fábrica.

Empresas Virtuais buscam o compartilhamento de especialistas, tecnologias, recursos e lucros para alcançar agilidade, ou seja, capacidade de prosperar em um meio em constante modificação, com um comportamento de difícil previsão (CAMARINHA-MATOS, 2000; VASILASH, 1993; HILTON & GILL, 1994). A troca de informações entre parceiros através de uma estrutura de rede de comunicação de dados é uma questão crítica para o sucesso de tais empresas. Os parceiros, em uma empresa virtual, devem compartilhar informações sobre produtos, processos e produção. Esta informação deve ser representada na forma de dados, conhecimentos e/ou modelos, podendo ser distribuída para diferentes ambientes computacionais.

Para a efetiva implantação de uma estrutura de Manufatura Virtual, os principais aspectos a serem considerados incluem:

Suporte para o projeto conceitual auxiliado por computador. Ferramentas de software devem ser desenvolvidas para suportar a manipulação de funções e conceitos, antes de sua realização como geometria (domínio do CAD tradicional);
Integração além domínios da manufatura tradicional. A integração deve ser possível através de todo o espectro dos sistemas de projeto e manufatura e através de todos os parceiros na empresa. Isto implica em planejamento para a manufatura utilizando múltiplos processos, seleção de processos ótimos, integração do planejamento do processo com o controle de chão-de-fábrica;
Modularização na representação de informações de recursos de manufatura e interfaces comuns entre os sistemas de manufatura (softwares). Isto implica na utilização de um modelo de arquitetura aberta, o qual possibilite o acesso às estruturas de dados e representações.

2.2.1 Trabalho Cooperativo

O Trabalho Cooperativo, também denominado de ``Colaborativo''typeset@protect @@footnote SF@gobble@opt Neste Trabalho será utilizado o termo Cooperativo traduzido do Inglês Collaborative. O vocábulo ``Colaborativo'' não está presente em nossa língua. A fim de não criar um neologismo não será utilizado o termo ``Colaborativo''. , como item parte integrante da estratégia de implantação de uma estrutura de Manufatura Virtual envolve conceitos de Realidade Virtual, em ambientes compartilhados, proporcionando aplicações de Teleoperação, Telerobótica e Telepresença, além de uma infra-estrutura de Rede de Alta Velocidade. Estes temas são discutidos a seguir.

2.2.2 Realidade Virtual e VRML

O termo Realidade Virtual (RV) pode ser interpretado como uma forma avançada de interface do usuário de computador (HANCOCK, 1995), a qual tem aplicação na maioria das áreas do conhe-cimento. Pode também ser definida como uma técnica avançada de interface, onde o usuário pode realizar imersão, navegação e interação em um ambiente sintético tridimensional gerado por computador, utilizando canais multi-sensoriais (JACOBSON, 1994; KRUEGER, 1991). A interface com realidade virtual envolve um controle tridimensional altamente interativo de processos computacionais, onde o usuário entra no espaço virtual das aplicações e visualiza, manipula e explora os dados da aplicação em tempo real, usando seus sentidos, particularmente os movimentos natu-rais tridimensionais do corpo. A grande vantagem desse tipo de interface é que o conhecimento intuitivo do usuário a respeito do mundo físico pode ser transferido para manipular o mundo virtual. Um sistema de realidade virtual envolve estudos e recursos ligados com percepção, hardware, software, interface do usuário, fatores humanos, e aplicações (BISHOP, 1992).

De maneira geral, pode-se considerar o conceito de realidade virtual como sendo composto por três conceitos chave, os quais coexistem: imersão, interação e envolvimento (MORIE, 1994).

A Realidade Virtual, por sua vez, também é uma tecnologia chave no desenvolvimento do produto e processo. A RV pode ser definida como "a habilidade em criar e interagir no espaço cibernético, isto é, um espaço que representa um ambiente com muita similaridade ao ambiente em torno de nós" (BANERJEE & ZETU, 2001).

De fato, realidade virtual e simulação são componentes em diferentes áreas, incluindo a Manufatura Virtual, mas há diferenças entre elas. Ambas, simulação e realidade virtual, são ferramentas que podem ser usadas para análise e teste de materiais, treinamento de pessoas de diversas maneiras, e o projeto e implementação de novas idéias e conceitos.

Uma distinção importante entre elas é como os usuários operam a tecnologia. A realidade virtual freqüentemente requer mais interação física da parte do usuário, enquanto a simulação tipicamente é mais passiva. A realidade virtual é um processo táctil, incorporando luvas, controle "joysticks", telas em capacetes, óculos estéreos 3D, e paredes e telas para projeção de vídeo. Simulação envolve software de visualização com gráficos de alta resolução, usando modelos CAD 3D, operando em estações gráficas de alto desempenho. Ambas podem ser usadas em conjunto por projetistas e engenheiros para criar praticamente qualquer tipo de mundo artificial imaginável. Nestes ambientes digitais, muitos tipos de situações do mundo real, variáveis, e reações podem ser duplicadas.

A Realidade Virtual tem sido usada por companhias tais como General Motors e Caterpillar para construir protótipos eletrônicos de veículos, ao invés de protótipos físicos, reduzindo significantemente o tempo de desenvolvimento do produto. PENG, HALL e LISTER (2000) apresentam um sistema CAPP Generativo baseado em Realidade Virtual (VR) voltado para o processo de usinagem.

A vantagem principal dessa tecnologia é o desenvolvimento e análise do projeto cooperativo, habilitando grupos de engenheiros a visualizar e manipular, em tempo real, um objeto virtual tão facilmente como eles poderiam fazer com um objeto físico.

A figura 2.3 mostra o relacionamento usuário/ambiente em sistemas que utilizam interfaces não convencionais.

**Figure:** Relacionamento Usuário / Ambiente (KIRNER, 2001).
$\resizebox*{11cm}{6cm}{\includegraphics{fig/fig2_3.ps}}$

O Ambiente Virtual difere do Sistema de Telepresença na atuação sobre o ambiente. Enquanto a telepresença faz com que a interface atue sobre um telerobô que vai atuar sobre o mundo real, o sistema de realidade virtual faz com que a interface atue diretamente sobre o computador que vai atuar sobre um mundo virtual ou um mundo real simulado. Em telepresença e em outros casos, onde possa haver dificuldades de transferência ou tratamento em tempo real de imagens reais complexas, a substituição do mundo real por um mundo virtual equivalente pode resolver o problema, na medida em que as imagens podem ser geradas localmente. As transferências de informações podem ser reduzidas a dados de posicionamento.

Um Sistema de Realidade Aumentada é uma combinação da visão do ambiente real com o ambiente virtual (AZUMA, 1993; BOMAN, 1995; FEINER, 1993). Esse tipo de sistema é obtido mesclando-se sistemas de telepresença e realidade virtual, como mostrado na figura 2.4.

**Figure 2.4:** Realidade Aumentada (DURLACH & MAVOR, 1995).
$\resizebox*{11cm}{9cm}{\includegraphics{fig/fig2_4.ps}}$

Um Sistema de Realidade Melhorada é uma variação do sistema de realidade aumentada, onde um sistema de processamento de imagem gera informações adicionais para serem sobrepostas à imagem real. O resultado final pode ser tanto uma melhoria espectral quanto espacial, gerando transformações e anotações sobre a imagem. A geração de imagens obtidas através de ampliação do espectro visível do olho humano e a anotação de características específicas dos objetos como distância, tipo, etc., são exemplos de melhoria de uma imagem (BOWSKILL & DOWNIE, 1995). Um exemplo de um sistema deste tipo é mostrado na figura 2.5.

**Figure:** Sistema de Realidade Aumentada Baseado em Vídeo (KIRNER, 2001).
$\resizebox*{10cm}{6cm}{\includegraphics{fig/fig2_5.ps}}$

A modelagem geométrica abrange a descrição da forma dos objetos virtuais através de polígonos, triângulos ou vértices, e sua aparência, usando textura, reflexão da superfície, cores, etc. A forma poligonal dos objetos pode ser criada, usando-se bibliotecas gráficas ou usando-se modelos prontos de bases de dados comerciais ou digitalizadores tridimensionais. Os objetos também podem ser criados por programas CAD ou com o uso de editores de realidade virtual. A aparência dos objetos está relacionada principalmente com as características de reflexão da superfície e com sua textura.

A modelagem geométrica de um objeto não é suficiente para conseguir uma animação. Para isto, deve ser possível agarrar o objeto, alterar sua posição, mudar a escala, detectar colisões e produzir deformações na superfície. A utilização de coordenadas locais dos objetos e de coordenadas gerais, juntamente com matrizes de transformação, permitirão a alteração das posições e as mudanças de escala (ROBINET & HOLLOWAY, 1992).

Os objetos virtuais também deverão ser modelados fisicamente pela especificação de suas massas, pesos, inércia, texturas (lisas ou ásperas), deformações (elásticas ou plásticas), etc. Essas características, em conjunto com a modelagem geométrica e com as leis de comportamento, determinam uma modelagem virtual próxima da realidade. A simulação mecânica do mundo virtual, para ser realista, deverá ser executada de maneira confiável, contínua, automática e em tempo real.

A modelagem geométrica e física de mundos virtuais com muitos objetos deverá resultar em um modelo muito complexo, difícil e caro de ser mostrado. Normalmente, esses mundos possuem vários espaços específicos, distâncias razoáveis e objetos móveis com velocidades diferentes. O problema da complexidade pode ser contornado por segmentação do mundo, alteração do nível de detalhe dos objetos, alteração de resolução de imagens, pré-computação, etc.

A segmentação do mundo baseia-se na divisão do mundo geral em mundos menores, de forma que somente os objetos do mundo menor sejam mostrados. É o caso de uma casa com diversas salas, onde cada sala é um mundo menor. Embora o mundo geral seja muito complexo, a visão do usuário sempre será mais simples.

Uma abordagem semelhante é usada para cenas de movimentação. Objetos que estejam movendo-se rapidamente, não conseguem ser vistos claramente. Assim pode-se representar os objetos rápidos de maneira simplificada, conseguindo o mesmo efeito e economizando processamento.

2.2.3 VRML

VRML (Virtual Reality Modeling Language) é uma linguagem independente de plataforma que permite a criação de cenários 3D, por onde se pode ``passear'', visualizar objetos por ângulos dife-rentes e interagir com eles. A linguagem tem como objetivo dar o suporte necessário para o desenvolvimento de mundos virtuais tridimensionais multi-usuários na Internet. O código VRML é um subconjunto do formato de arquivo ASCII do Open Inventor, da Silicon Graphics, com características adicionais para navegação na Web.

Para navegar em mundos virtuais criados com a linguagem é necessário o uso de browsers que suportem VRML. Assim, ao invés de visitar homepages, pode-se visitar homeworlds. Existem muitos browsers disponíveis que suportam diretamente a linguagem. Outros browsers que não suportam necessitam de software adicional (plug-in).

No contexto da Manufatura, VRML é um mecanismo de visualização de representações geométricas de diversas entidades relacionadas. Em conjunto com uma Interface Visual, dados de manufatura podem ser acessados, utilizando representações 3D. Os objetos VRML atuam como interface para a base de dados da manufatura.

2.2.4 Laboratório Virtual

Um Laboratório Virtual é um meio heterogêneo e distribuído de resolução de problemas que permite a um grupo de pesquisadores de diversos lugares no mundo trabalharem em um conjunto comum de projetos. No projeto e manufatura, uma empresa envolvida na produção de um produto grande e complexo, tal como um avião, deve ser capaz de simular processos diretamente para interagir com as bases de dados de projeto as quais contém especificações técnicas e de manufatura.

Os componentes de um laboratório virtual incluem:

Bases de dados que contenham informações de aplicações específicas tais como a simulação inicial e condições de contorno, observações experimentais, requisitos de clientes, além de recursos distribuídos específicos;
Instrumentos científicos que são conectados à rede;
Ferramentas cooperativas, incluindo tele-imersão;
Software: para simulação, análise de dados, redução e visualização;
Serviços de reserva de banda.

2.3 Teleoperação

Existem diversas situações em que a operação de um determinado dispositivo deve ser realizada através de um operador remoto, o qual encontra-se fisicamente distante do objeto de controle. Estes dispositivos remotamente operados vem sendo utilizados em diversas áreas tais como robótica, medicina, pesquisa submarina, etc (ADAM, 1985 e WITHAM et al. , 1985).

Geralmente, uma tarefa de manipulação remota requer uma máquina de propósito geral que possa realizar uma variedade de manipulações físicas. Muitas destas tarefas são altamente variáveis. As tarefas remotas variam em termos do local onde a tarefa tem que ser realizada e se a tarefa é conhecida a priori. Um sistema ideal para realizar estas tarefas tem que ter a mesma capacidade de um operador humano para reconhecer qual tarefa tem que ser realizada e quais passos devem ser tomados para sua realização, além de possuir flexibilidade para realizar manipulações físicas, de maneira análoga à operação de um humano.

Na prática, a maioria dos sistemas que realizam manipulação remota estão longe desta situação ideal. Necessitam, consequentemente, da capacidade humana para decidir qual tarefa deve ser realizada e para ensinar ao dispositivo como realizá-la. Como nestas situações não é possível a presença do operador humano no local em que se encontra o dispositivo, o que acontece é que o operador acaba indiretamente realizando a tarefa através de uma máquina teleoperada.

Quando o operador está fisicamente presente no local e realiza uma tarefa diretamente no disposi-tivo controlado, ele recebe diversos tipos de sinais de realimentação do resultado de suas ações, tais como realimentação visual, auditiva, táctil, de força, etc. Além disso, ele necessita, constantemente, mudar sua posição de observação para obter melhor informação de realimentação visual. Quando, por outro lado, o operador está fisicamente distante do dispositivo controlado e realiza alguma tarefa de manipulação, a realimentação de suas ações de controle tem que ser artificialmente transmitidas a ele. As informações mais relevantes do local remoto são capturadas através de sensores, enviadas ao operador e reproduzidas, proporcionando a realimentação necessária à tarefa de controle. A figura 2.6, mostra, esquematicamente, uma configuração típica para manipulação remota.

**Figure:** Configuração Típica para Manipulação Remota (THESYS, 2001).
$\resizebox*{14cm}{10cm}{\includegraphics{fig/fig2_6.ps}}$

Nesta configuração, o dispositivo deve ser flexível o bastante para seguir os comandos de manipulação enviados pelo operador. Para isto, existem sensores no site remoto os quais são montados no dispositivo a ser controlado, fornecendo dados de realimentação necessários ao operador para que o sistema funcione em malha fechada. O número de sensores e o tipo de informação sensoreada varia com a tarefa a ser realizada, mas no mínimo uma câmera de vídeo deve estar presente, para que o operador possa visualizar o site diretamente. Estes sinais de sensores são transmitidos através de um link de comunicação e mostrados na interface do operador.

Um sistema de teleoperação tem vários componentes e requer conhecimento de muitas áreas dife-rentes. Diversos métodos de comunicação são utilizados para transmitir dados entre o site remoto e o site local, do operador, dependendo do meio de atuação do dispositivo controlado. Um dos componentes mais importantes de um sistema teleoperado é a interface do operador, já que determina a extensão daquilo que o operador pode sensorear no ambiente remoto e, consequentemente, controlar no manipulador. O display na interface do operador deve ser projetado de tal maneira que o operador receba informação suficiente a respeito do meio remoto. O controlador na interface do operador tem que ser projetado para que o operador possa, efetivamente, controlar o dispositivo (DRASCIC, 1991).

Aspectos importantes no efetivo controle de dispositivos remotos envolvem: o atraso entre uma ação de controle do operador e sua correspondente visualização, como informação de realimentação de sua ação, mostrada em seu display; largura de banda do sistema de comunicação, que determinam uma parcela importante do atraso relacionado à ação de controle; experiência na tarefa de controle contínuo, manual, do dispositivo controlado; questões de segurança e erros de posicionamento e autonomia (SHERIDAM, 1993; MASSIMINO, 1994, MCKINNON, 1988; STURGES, 1991; PETERS, 1988).

A questão da autonomia é particularmente importante, já que define o quanto o dispositivo teleoperado pode funcionar independentemente do operador humano. Isto pode ser obtido através da implementação de parte da estratégia de controle em um computador localizado no site remoto, como mostrado na figura 2.7. O operador pode estabelecer altos níveis de controle ao computador remoto, o qual pode executar os níveis mais baixos de controle.

**Figure:** Um sistema de teleoperação com um loop de execução remoto (SHERIDAN, 1992).
$\resizebox*{14cm}{8cm}{\includegraphics{fig/fig2_7.ps}}$

2.3.1 Telerobótica

Sistemas robóticos teleoperados vem sendo utilizados em diversos campos tais como automação da manufatura, exploração espacial, aplicações militares, etc. A principal vantagem associada a tais sistemas é que permitem que certas tarefas possam ser executadas sem que o operador esteja presente no local de execução das mesmas.

A Telerobótica pode ser considerada uma sub-área da Teleoperação e consiste na operação remota de robôs utilizando-se de um link de comunicação. Com a utilização crescente da Internet para tais aplicações, o termo mais comumente utilizado é o de Web Robots ou Internet Robots. Diversas aplicações vem sendo desenvolvidas, em diversas áreas: Robôs Móveis, Manipuladores, etc. (HIRZINGER et al. , 1997; WOLF & FREITZHEIN, 1997).

O controle e monitoração remota de máquinas permite o compartilhamento de recursos, de tal maneira que uma planta de fabricação possa envolver equipamentos distribuídos em diversos locais ou até mesmo diversos países. Isto é possível através da utilização da Internet.

A vantagem do uso da Internet como meio de troca de informações em sistemas teleoperados reside na relativa simplicidade na qual a informação é transmitida. Serviços tais como FTP, TELNET, WWW, etc. são disponibilizados e amplamente acessados.

Sistemas controlados remotamente utilizam-se de comandos e dados do objeto controlado, os quais são transmitidos através de uma rede de comunicação de dados. Com a utilização da Internet, isto é feito através da utilização do Protocolo IP (WOLF et al. , 1997). A Arquitetura Cliente/Servidor, utilizando o protocolo HTTP, proporciona esta aplicação através de um Servidor WWW, como mostrado na figura 2.8.

**Figure 2.8:** Arquitetura Cliente/Servidor.
$\resizebox*{14cm}{11cm}{\includegraphics{fig/fig2_8.ps}}$

A estratégia de controle baseia-se em realimentação de informações através de imagens e/ou dados de sensores de força, posicionamento, entre outros (FIORINI et al. , 1993).

Os principais fatores a serem considerados na implementação de tais sistemas são descritos a seguir (TAYLOR & DALTON, 1997; HANNAFORD, 1999):

Confiabilidade: O robô deve estar disponível 24 horas por dia e 365 dias por ano, demandando manutenção mínima. O sistema deve ter mecanismos para contornar problemas de software e hardware;
Tempo de Resposta: Enquanto um operador está esperando por uma resposta do robô ele não pode submeter o próximo comando/requisição. Para minimizar este período de espera o tempo de resposta deve ser tão pequeno quanto possível. Este tempo é definido como:

$\begin{displaymath} tr=tp+(Ds+Dr)/V1+tc\end{displaymath}$

onde tp é o tempo de processamento da requisição, tc é o tempo para a inicialização da comunicação, Ds e Dr são os dados submetidos e recebidos e Vl é a velocidade de transmissão do link;
Fatores Humanos: O operador, em aplicações de controle a distância, passa a ser a parte central do loop de controle e seu comportamento deve ser um ponto importante no projeto do sistema de controle;
Projeto da Interface: Uma interface informativa e simples é essencial para que um telerobô possa ser de fácil uso e produtivo. A complexidade da cinemática, singularidades e vizi-nhanças do workspace do robô devem ficar "escondidos" do usuário, permitindo flexibilidade de operação.

Outra área de grande interesse, em telerobótica envolve a simulação de operações, baseada em realimentação de informações visuais (imagens) do workspace do robô. A extensão desta técnica permite a implementação da Telerobótica Virtual, a qual fornece ferramentas para interação on-line do usuário com o modelo do robô a ser controlado, antes de implementar, de fato, comandos para seu posicionamento (RASTOGI, MILGRAM & GRODSKI, 1999).

2.3.2 Telepresença

O conceito de grupos desempenha um importante papel no trabalho diário. A proximidade física facilita a interação entre membros do grupo. Em muitas empresas, grupos são distribuídos através de cidades e até países. Neste cenário, o principal desafio destas empresas é manter o conceito de "grupo", independente das distâncias envolvidas. O conceito de telepresença apresenta-se como importante ferramenta para tais propósitos (BUXTON, 1992).

O termo telepresença refere-se ao uso de tecnologia para estabelecer o sentido de presença compartilhada ou de espaço compartilhado entre membros de um grupo, geograficamente separados. Isto envolve o conceito de presença em dois espaços: o da pessoa e o da tarefa.

O espaço de pessoa em telepresença é o sentido coletivo de co-presença entre/através dos participantes do grupo. Isto inclui suas expressões faciais, voz, olhar e linguagem corporal. O espaço de tarefa permite a co-presença no domínio da tarefa sendo realizada. Em alguns casos, os espaços de tarefa e de pessoa são os mesmos

A implantação destes espaços e, de maneira mais ampla, da telepresença envolve ferramentas de videoconferência com técnicas de projeção, para obter efeitos de conversação mais realistas, além de dispositivos de compartilhamento de ferramentas de projeto (BUXTON, 1992).

A telepresença que é implementada por mecanismos de teleoperação, consiste de um usuário, uma interface homem-máquina, um telerobô e um ambiente remoto, conforme a figura 2.9.

**Figure:** Sistema de Telepresença.
$\resizebox*{13cm}{6cm}{\includegraphics{fig/fig2_9.ps}}$

2.4 Taxonomia: Laboratórios Virtuais e Remotos

Muitos cursos da engenharia, incluindo cursos de Controle e Automação da Manufatura, normalmente usam a Web para demonstrações de softwares, tutoriais e gerência básica do curso. Entretanto, a necessidade de aulas práticas em laboratório está levando ao desenvolvimento de duas modalidades de uso da Web na área de Ensino a Distância (EAD): Laboratórios Virtuais e Laboratórios Remotos. Este uso da Web voltado ao ensino pode também ser voltado para gestão e controle da produção usando a mesma metodologia em especial nos chamados Laboratórios Remotos que também podem ser designados de Plantas Industrias Remotas em um contexto de Telemanufatura e Manufatura Virtual.

As demonstrações por meio de software de conceitos abstratos podem ser muito benéficas para a compreensão dos usuários em um determinado assunto. Por exemplo, o índice da frequência em um sinal no domínio do tempo pode ser ilustrado eficazmente usando uma aproximação através de multimídia interativo. Os estudantes mudam a amplitude dos componentes nos espectros da freqüência e vêem a forma de onda do sinal resultante no tempo ao escutar um sinal de áudio correspondente. Estes tipos de demos podem ser usados em sala pelo instrutor ou ser vistos individualmente pelos estudantes. Antes da Web, tais demos eram desenvolvidos isoladamente em diversas instituições de ensino usando os pacotes de software comerciais disponíveis ou mesmo gratuitos. Demos podem ser passivos ou interativos. Os demos interativos podem ser classificados em duas categorias: aqueles que necessitam de download para a execução do software excutando na máquina local, e aqueles que funcionam diretamente na Web usando Java Applets.

Os laboratórios virtuais são simulações de dispositivos físicos por meio de software. Estes podem ser considerados demos interativos sofisticados. Os laboratórios virtuais podem ser uma bancada de testes de um sistema visando elaborar métodos para o seu controle, ou mesmo a simulação de um sistema de manufatura baseado em Teoria de Filas. Se a simulação for muito detalhada, pode ser um bom substituto para um laboratório real, especialmente se acompanhado de animação. Os laboratórios virtuais acessíveis através da Internet/Intranet estão se transformando em uma maneira popular para reduzir custos de equipamento e disponibilizar conceitos através do laboratório em cursos de EAD. Estes tipos de laboratórios usam geralmente softwares comerciais como o LabView, o MATLAB, o Arena, o AutoMod, Sistemas CAD/CAM, entre outros. Por exemplo, o laboratório virtual para ensino de Processamento de Sinais da Universidade de Carnegie Mellon (STONICK, 1993) e o laboratório CAD/CAM desenvolvido em Java da Universidade de Berkeley (cybercut http://cybercut.berkeley.edu) são utilizados em Ensino a Distância (EAD) em algumas disciplinas dos cursos de Graduação e Pós-Graduação destas Universidades.

Conceitualmente, usar um browser como interface para o laboratório virtual tem muitas vantagens em conexões Intranet e/ou Internet. É uma plataforma independente, fácil de usar (os estudantes já são familiarizados com as ferramentas de navegação para a Web) e o software adicional necessário no lado do cliente (usuário remoto) é mínimo. Entretanto, a conexão Web fornece alguns desafios também: necessita-se de meios para que o estudante incorpore os parâmetros do controle (que usam preferivelmente uma interface gráfica amigável) e de meios de simular a resposta do sistema. O código padrão do HTML não pode realizar todas estas tarefas.

As páginas interativas da Web com indicadores gráficos para dados de entrada (isto é, parâmetros de controle) podem ser escritas usando programas em Commom Gateway Interface (CGI) ou Java Applets. Os programas em CGI são os executáveis que residem no lado do servidor em um Arquitetura Cliente/Servidor, onde o browser e as aplicações em Java representam o cliente, por exemplo. Mais recentemente, Java Applets estão sendo usados como entrada de dados em uma aplicação da Web. Programas na linguagem Java diferem dos programas em CGI que residem no lado do servidor; pois Java Applets rodam no lado do cliente executando o código localmente. Também os programas em CGI não mantêm, geralmente, a conexão Internet persistentemente aberta, o que pode ser um impedimento em aplicações em tempo real.

Um exemplo de laboratório virtual localiza-se na Universidade de Edimburgo (MERRICK et al. , 1996), o qual busca demonstrar os conceitos básicos do controle do processo. O laboratório virtual consiste de diversos experimentos de controle do processo químico. Cada "experiência" é acompanhada por uma descrição da teoria junto com uma fotografia de um dado real. Os estudantes podem introduzir parâmetros de controle e então simular o sistema em malha fechada. Os gráficos dos resultados são indicados aos estudantes.

O MATLAB tem uma vantagem sobre Java pois pode executar cálculos sofisticados de uma maneira numericamente robusta. É também uma ferramenta computacional padrão na comunidade de Automação e Controle. MATLAB pode ser lançado dentro de um browser de forma similar às aplicações Realvideo e Acroread, necessitando de um plug-in adequado ao browser. Os exemplos dos laboratórios virtuais que utilizam MATLAB na máquina do cliente para finalidades de simulação são apresentados em (LEE et al. , 1998) e (SCHMID, 1998).

Os laboratórios remotos permitem que experimentos reais do laboratório sejam controlados remotamente através de uma conexão Internet via Web, por exemplo. Este tipo de laboratório é bem adequado aos cursos de EAD onde os estudantes não necessitam estar fisicamente no laboratório. Os parâmetros de controle podem ser ajustados em uma página Web e enviados para o servidor que controla o experimento. Os dados reais são gravados durante o experimento retornando ao usuário através da conexão Web.

Um método comum para executar o controle remoto do equipamento ou de um experimento é através de uma conexão remota via telnet (emulação de terminal) em um outro computador que esteja controlando um experimento, chamado de servidor. Entretanto, Uma desvantagem deste método é a necessidade de uma conta no servidor além da ausência de uma interface gráfica, pois sendo textual ela é pouco amigável. A utilização de terminais gráficos (Xfree ou Windows) requer uma alta velocidade de transmissão de dados, sendo viável apenas em Intranet e conexões Internet de alta velocidade (ÁLVARES e TOURINO, 1999). Usar a Web para a conexão Internet é melhor que o telnet, pois requer apenas um browser padrão no lado do usuário (cliente). Além disso, o browser é uma plataforma independente no lado do usuário. O uso da Web em laboratórios remotos é uma atividade relativamente recente, alguns exemplos incluem: teste automatizado de circuitos analógicos (KNIGHT e WEERTH, 1996), laboratório remoto de medições, controle de robô (ÁLVARES, 2000), controle de processo químico (SHAHEEN et al., 1998) e controle de um máquina de oxi-corte CNC (http://weboxicorte.graco.unb.br).

Os componentes da arquitetura de controle via Web são ilustrados na figura 2.10. Aqueles relacionados aos aspectos remotos são o cliente (usuário remoto) conectado através de um modem, conexão ADSL ou conexão de alta velocidade ao Servidor HTTP (Web) dedicado, que reside em um computador no local do laboratório. Os componentes relacionados diretamente ao experimento são o controlador/computador (pode ser o mesmo que o servidor Web) onde se realiza realmente o experimento e os equipamentos associados (placas, conversor A/D, CNC, Robôs, etc.). Os labo-ratórios são desenvolvidos utilizando programas em C++ ou software comercial específico, tal como LabVIEW, que residem no computador local, laboratório, coordenando os experimentos.

**Figure:** Conexões remotas do laboratório (SCHMID, 1998).
$\resizebox*{14cm}{5cm}{\includegraphics{fig/fig2_10.ps}}$

2.5 Comunicação de Dados via Internet

Nesta seção serão apresentados os conceitos de modelo cliente-servidor, o modelo ISO-OSI para comunicação de dados, e o conceito de canais de comunicação (HALL, 1999), (MEATCALFE, 1998) e (TOURINO, 2000).

2.5.1 O Modelo Cliente-Servidor

O modelo da arquitetura cliente-servidor é um modelo de sistemas distribuídos que mostra como os dados e processamentos são distribuídos entre um conjunto de processadores. Os principais componentes desse modelo são:

um conjunto de servidores independentes que oferecem serviços para outros sub-sistemas;
um conjunto de clientes que requisitam serviços oferecidos pelos servidores;
uma rede de computadores que permite que os clientes acessem esses serviços.

Os clientes devem saber os ``nomes'' dos servidores disponíveis e os serviços que os mesmos provêm. Entretanto, servidores não precisam conhecer ou a identidade dos clientes ou quantos clientes tentam obter seus serviços.

A mais importante vantagem do modelo cliente-servidor é a sua fácil distribuição ou ampliação. É simples adicionar um novo servidor e integrá-lo gradualmente com o resto do sistema, ou mesmo atualizar os servidores sem afetar outras partes do sistema.

2.5.2 O modelo ISO-OSI

Um sistema de comunicações representa a forma na qual se realizam as trocas de dados e a passagem das informações de controle. O deslocamento desses dados é geralmente definido a partir do modelo de comunicação OSI (Open System Interconnection), definido pela ISO (International Organization for Standardization).

O modelo OSI divide em sete camadas o trabalho de deslocamento de dados de um ponto a outro. São camadas hierarquizadas que contribuem para o agrupamento ou separação de um pacote de dados. Esses pacotes de dados, além da informação propriamente dita a ser transmitida, levam em seu interior dados relativos à origem e destino na rede, assim como o protocolo empregado na codificação das informações transportadas. A figura 2.11 apresenta o modelo OSI/ISO e os protocolos mais utilizados em cada camada.

As camadas do modelo OSI são as seguintes:

Camada Física: É a camada responsável pela geração e recepção dos impulsos físicos (elétricos) envolvidos na comunicação de dados. Essa camada apenas trata da conexão das demais camadas com o sistema de comunicação, não incluindo portanto a implementação física da rede de computadores.
Camada de Enlace de Dados: É o nível que realiza o primeiro tratamento dos sinais, agrupando-os em pacotes de bits e adicionando-lhes sistemas de verificação de erros.
Camada de Rede: Quando uma rede de computadores torna-se complexa devido ao seu tamanho, utiliza-se como solução a sub-divisão desta rede, através da criação de sub-redes locais. A camada de rede gerencia o transporte de dados através da rede, realizando o roteamento dessas informações.
Camada de Transporte: É um nível de transição que realiza o gerenciamento final dos pacotes de roteamento e a recuperação de erros das camadas anteriores.
Camada de Sessão: A camada de sessão é o nível que mantém as transmissões orientadas à conexão, realizando a abertura e fechamento de conexões entre máquinas da rede.
Camada de Apresentação: É uma camada pouco utilizada responsável pela conversão dos dados recebidos para a próxima camada, a camada de aplicação.
Camada de Aplicação: A camada de aplicação trata dos assuntos de segurança e disponibilidade de recursos, como transferência de arquivos e protocolos de terminais.

**Figure:** Arquitetura ISO/OSI e protocolos utilizados nas sete camadas (Álvares, 1992).
$\resizebox*{17cm}{19cm}{\includegraphics{fig/fig2_11.ps}}$

2.5.3 TCP e UDP

O TCP (Transmission Control Protocol) e o UDP (User Datagram Protocol) são protocolos que percorrem encapsulados nos pacotes IP (Internet Protocol), sendo responsáveis pela comunicação de dados baseados em datagramas e baseados em fluxo.

Um protocolo baseado em datagrama é aquele que atribui um tamanho máximo à quantidade de dados enviada em uma única transmissão (como o UDP). Um protocolo baseado em fluxo (como o TCP) realiza a ``quebra'' da informação em pacotes menores e trata da reorganização desses pacotes, de forma que, para o usuário, a transmissão é realizada sem limites de quantidade de dados.

De forma comparativa, podemos diferenciar o UDP do TCP da seguinte forma:

UDP baseado por datagrama; menor consumo de recursos da rede; menor confiabilidade; quantidade de dados enviada por transmissão limitada.
TCP baseado em fluxo; maior consumo de recursos da rede; maior confiabilidade; quantidade ilimitada de dados transmitidos.

2.5.4 Canais de Comunicação (Sockets)

Canais de comunicação (geralmente denominados de ``sockets'') são a forma de se realizar a comunicação entre dois computadores em uma rede. Os canais ligam dois computadores através de seus endereços IP e através de uma ``porta'' de comunicação. Esta comunicação pode ser reali-zada tanto através do protocolo UDP como pelo protocolo TCP. Comandos como ``telnet'' e ``ftp'' utilizam internamente em seu funcionamento o conceito de canais de comunicação.

De forma genérica um canal de comunicação é aberto especificando-se o endereço da máquina destino e a porta de comunicação a ser utilizada. Para o caso de uma comunicação TCP, a máquina remota recebe o endereço da máquina local, o que permite que uma conexão baseada em fluxo seja realizada entre as máquinas.

2.5.5 O servidor Inetd

Nos sistemas UNIX, como o Linux, existe um processo responsável pela maior parte das conexões realizadas através de canais de comunicação. Esse programa, denominado ``inetd'', aguarda conexões de rede e as direciona para programas servidores, como o ``telnetd'', responsável por conexões ``telnet''.

A configuração do inetd é armazenada no arquivo \etc\inetd.conf. A sintaxe dos dados contidos no arquivo segue a seguinte forma:

2.5.5.0.0.1 serviço canal protocolo espera usuário localização argumentos

Os termos referidos acima possuem os seguintes significados:

[serviço]: é o nome do servidor, listado no arquivo /etc/services.
[canal]: descreve o tipo de canal utilizado, ou seja, stream ou dgram.
[protocolo]: é o protocolo utilizado pelo serviço, seja tcp ou udp.
[espera]: configura o inetd a travar a porta (wait) a novas conexões ou não travar a porta (nowait) a novas conexões.
[usuário]: indica sob qual usuário o servidor deve ser ativado (geralmente o super-usuário root).
[localização]: indica a localização e nome do servidor a ser ativado pelo inetd.
[argumentos]: descreve os argumentos a serem passados ao programa servidor.

Assim, por exemplo, o servidor telnet é geralmente configurado no arquivo inetd.conf da seguinte forma:

2.5.5.0.0.2 telnet stream tcp nowait root /usr/etc/in.telnetd in.telnetd

Deve-se lembrar que o servidor deve estar listado no arquivo /etc/services, onde é definida a porta que o servidor atende. No caso do servidor de telnet, sua configuração é a seguinte:

2.5.5.0.0.3 telnet 23/tcp

onde temos a utilização da porta 23 sob o protocolo tcp.

A utilização do inetd é vantajosa sobre a programação convencional utilizando diretamente os canais de comunicação pois reduz a carga sobre o sistema operacional e facilita o desenvolvimento de programas que realizam comunicação via Internet.

2.6 Infra-estrutura de Rede de Alta Velocidade

A Infra-estrutura de Rede de Alta Velocidade deve disponibilizar diversas tecnologias para suportar diferentes aplicações, as quais utilizam parâmetros diversos de Qualidade de Serviço: Velocidade de Transmissão, Atraso (Delay), Throughput, Agendamento e Taxa de Perda.

A velocidade de transmissão define a faixa de valores na qual a velocidade de uma determinada conexão deve estar; o atraso define o máximo de interrupção aceitável para um sinal na rede, de modo a garantir o fluxo contínuo de transferência da informação; o throughput define a quantidade de dados transmitidos em uma unidade de tempo; o agendamento define o horário em que uma determinada conexão deverá estar disponível e a taxa de perda define a taxa máxima esperada de perda de pacotes na unidade de tempo.

No Brasil esta infra-estrutura de rede é disponibilizada pelo Backbone da RNP que conecta as instituições de ensino superior, em especial a UnB e a UFSC. Futuramente teremos conectividade através da Internet 2, onde o backbone terá uma maior largura de banda, sendo mais adequado para aplicações de manufatura remota e virtual.

As principais tecnologias disponibilizadas através desta plataforma de Rede envolvem:

RSVP: (Reservation Protocol) - Protocolo da família TCP/IP o qual aloca recursos na rede no sentido de garantir a Qualidade de Serviço;
IGMP: (Internet Group Management Protocol) - Protocolo que trabalha com comunicação Multicast, dando suporte à comunicação entre usuários da rede;
IPv6: (Internet Protocol version 6) - Evolução do IP versão 4, o qual possui maior capacidade de endereçamento, menores tabelas de roteamento, menor overhead (cabeçalho mais simples) e suporte à Qualidade de Serviço;
ATM: (Assynchronous Transfer Mode) - Técnica de comutação rápida de células, a qual trabalha com diversos tipos de tráfego, tais como voz, dados, imagens, etc. É uma técnica de multiplexação estatística assíncrona a qual implementa o conceito de QoS (Quality of Service - Qualidade de Serviço). Seu ponto principal consiste em garantir ao usuário níveis pré-definidos de desempenho da rede. Para tal, são definidas diferentes classes de serviço.

3. Internet e a World Wide Web

Neste capítulo será apresentada uma compilação das principais tecnologias, protocolos e ferramentas disponíveis para o desenvolvimento de aplicações baseada no protocolo TCP/IP. Este capítulo é baseado no projeto elaborado pelo autor sobre ensino a distância para disciplinas de graduação do curso de Engenharia Mecatrônica da Universidade de Brasília. O projeto está disponível na URL ftp://graco.unb.br/pub/publicacoes_graco/ensino_a_distancia.pdf.

3.1 WWW (World Wide Web)typeset@protect @@footnote SF@gobble@opt Também denominado de Web. Neste trabalho muitas vezes a terminologia WWW será designada simplesmente de web, ou seja, a rede Internet utilizando o protocolo HTTP.

O serviço WWW surgiu em 1989 como um integrador de informações, dentro do qual a grande maioria das informações disponíveis na Internet podem ser acessadas de forma simples e consistente em diferentes plataformas. A forma padrão das informações do WWW é o hipertexto, o que permite a interligação entre diferentes documentos, possivelmente localizados em diferentes servidores, em diferentes partes do mundo. A figura 3.1 apresenta a evolução da Internet apresentando os diversos protocolos desenvolvidos ao longo dos anos.

O hipertexto é codificado com a linguagem HTML (Hypertext Markup Language), que possui um conjunto de marcas de codificação que são interpretadas pelos clientes WWW (que são os browsers, como o Netscape), em diferentes plataformas. O protocolo usado para a transferência de informações no WWW é o HTTP. O protocolo HTTP é um protocolo do nível de aplicação que possui objetividade e rapidez necessárias para suportar sistemas de informação distribuídos, cooperativos e de hipermídia. Suas principais características são:

Comunicação entre os agentes usuários e gateways, permitindo acesso a hipermídia a diversos protocolos do mundo Internet, tais como, SMTP, NNTP, FTP, Gopher, WAIS ;
Obedece ao paradigma de pedido/resposta: um cliente estabelece uma conexão com um servidor e envia um pedido ao servidor, o qual o analisa e responde. A conexão deve ser estabelecida antes de cada pedido de cliente e encerrada após a resposta.

**Figure:** A evolução da Internet até a utilização de gráfico 3D (Tornincasa, 2001).
$\resizebox*{15cm}{10cm}{\includegraphics{fig/fig3_1.ps}}$

3.2 Vantagens da Utilização da WWW

A partir dos trabalhos de (SCH, 1995), (MAR, 1996) e (LOH, 1996) pode-se apresentar as principais vantagens do WWW :

o WWW permite a apresentação de conteúdo multimídia: texto integrado com som, imagens 2D e 3D e vídeo;
o WWW consiste em um ambiente bastante amigável, o que permite sua manipulação por usuários com pouca intimidade no uso de computadores;
é, potencialmente, um ambiente integrado, pois é possível visualizar as diferentes mídias dentro do próprio browser WWW. Além da capacidade de visualizar texto formatado e figuras, que são comuns na maioria dos browsers, a maioria dos browsers são capazes de executar aplicações auxiliares externas, denominadas helper applications, para visualizar outras mídias. Os browsers Netscape e Internet Explorer também permitem a instalação de plug-ins, que são programas que estendem a capacidade dos browsers, permitindo que outros formatos de dados possam ser visualizados dentro do próprio browser. Atualmente existem plug-ins para visualizar documentos VRML, vídeo, áudio, entre outras mídias. O suporte a helper applications e plug-ins é de extrema importância, principalmente para os usuários com pouca familiaridade no uso de computadores, pois torna a tarefa de "chamar" diferentes programas para executar as diferentes mídias transparente ao usuário;
permite a integração com outros serviços da Internet. A partir do WWW é possível utilizar serviços como o gopher, ftp, telnet, wais, newsgroup e correio eletrônico;
permite o uso de hiperlinks, fornecendo uma liberdade maior na "navegação". No entanto, o projeto da estrutura de hiperlinks de um hiperdocumento deve ser cuidadosa, pois devido a liberdade de navegação, é bastante comum que o usuário fique "perdido no ciberespaço";
as ferramentas como browsers, plug-ins e helper applications geralmente são disponibilizadas a um preço bastante acessível ou mesmo em versão freeware para fins educacionais.

3.3 Recursos avançados no WWW

Ao se avaliar a efetividade do uso do WWW na manufatura remota é imprescindível a realização de um estudo e avaliação das várias ferramentas disponíveis para prover recursos avançados no WWW, tais como interatividade, animações, simulações e mundos virtuais a este serviço. Assim, nesta seção serão apresentados os Forms/CGI (Common Gateway Interface) e Servlets, bem como as linguagens Java, Javascript e VRML (Virtual Reality Modeling Language). Serão apresentados os fatores relevantes na avaliação destas ferramentas para verificar se o seu uso tem o potencial de prover um hiperdocumento interativo, eficiente e de alta de qualidade.

3.3.1 Apresentação das Ferramentas Form/CGI

O Form é um elemento da linguagem HTML que permite que o usuário forneça dados a uma aplicação de hiperdocumento, através do preenchimento de campos de um formulário. Esses dados são enviados para um servidor HTTP, onde serão interpretados e processados por uma CGI (common gateway interface).

Uma CGI (common gateway interface) é colocada em um servidor WWW para realizar a interface deste com programas externos. Assim uma CGI atua como um gateway entre o servidor WWW e bases de dados, aplicações locais ou geradores de documentos. O funcionamento de uma CGI é descrito abaixo:

Primeiramente o cliente WWW (browser) solicita uma URL ao servidor WWW ;
A URL solicitada é referente a uma CGI, portanto o servidor WWW executa a CGI solicitada;
A CGI trabalha interagindo com outras aplicações do sistema, recupera dados destas aplicações e retorna o resultado ao servidor WWW;
O servidor WWW por usa vez envia os dados para o cliente WWW, que formata o resultado e o apresenta ao usuário.

Os forms, juntamente com as CGI podem, por exemplo, serem utilizados para acionar um equipamento onde os parâmetros de comando do equipamento são passados ao programa CGI, que estabelece a conexão com o equipamento teleoperado e executa o comando. A seguir recebe o status do equipamento e gerar um documento HTML. Um outro exemplo, poderia ser o acesso a uma Base de Dados para buscar informações sobre condições tecnológicas de usinagem para um determinado processo. Como a implementação de um CGI exige programação em linguagens como C, Perl, Visual Basic, Unix Shell, ou outra compatível com o sistema, sua utilização é razoavelmente difícil para pessoas sem experiência em programação.

3.3.2 Servlets

Servlets são módulos de código Java que ``rodam'' em uma aplicação no servidortypeset@protect @@footnote SF@gobble@opt Servlets estão para o lado do servidor, assim como Applets estão para o lado do cliente. respondendo a uma solicitação do cliente. Servlets não tem um protocolo específico cliente/servidor, sendo utilizados em conjunto com o servidor HTTP. O servidor mais utilizado com o Apache é o TomCat. Servlets fazem uso das classes estendidas padrão Java disponíveis nos pacotes javax.servlet e javax.servlet.http. Usos típico de HTTP Servlets incluem:

Processamento e/ou armazenamento de dados submetidos por um formulário HTML;
Possibilita conteúdo dinâmico, isto é, retorna os resultados de uma pergunta (``query'') de um cliente à base de dados;
Gerencia o estado da informação no topo da ``stateless HTTP'', isto é, para um sistema de ``shopping cart'' o qual gerência muitos clientes simultaneamente e mapeia cada solicitação/pedido para o cliente certo.

Maiores informações sobre Servlets e comparações com CGI destacando vantagens e desvantagens estão disponíveis na URL ftp://custom.lab.unb.br/pub/docs/books/www.novocode.com/doc/servlet-essentials/index.html.

3.3.3 Java

A linguagem Java torna possível a criação de aplicações multimídia interativas as quais serão executadas localmente nas máquinas clientes de forma independente da plataforma, bastando que o usuário possua um browser Web com capacidade de interpretar código em Java instalado em sua máquina.

Dessa forma a linguagem Java abre um grande número de novas perspectivas em direção à criação de ambientes integrados para aplicações em CAD/CAPP/CAM (http://cybercut.berkeley.edu), Modelagem Cooperativa na etapa de Projeto Detalhado (webspiff http://www.webspiff.org), Prototipagem Rápida (http://www.ia.ee.ccu.edu.tw e http://tmf.sdsc.edu), entre outras.

Com os applets escritos em Java, é possível desenvolver-se páginas Web incluindo animações, gráficos 2D e 3D, computação, aplicações distribuídas e comunicação. No entanto o maior destaque desta linguagem é a possibilidade de criar páginas Web altamente interativas. Segundo HORSTMANN E CORNELL (2000), Java transforma a Web em um sistema de distribuição de software, onde o usuário tem "coisas para fazer" e não apenas "lugares para ir". O Java pode mudar o comportamento dos usuários da Web, que deixarão de apenas "surfar" para também ``trabalhar'', "jogar", "interagir" e "aprender" nos novos ambientes interativos. Também acredita-se que a linguagem Java irá melhorar muito o suporte à cursos via Internet através do uso de simuladores escritos nesta linguagem, os quais auxiliarão no aumento do envolvimento dos alunos nas sessões de aprendizagem remota, ajudando-os a aprender através da experimentação e visualização (MIR, 1996).

3.3.3.1 Funcionamento da linguagem Java

Em primeiro lugar deve-se criar o código fonte Java, gerando um arquivo ``.java''. Compila-se o código fonte, gerando um arquivo ``.class'', o qual contém um formato de dado chamado bytecode, que posteriormente poderá ser interpretado por um cliente WWW com capacidade de interpretar Java.

Cria-se um documento HTML, contendo a chamada da applet Java, através da tag <APP>. Copia-se o arquivo ``.class'' para o mesmo diretório do documento HTML que faz a sua chamada, por exemplo. Quando um cliente WWW com capacidade de interpretar Java carrega este documento HTML e lê a tag <APP>, o cliente WWW gera um comando HTTP GET e faz o download do arquivo ``.class''. O cliente WWW então interpreta os bytecodes contidos no arquivo .class, e executa a applet na máquina do cliente. O grande obstáculo no uso desta linguagem é que a geração do código fonte em Java exige uma grande experiência em programação, já que a utilização desta linguagem está longe de ser simples como a utilização da linguagem HTML.

3.3.4 Javascript

A linguagem Javascript foi criada pela Netscape com o objetivo de obter uma linguagem intermediária entre a linguagem Java e a HTML, de tal forma que fosse complementar e integrada a estas duas linguagens. Assim o Javascript é fácil de usar, aberta, e tem capacidade de ligar objetos e recursos tanto da linguagem Java como da HTML. Enquanto as applets Java são desenvolvidas apenas por programadores, o Javascript pode ser usado por autores de páginas HTML para controlar a interação e comportamento de suas páginas.

Um dos principais benefícios que o Javascript oferece é a capacidade de reduzir o tráfego da rede através da execução local de tarefas simples. Assim, ao invés do servidor executar as tarefas e retornar os resultados para o browser, este último pode manipular algumas tarefas localmente, com um menor tempo de resposta. A linguagem Javascript é interpretada pelos browsers Web que possuem este recurso (por exemplo, o Netscape e Internet Explorer).

O código da aplicação Javascript é recuperado pelo browser Web na forma de texto, juntamente com o documento HTML. Com o Javascript pode-se facilmente implementar respostas a eventos do usuário, tais como cliques do mouse, movimentos do mouse sobre um link, e entrada de dados em um formulário. Dessa forma é de grande utilidade na criação de interfaces mais explicativas ao usuário. Também é possível criar páginas dinâmicas, cujo conteúdo muda de acordo com as requisições do usuário, ou mesmo disparar sons ou executar applets quando o usuário entra ou sai de uma página, permitindo assim uma maior interatividade com o usuário. Outra aplicação bastante comum da linguagem Javascript é a validação de formulários, ou seja a verificação dos dados que o usuário digitou no formulário, antes que estes sejam submetidos ao programa CGI, aumentando a performance do servidor e também diminuindo a frustração do usuário. A linguagem Javascript é de aprendizado bem mais simples que a linguagem Java, no entanto exige um esforço consideravelmente maior do que a linguagem HTML, já que apesar de sua simplicidade a linguagem Javascript é baseada em linguagem de programação, o que a torna muito mais sofisticada do que a linguagem HTML.

3.3.5 VRML

VRML (Virtual Reality Modeling Language) é uma linguagem de descrição de simulações interativas com vários participantes se comunicando através da Internet. Espera-se que todos os aspectos referentes a apresentação, interação, internetworking de um mundo virtual possam ser especificados usando VRML. A intenção dos projetistas desta linguagem é torná-la padrão para a descrição de simulações interativas no WWW, assim como a linguagem HTML é o padrão para descrição de páginas Web. A primeira versão (VRML 1.0) foi concebida em 1994, e foi projetada seguindo três requisitos principais (BEL, 1995):

independência de plataforma;
extensibilidade;
e capacidade de trabalhar bem mesmo em conexões com pequena largura de banda (bandwidth).

Na versão 1.0 optou-se pelo suporte a comportamentos interativos limitados. Assim sendo a interatividade ainda se restringe a inserção de hiperlinks. As melhorias advindas com a versão 2.0 são:

Interatividade: em um mundo interativo: por exemplo poder abrir portas, andar entre os móveis de um apartamento virtual, trocar objetos de lugar entre outras coisas. No entanto certamente este recurso aumenta significativamente o tamanho dos arquivos;
Comportamentos: na versão 1.1 a capacidade de animação é ainda muito limitada, já na versão 2.0 pode criar comportamentos, tal que os objetos possam ter um pouco de "vida", através de movimentos limitados, e também ações que afetem outros objetos;
Som 3D : o som é uma característica chave na criação de um bom ambiente imersivo. Considera-se que uma pequena melhora na qualidade do som é percebida mais significativamente pelo usuário do que uma pequena melhora na qualidade da imagem;
Multiusuário: o suporte inicial a multiusuário através de código em Java, que na realidade envia sinais contendo a posição e velocidade dos avatares. Algumas questões incluem o logging das pessoas que estão atualmente no mundo, detecção de colisão para impedir que dois avatares estejam no mesmo espaço num dado momento.

Para visualizar um mundo virtual criado em VRML é necessário usar-se um browser VRML. Este pode comunicar-se com o browser HTML, de tal forma que quando seleciona-se um link para um arquivo html de dentro de um mundo virtual, o browser HTML carregará a URL. No caso inverso o browser HTML reconhecerá o MIME type e passará a URL para o browser VRML. Alguns browsers HTML como o Netscape possui um plug-in VRML (Live3D), que permite que o arquivo VRML seja apresentado no browser HTML, na mesma janela onde são apresentados os arquivos HTML. Atualmente os arquivos VRML podem ser enviados usando o mesmo servidor HTTP usado para enviar arquivos HTML.

3.3.6 Hardware mínimo necessário para usuário

Um fator importante na efetividade dos recursos avançados do WWW é a configuração mínima de hardware necessária para o usuário final executar tais recursos. Apesar deste recursos poderem ser executados em diversas plataformas (PC, Macintosh, Sun, Linux, etc), pode-se notar que todos os recursos avançados podem ser executados utilizando uma configuração de hardware que atualmente é bastante comum.

3.3.7 Software mínimo necessário para usuário

Softwares necessários para o usuário final executar os recursos avançados em questão:

Forms/CGI: Browser WWW com capacidade para visualizar FORMS, por exemplo: Netscape Navigator e Microsoft Explorer;
Java: browser WWW com capacidade de interpretar código em Java, por exemplo: Hot Java, Netscape, Microsoft Explorer e plug-ins associados para Java e Java 3D, entre outros. A partir da versão Java 2 é necessário a utilização de plug-ins para trabalhar com a nova interface gráfica denominada de SWING. Quando o applet é desenvolvido utilizando a interface gráfica baseada no AWT não é necessário a utilização de plug-in, necessitando apenas a ativação do recurso java e javascript;
Javascript: browser WWW com capacidade de interpretar a linguagem Javascript, por exemplo: Netscape ou Internet Explorer 3.0;
VRML: Browsers VRML: WebFX (http://www.paperinc.com), WebSpace (http://webspace.sgi.com) ou WorldView (http://www.intervista.com);
Plug-ins VRML: Live3D para Netscape e Director3D para Microsoft Explorer.

3.3.8 Software mínimo necessário para o programador

Softwares necessários para o desenvolvimento de recursos com as ferramentas de implementação em questão, são:

Forms/CGI: Compilador/interpretador usado para gerar o CGI : C/C++, Fortran, PERL, TCL, qualquer shell Unix, Visual Basic;
editor html ou editor ascii para criar os formulários e escrever o código fonte do CGI browser WWW (que suporte Forms) para poder visualizar a aplicação (é necessário colocar o documento html e o cgi em um servidor WWW que se encarregará de executar o cgi;
Java: JDK (Java Development Kit) é o kit básico para o desenvolvimento de programas em Java. O JDK inclui, entre outros recursos: um interpretador de runtime, compilador, depurador, visualizador de applets, código fonte de todas as classes que formam a API (Application Programming Interface) do Java.
Um browser que suporte applets Java: Hot Java, Netscape, Microsoft Explorer;
Javascript: editor html ou editor ascii para escrever o código fonte em Javascript;
browser WWW (que suporte Javascript) para poder visualizar a aplicação (pode ser testado off-line pois é interpretado diretamente pelo browser).
VRML: editor ascii para especificar o mundo virtual;
browser VRML ou plug-in VRML para testar o mundo.

Os softwares necessários para a implementação dos recursos avançados no WWW não se apresentam como fatores limitantes pois são bastante comuns, como é o caso do editor ascii ou podem ser facilmente encontrados gratuitamente na rede, como é o caso dos browser, plug-ins, o JDK e alguns compiladores e interpretadores para gerar CGI.

3.3.9 Hardware mínimo necessário para o programador

Quando se utiliza plataforma Unix, em especial Linux, tem-se uma grande quantidade de softwares open source, que estão disponíveis para o desenvolvimento de aplicações, além da grande facilidade de se trabalhar em ambiente de rede (TCP/IP) pois todo o sistema (kernel, ambiente XFree86 e aplicações) foram concebidos para operarem em ambiente multiusuário, distribuído e compartilhado de uma forma nativa, sendo mais confiável, robusto e transparente que o ambiente Windows. Assim, para o desenvolvimento de aplicações em uma arquitetura Cliente/Servidor a plataforma Unix (Linux, FreeBsD, Solaris, entre outras) é mais adequada.

No trabalho de implementação computacional da metodologia de integração CAD/CAPP/CAM baseada na Web, a ser desenvolvido na Tese, será utilizado a plataforma Linux e em especial as facilidade disponibilizadas pela distribuição SuSE (http://www.suse.com e ftp://custom.lab.unb.br/pub/suse).

3.3.10 Dificuldade de aprendizagem e uso

É importante se avaliar o grau de dificuldade envolvido na aprendizagem e uso da ferramenta de implementação, em função do conhecimento básico exigido:

Forms/CGI: Dificuldade média/alta na implementação dos CGI's, dependendo da linguagem escolhida para implementá-los, e da complexidade do CGI a ser implementado. No entanto em todos os casos é necessário uma experiência em programação;
Java: Dificuldade alta, exigindo conhecimento em linguagem de programação orientada a objetos;
Javascript: Dificuldade baixa, exige conhecimentos básicos de programação, com a vantagem da aplicação poder ser visualizada diretamente no browser, sem compilação, já que é interpretada pelo browser.
VRML: Dificuldade média a alta, dependendo da complexidade do mundo virtual a ser implementado.

Como pode ser analisado, o grande obstáculo na efetividade da integração de recursos avançados no WWW é a sua dificuldade de implementação. Este fator se torna bastante limitante quando se considera que pessoas com pouco conhecimento em linguagens de programação desejem utilizar estas ferramentas. Esse problema pode ser contornado através do uso de ferramentas auxiliares na implementação de tais recursos.

3.3.11 Existência de ferramentas auxiliares

Devido a dificuldade de implementação encontrada em alguns destes recursos, é importante a verificação da existência de ferramentas auxiliares que facilitem tal implementação.

As ferramentas auxiliares na criação de CGI's são bastante úteis, permitindo que usuários sem conhecimento em programação possam inserir este recurso em suas páginas. No entanto estas ferramentas ainda são pouco genéricas, geralmente permitindo apenas a criação de formulários e CGI's para atender a um objetivo específico.

As ferramentas auxiliares na criação de applets Java ainda se restringem à ambientes de desenvolvimento integrados denominados de IDE (VisualJava, VisualCafe, JavaBorland, entre outros), os quais facilitam o trabalho dos programadores, mas está longe de solucionar o problema das pessoas com pouco ou nenhum conhecimento em programação.

Quanto ao VRML, existem as ferramentas de autoria de documentos VRML, que são semelhantes às ferramentas de autoria de documentos HTML. Os conversores permitem a criação de documentos VRML usando CAD ou softwares de modelagem 3D, no entanto, segundo SCO (1996), estes conversores tendem a gerar arquivos VRML grandes e ineficientes.

3.4 Computação Baseada em Servidor

Segundo CITRIX (2001) os modelos de computação distribuídos, utilizando uma rede de computadores, podem ser divididos em quatro categorias:

Modelo de Computação Tradicional em Rede de Computadores: usa um servidor de rede para armazenar aplicações DOS, Windows, Unix, etc, e arquivos de dados para a rede. O cliente faz o download da aplicação do servidor de rede e a execução local, na sua máquina, salvando os arquivos no servidor de rede.
Modelo de Computação Cliente/Servidor: distribui o processamento de aplicações sobre diferentes computadores na rede, onde o servidor manipula o acesso aos dados em função da aplicação, enquanto que o cliente executa o serviço de apresentação e funções lógicas da aplicação. O cliente é normalmente o front-end do servidor. Esta arquitetura é muito utilizada para acessar informações de bases de dados e nos serviços Web, ftp, telnet, mail, entre outros.
Modelo de Computação em Rede de Computadores: semelhante ao modelo tradicional, entretanto, utiliza tecnologia Java, onde o servidor armazena todas as aplicações Java e dados dos cliente. O cliente faz o download e executa a aplicação em um computador da rede que contem apenas CPU, RAM, modem ou cartão de rede e monitor. Normalmente não contem um disco rígido.
Modelo de Computação Baseado em Servidor: usa uma arquitetura na qual aplicações e dados são oferecidos, gerenciados, suportados e executados 100% no servidor. Os dispositivos clientes, fat ou thin, tem acesso instantâneo as aplicações no servidor sem o uso de aplicações de escrita ou download. Fat Clients referem-se a um computador standalone com um disco rígido, disquete, slots de expansão e outros componentes tradicionais de PC (computador pessoal). Thin Clients referem-se a equipamentos de baixo custo, gerenciados centralmente sem necessidade de disco rígido, disquetes ou slots de expansão. Quando o usuário quer usar uma aplicação ele clica um ícone no seu cliente e a aplicação inicia no servidor e envia uma interface da aplicação para a tela do cliente. Exemplos deste sistema são as arquiteturas de sistema X11/xdm de plataformas Unix (XFree86, por exemplo), Metaframe da Citrix (Windows e Unix) e RDP (Protocolo de Desktop Remoto) um Emulador de Terminal Remoto da Microsoft/Citrix, só disponível para plataforma Windows.

A arquitetura Citrix (http://www.citrix.com)oferece a possibilidade de viabilizar o acesso distribuído às informações com o software Metaframe XP, uma solução baseada no modelo de "Computação Baseada em Servidor". Com o Metaframe XP a organização pode acelerar o desenvolvimento de seus sistemas corporativos enquanto disponibiliza aplicativos de missão crítica. O Metaframe permite o desenvolvimento de aplicativos utilizando qualquer tipo de equipamento de hardware disponível, desde microcomputadores legados ou antigos, equipamentos tipo Macintosh, sistemas Unix, estações Windows de última geração ou equipamentos baseados em sistemas Java. O Metaframe ajuda a reduzir os custos de propriedade das aplicações desenvolvidas, porque permite que a empresa centralize todo o processamento das aplicações de missão crítica num mesmo local, ao mesmo tempo em que reaproveita toda a infraestrutura de hardware, periféricos, rede de dados e infraestrutura de comunicações da organização.

O modelo de "Computação Baseada em Servidor" é uma eficiente evolução do ambiente de rede tradicional, e oferece às organizações uma maneira de expandir seus recursos computacionais, simplificar o desenvolvimento e a manutenção de seus sistemas aplicativos, além de diminuir o custo de propriedade dos mesmos. Esse tipo de utilização permite que todas as aplicações sejam desenvolvidas, mantidas, gerenciadas e executadas 100% a partir do servidor Metaframe. O modelo de ``Computação Baseada em Servidor" tem 3 componentes críticos:

O primeiro componente capacita o servidor a suportar inúmeros usuários simultâneos executando diferentes aplicações em seções separadas, com absoluta proteção e sigilo.
O segundo componente é uma tecnologia altamente eficiente que separa a lógica da aplicação da sua interface, capacitando somente o teclado, as telas e o mouse a trafegar pelo meio de comunicação ou pela rede, tendo como resultado imediato, uma melhor performance dos aplicativos, independente da largura de banda do meio de comunicação.
O terceiro componente, baseado na utilização e gerenciamento centralizada das aplicações, permite que grandes ambientes de processamento sejam disponibilizados aos usuários, e os desafios no desenvolvimento, manutenção, acesso remoto, performance e segurança sejam superados.

O modelo de "Computação Baseada em Servidor" é possível através do emprego simultâneos de duas tecnologias Citrix: Arquitetura de Computação Independente (ICA) e a tecnologia Multi-Win. No modelo de "Computação Baseada em Servidor", o processamento da aplicação não é mais realizada na estação do usuário e sim no servidor Metaframe.

A arquitetura do Metaframe XP baseada em servidor retém todo o tráfego gerado no backbone da rede local. Somente as modificações das telas, os movimentos do mouse e os caracteres digitados no teclado é que trafegam pela rede e meios de comunicação, consistindo agora numa pequena fração de todo o tráfego gerado pela aplicação corporativa tradicional. Isso permite que os usuários, locais ou remotos, tenham um excelente tempo de resposta em seus aplicativos, mesmo através de redes congestionadas. A redução do tráfego gerado nas redes pode ser revertida em eliminação de custos de comunicação de dados. O Metaframe XP é otimizado para trabalhar em conexões de baixa velocidade como 14.4 kbps. Os usuários remotos podem ter bons resultados e tempos de respostas adequados, independentemente de estarem trabalhando em filiais, escritórios, hotéis, residência, etc. De fato, o Metaframe XP ajuda as aplicações a executarem de forma muito rápida sobre qualquer infra-estrutura de comunicações, incluindo roteadores, nós remotos, linhas discadas, etc.

Utilizando a arquitetura Citrix é possível obter a conectividade de qualquer cliente (Windows, Unix, entre outros). Os usuários podem ter total acesso aos sistemas e aplicações disponíveis, de acordo com os perfis previamente definidos pelo administrador da rede. Isso quer dizer, que os usuários apesar de estarem operando de forma remota em qualquer lugar, somente terão acesso aos sistemas e às informações que tiverem direito de ver ou a manipular. As aplicações que serão disponibilizadas serão aquelas aplicações escritas em ambiente Windows 16 e 32 bits, aplicações residentes em Mainframes ou servidores Unix através de emuladores, aplicações tradicionais do tipo Cliente/Servidor e aplicações escritas em linguagem Java. Seja qual for a linguagem ou tecnologia empregada pela aplicação, o usuário terá a visibilidade e a operação do sistema a partir de qualquer lugar e utilizando qualquer tipo de equipamento/sistema operacional.

Pode-se gerenciar e expandir o alcance das aplicações corporativas de missão crítica com as ferramentas específicas do Metaframe através da publicação das aplicações na WEB. Com a ferramenta "Application Lauching and Embedding" (ALE), pode-se disponibilizar os sistemas de CAD/CAM comerciais, por exemplo, através da Internet, reduzindo o tempo e os custos dos projetos, sem a necessidade de decodificar as aplicações a serem disponibilizadas na WEB. Com o processo de publicação de aplicações via WEB, os usuários autorizados poderão acessa-las como qualquer outro recurso da rede. Um exemplo está disponível na URL http://beat.graco.unb.br.

3.5 Ferramentas Para Visualização de Modelos 2D e 3D

3.5.1 SATVIEWER

SATVIEWER é uma software baseado na WEB utilizando a API Java 3D para visualização gráfica de modelos sólidos de componentes mecânicos através da Internet. O software foi implementado como um Java applet que pode ser acessado usando um browser Internet para visualizar os modelos sólidos em formato padrão ``.SAT'', utilizado pelo kernel de modelagem sólida ACIS. Para utilização do applet é necessário a instalação da versão Java 1.2.2 JRE e Java3D JRE.

A URL http://caec.me.ufl.edu/ akumar/satviewer/satviewer.htm apresenta a página do sistema SATVIEWER desenvolvido na University of Florida, Department of Mechanical Engineering.

3.5.2 JavaCAD

JavaCAD é um applet que permite a modelagem 2D de peças através da Internet, permitindo o projeto e compartilhamento de informações para todo o mundo. A URL http://www.cad.delhi.nic.in/ nougain/java.html apresenta a página do sistema.

3.5.3 Conversor de formato ``.WRL'' para ``.SAT''

Este aplicativo permite a conversão de um arquivo ``.WRL'' (formato VRML) para o formato ``.SAT'' (ACIS). A URL http://www.me.cmu.edu/faculty1/shimada/gm98/project/jorge/project/index.html apresenta uma descrição do projeto e o algoritmo desenvolvido.

3.5.4 JGV: Visualizador 3D em Java

JGV é uma programa em Java que permite a movimentação de objetos 3D em páginas Web. Os usuários podem rotacionar, escalonar e translador os objetos utilizando o mouse. JGV difere dos visualizadores VRML pois é escrito em Java, significando que é possível utliza-lo em qualquer browser com capacidade Java. A URL http://www.geom.umn.edu/java/JGV/ apresenta a página do visualizador. O formato do arquivo é ``OOGL'' usado pelo sistema Geomview.

3.5.5 CADVIEWER: Visualizador Formato ``.DWF'' e ``.SVF''

CADVIEWER é um applet que permite a visualização de arquivo no formato ``.DWF'' e ``.SVF'', gerados pela maioria dos sistemas CAD da atualidade, permitindo sua visualização através da Web. Um exemplo do seu uso está disponível na URL http://www.graco.unb.br/alvares/cadviewer/old/demo.html, onde é apresentada uma planta baixo do laboratório do Graco. É um produto comercial desenvolvido Cadviewer (http://www.graco.unb.br/alvares/cadviewer/trial/index.htm).

4. Manufatura Remota: Teleoperação

Este capítulo apresenta uma metodologia para o desenvolvimento de sistemas de teleoperação baseados na Web. Inicialmente é apresentada uma revisão do estado da arte sobre o tema. A seguir é apresentado a metodologia desenvolvida pelo doutorando e os sistemas implementados no Graco para teleoperação de pan-tilts, Robôs Industriais, Robôs Móveis e Máquinas de Oxi-Corte CNC, sendo este último discutido no capítulo 5. A grande maioria de desenvolvimentos de sistemas de teleoperação são voltados para a área de Robótica Industrial e Robótica Móvel. Cabe destacar a edição especial da revista ``Robotics & Automation Magazine'' publicada pela IEEE denominada ``Robots on the WEB - Global Remote Control Through Internet Teleoperation'', onde alguns sistemas desenvolvidos pelo doutorando são citados como referência (IEEE, 2000).

4.1 Definição Clássica de Sistemas de Teloperação

A Teleoperação é definida como o controle contínuo e direto de um teleoperador/teleoperator. Teleoperador é um manipulador que requer comandos ou supervisão de um operador humano remoto (NOF, 1999). Telepresença refere-se à intensa utilização de realimentação sensorial para a teleoperação, fornecendo realismo para o operador em uma abordagem idealizada de "presença a distância".

Telerobótica amplia o domínio do manipulador em um contexto de controle compartilhado pela máquina e pelo operador humano. Um sistema Teleoperador/Teleoperator (NOF, 1999) consiste de uma unidade remota (manipulador), uma unidade de comando para entrada dos comandos do operador (interface homem/máquina) e um canal de comunicação como elo de ligação da unidade de comando com a unidade remota.

Inicialmente desenvolvida para a manipulação de materiais radioativos, a teleoperação permite que um operador exerça força e realize movimentos sobre uma máquina remota, e ainda receba realimentação sensorial, geralmente através de dados visuais, sonoros ou táteis. Com a introdução da tecnologia de teleoperação, foi possível o desenvolvimento de interfaces capazes de prover uma interação satisfatória entre homem e máquina, permitindo que serviços de grande destreza fossem realizados.

Foram propostos um grande número de sistemas de classificação para descrever a teleoperação. Um desses categoriza os sistemas de teleoperação tomando como base o grau de automação do sistema. Em um espectro variando da mínima para a máxima autonomia, a teleoperação pode ser classificada como (ZHAI, 1991):

controle manual sem auxílio computacional;
controle manual com significativo auxílio ou transformação computacional;
controle supervisório com predomínio do controle realizado pelo operador humano;
controle supervisório com predomínio do controle realizado pelo computador;
controle completamente automático, onde os operadores humanos observam o processo sem intervenções.

Diversos modelos relacionam esta interface, sendo os seguintes os tipos principais (ZHAI, 1992):

Modelo Mestre-Escravo: Este modelo descreve o mais tradicional sistema de teleoperação. Neste caso, o operador humano observa o ambiente de trabalho remoto através de um sistema de vídeo e manipula o braço robótico mestre por meio de um ``console'', que controla o braço escravo no local remoto. A estrutura mestre-escravo provê uma interface intuitiva para o controle remoto de sistemas. Embora esse modelo esteja muito evoluído, com o uso de vídeos estéreis e realimentação de força, a maior desvantagem desse sistema é a sua falta de destreza e o cansaço físico que impõe ao operador.
Modelo de Telepresença: Em um esforço de alcançar uma alta fidelidade nos canais de comunicação entre o mestre e escravo do modelo anterior, foram desenvolvidos sistemas antropomórficos para teleoperação, de forma a oferecer uma melhor forma de transmissão das capacidades humanas de solução de problemas e de manipulação em ambientes hostis. Com a meta de prover um sistema transparente de interface homem-máquina, os sistemas de telepresença utilizam-se de "displays'' montados na cabeça, sensores de movimento montados no corpo do operador, realimentação de força, entre outras tecnologias. A meta final desses sistemas é fazer o operador sentir-se presente no local de trabalho remoto, obtendo-se assim melhores condições de realização de tarefas. O custo técnico da implementação de tais sistemas, entretanto, não é justificado. O cansaço provocado ao operador devido ao volume e peso do equipamento, e ainda a falta de necessidade de um sistema de telepresença, reduzem o uso desse modelo principalmente à pesquisa e não para utilizações práticas.
Modelo Professor-Aluno: Dado que o aprendizado de sistemas computacionais é uma das áreas mais difíceis na inteligência artificial, o modelo professor-aluno define como função de professor ao operador humano, e assume que o ``aluno'' robô possui inteligência suficiente para reconhecer e atuar em uma situação já aprendida. Embora essas tecnologias ainda devam ser desenvolvidas e integradas para realizar esse modelo, as vantagens potenciais oferecidas por este conceito, em termos de conforto e efetividade, são substanciais.
Modelo Supervisor-Companheiro: De acordo com esse modelo, um robô baseado em sensores não deve simplesmente repetir os movimentos do operador humano, como no modelo mestre-escravo. Neste caso, o operador humano serve como um supervisor, ao invés de projetar-se no ambiente remoto. Com a companhia do operador humano, o sistema robótico incorpora capacidades computacionais, como precisão e capacidades sensoriais, para a realização das tarefas.

A comunicação homem-robô pode ser facilitada com o uso de gráficos interativos, controle com vários graus de liberdade e interfaces híbridas. Uma vez estabelecida e efetivada a comunicação entre homem e máquina, deve-se observar a relação entre a máquina remota e seu ambiente. Dessa forma, são propostos esquemas de classificação de modelos de ambientes:

Ambiente Remoto Totalmente Modelado: Nesta categoria, os objetos sendo manipulados, o ambiente e os procedimentos operacionais são repetitivos ou variantes, mas previsíveis. No primeiro caso, um robô programável pode realizar suas tarefas com mínima intervenção humana. No último, um operador humano escolhe estratégias de ação pré-programadas, consideradas como uma linguagem de programação do sistema.
Ambiente Remoto Parcialmente Modelado: Nesta categoria incluem-se operações em ambientes "humanos", como plataformas espaciais ou plantas industriais, onde todos os potenciais procedimentos operacionais das tarefas não podem ser antecipados em suficientes detalhes para uma pré-programação efetiva. Nesses casos, entretanto, é possível algum conhecimento geométrico do ambiente, podendo ser modelado à priori, mesmo que as relações espaciais entre o local e seus objetos não sejam conhecidas exatamente.
Ambiente Remoto Desconhecido: Esta categoria difere da anterior pelo fato de que pouca ou nenhuma informação sobre o ambiente e seus objetos é conhecida a priori. Exemplos desse tipo são os de robótica submarina, mineração, limpeza de resíduos nucleares e robótica militar.

4.1.1 Teleoperação Via Internet

A teleoperação requer a sinergia entre homem e máquina. O operador está envolvido no controle e na supervisão do sistema através de um console de operação e da correspondente interface homem-máquina. O console do sistema é uma estação gráfica a partir da qual o operador controla e supervisiona o sistema remoto, assumindo a existência de realimentação visual. Esta característica torna a interface homem-máquina uma peça fundamental do sistema.

A principal característica da interface é a integração de todas as informações necessárias à operação do sistema e relevantes ao operador num único écran, incluindo a exibição de imagens de vídeo, modelos virtuais e interfaces gráficas de controle. A interface homem-máquina tem como objetivo principal proporcionar um controle supervisionado realista e intuitivo que permita: monitorar continuamente a operação via displays baseados em vídeo ou ambientes virtuais; intervir interativamente e modificar os objetivos pela aplicação de comandos de controle enquanto opera a Spaceball ou o mouse na interface gráfica .

A Internet possui uma grande facilidade de criação de ambientes gráficos, o que facilita a interface com o usuário, além de possuir um baixo custo em relação ao equipamento teleoperado. Sendo uma rede de comunicação é possível enviar e receber informações, que podem ser comandos para serem executados em algum dispositivo ligado a rede, esse dispositivo pode ser um sistema robótico (TAYLOR e TREVELYAN, 1995) ou uma máquina-ferramenta CNC (KAO e LIN, 1996). Uma das características mais importante sobre o funcionamento de uma rede é a taxa de transmissão. Como normalmente os comandos transmitidos não exigem uma grande taxa de transmissão o que não implica em um empecilho à implementação de sistemas telerobóticos operados via Internet.

Outro aspecto importante é a possibilidade da teleoperação ser executada a partir de qualquer local conectado a Internet a um custo insignificante, o que se apresenta como uma solução bastante interessante (ÁLVARES et al. , 1999 e 2000). A teleoperação baseada na Internet pode ser realizada através de várias metodologias (ÁLVARES e TOURINO, 2000) a partir de uma arquitetura cliente/servidor. Dentre as quais destacam-se:

Acesso Remoto via "Telnet" (ECKEL e HARE, 1995): Uma forma de se obter o acesso a um sistema teleoperado via Internet é a conexão direta do usuário via interface telnet ou ssh (textual), amplamente disponível em ambientes de rede. A simplicidade de operação é perdida pelo fato de se necessitar de contas de usuários nas máquinas servidoras, o que é inviável dentro de um sistema de ampla abrangência, e ser mais susceptível a falhas de segurança.
Programação CGI, Common Gateway Interface, com simples páginas html (WEINMAN, 1997): A programação CGI com base em páginas HTML ("Hiper Text Markup Language") é a abordagem mais utilizada no momento para o controle de sistemas através da Internet, baseada na interface WWW ("World Wide Web"). A sua desvantagem é a limitação de interatividade com o usuário, e pelo fato de sobrecarregar o servidor. Uma alternativa é a utilização da abordagem JavaServlets onde é necessário a instalação de um servidor JavaServlets (TomCat, por exemplo) trabalhando em conjunto com o Servidor HTTP (Apache, por exemplo).
Cliente Java utilizando servidores genéricos HTTP (Apache) e servidores específicos via Sockets (ARNET et al. , 1994): A linguagem de programação Java, através de aplicativos applets, são a forma mais atual de programação para a Internet (PRADHAN e HUANG, 1999). Suas vantagens incluem a interatividade com o usuário, a fácil programação e a sua natureza voltada para a Internet. Sua desvantagem principal é a velocidade de operação, além do tempo para inicialização dos applets. O sistema de teleoperação do lado do servidor pode ser baseado integralmente em uma solução através do servidor WWW (servidor httpd) permitindo ao cliente ações de comando via CGI ou mesmo de Servlets. Neste sistema não é necessário o desenvolvimento do servidor apenas dos programas que permitirão o controle do equipamento, normalmente desenvolvidos em linguagem C ou Perl no caso de CGI e Java, no caso de Servlets. Em Java é necessário a instalação de outras APIs além do JDK padrão para ter acesso a interface serial do servidor, por exemplo. Utilizando-se de servidores específicos, orientados a conexão via sockets, é necessário desenvolver os servidores além dos programas para teleoperação do equipamento. Esta é a abordagem implementada no sistema de Teleoperação do Robô Móvel Nomad e da máquina de oxi-corte CNC desenvolvidos no Graco.

Os sistemas desenvolvidos no Graco utilizando a metodologia desenvolvida por ÁLVARES et al. (1998, 1999, 2000, 2001), e que serão descritos nas próximas seções, podem ser classificados como sendo do tipo "controle supervisório com predomínio do controle realizado pelo operador humano".

4.2 Introdução à Teleoperação de Sistemas Robóticos Baseada na Internet

A TeleRobótica utilizando a Internet como link de comunicação é um novo campo de pesquisa que se desenvolve na área da Teleoperação tendo muitos grupos de pesquisa atuando nesta promissora área da Telemática (MONTEIRO et al. , 1997), principalmente em função dos baixos custos de acesso à Internet. Uma das primeiras aplicações de TeleRobótica via Internet foi o sistema desenvolvido por TAYLOR & TREVELYAN (1995) na University of Western Australia em 1994. Este sistema é constituído por um Robô Industrial sendo controlado via Interface WWW (World Wide Web), permitindo a manipulação de objetos com a utilização de uma garra. Este sistema pode ser acessado através do endereço http://telerobot.mech.uwa.edu.au. A figura 4.1 apresenta a interface com o usuário deste sistema. A partir deste sistema, inúmeros outros foram desenvolvidos por vários grupos de pesquisa em todo o mundo. Uma lista de algumas aplicações pode ser encontrada em http://dir.yahoo.com/Computers_and_Internet/Internet/Interesting_Devices_Connected_to_the_Net/Robots. Dentre estes, têm-se a teleoperação de Robôs Móveis (KLAUS et al. , 1997 e HIRZINGER et al. , 1997), Webvideo e manipuladores (ÁLVARES & ROMARIZ, 1998 e WOLF & FREITZHEIN, 1997), televigilância (ALMEIDA et al. , 1995), entre outras.

A TeleRobótica pode ser definida como sendo uma área da Telemática e da Robótica voltada à teleoperação de sistemas robóticos utilizando-se de um link de comunicação (KLAUSS et al. , 1997). Uma nova terminologia está sendo empregada no caso de se utilizar a Rede de Comunicação Internet como link de telecomunicações. Neste caso, designa-se sistemas World Wide Web Robots, WebRobots ou simplesmente Internet Robots. Esta terminologia é válida para aplicações que utilizam Robôs Industriais, Manipuladores, Pan-Tilt, Máquinas de Comando Numérico e outros equipamentos industriais similares.

É desejável o controle e a monitoração de máquinas remotamente, centralizando sua supervisão, possibilitando o compartilhamento de pessoal e de recursos materiais e minimizando custos. Outra vantagem está associada à localização da aplicação que poderá estar na mesma planta industrial ou mesmo em outro país ou continente, possibilitando a conexão e a utilização dos serviços disponibilizados através da Rede de Comunicação Internet, sendo o cliente independente da aplicação tanto do ponto de vista geográfico quanto temporal.

A utilização da Internet como link de telecomunicações, na TeleRobótica, possibilita a diminuição de custos de comunicação, viabilizando aplicações voltadas ao suporte técnico, à manutenção e reparos, laboratórios remotos, controle de máquinas e robôs em locais que anteriormente eram inviáveis economicamente. Aplicações típicas de teleoperação no passado incluíam ambientes hostis (deserto, espaço, águas profundas, entre outros) e trabalhos tediosos (inspeção de oleodutos, ferrovias, etc.).

**Figure:** TeleRobot: robô ASEA IRB controlado via Internet.
$\resizebox*{14cm}{12cm}{\includegraphics{fig/fig4_1.ps.eps}}$

Atualmente, com links de comunicação via Internet/Intranet, por meio de fibra óptica, satélite, ADSL, modem e/ou rádio pode-se estabelecer uma conexão de qualquer parte do mundo a um Computador Servidor de Tarefas Industriais que disponibiliza uma série de serviços para a aplicação em questão. Plantas industriais, portanto, podem ser monitoradas e supervisio-nadas remotamente a um custo extremamente baixo (MONTEIRO et al. , 1997). Tarefas típicas como telediagnóstico de mal-funcionamento, telemanutenção e ambientes que implementem atividades de telemanufatura podem ser executadas diretamente do escritório do fornecedor ou mesmo de outra filial/matriz da empresa situada a milhares de quilômetros.

4.3 Metodologia: Sistemas Teleoperados Via Internet

Sistemas teleoperados remotamente necessitam de dados e/ou imagens do objeto de controle, bem como da transmissão de comandos através de um link de comunicação, que neste caso é baseado em conexão via Rede de Comunicação (WOLF et al. , 1997), através do Protocolo Internet (IP). A metodologia proposta, implementada e testada para TeleRobótica utilizando a Internet como link de comunicação é baseada na Arquitetura Cliente/Servidor utilizando o Protocolo HTTP (Hypertext Transfer Protocol) através de um Servidor WWW convencional (CERN, NCSA ou APACHE) que disponibiliza uma interface multimídia. Esta pode ser acessada através de um Cliente WWW (browser) como o Netscape, Arena ou Internet Explorer (ECKEL & HARE, 1995).

A arquitetura proposta do sistema é apresentada na figura 4.2. Como exemplos de equipamentos teleoperados têm-se: manipuladores com vários graus de liberdade; câmeras de vídeo, pan-tilt, robôs industriais, robôs móvel, máquinas de soldagem, máquinas de comando numérico, controladores lógicos programáveis, brinquedos; entre outros. Estes equipamentos são conectados ao servidor WWW, normalmente, através de uma interface serial, paralela, proprietária ou mesmo, via Rede Local de Comunicação Ethernet. O Browser WWW conecta-se ao Servidor WWW através do protocolo TCP/IP (Transport Control Protocol/Internet Protocol) podendo utilizar ligação discada (115 kbps) ou uma linha dedicada T1 ou T3 a 1,4 Mbps e 45 Mbps, respectivamente.

**Figure:** Arquitetura para teleoperação.
$\resizebox*{12cm}{8cm}{\includegraphics{fig/fig4_2.ps}}$

O cliente interage com o Servidor WWW utilizando a linguagem de programação HTML (Hypertext Markup Language). Os dados enviados ou solicitados pelo cliente utilizam o mecanismo de solicitação/resposta do Protocolo HTTP, disponibilizado pelo servidor. Os dados solicitados/enviados pelo usuário são codificados em URI/URL (Universal Resource Identifier/Uniform Resource Locator) e enviados para o Servidor HTTP.

4.3.1 Ambiente WWW

O servidor extrai as informações da URI, mais especificamente da URL, processa-as e retorna uma resposta HTTP. Uma URL é um subset de uma URI, sendo esta o endereço de um arquivo acessado via Internet (http://www.whatis.com/url.htm). A figura 4.3 apresenta este mecanismo.

**Figure 4.3:** Servidor HTTP (OTSUKA, 1996).
$\resizebox*{14cm}{10cm}{\includegraphics{fig/fig4_3.ps}}$

O Servidor HTTP utiliza-se de um recurso muito poderoso chamado CGI (Commom Gateway Interface). Através desta extensão do HTTP (ECKEL & HARE,1997) é possível executar um programa em "C" ou Perl, ou em outra linguagem ou script, para realizar uma determinada tarefa, conforme descrito no capítulo três. Por exemplo, pode-se executar um programa compilado especialmente para ser utilizado em um Servidor WWW, que controla o acionamento de um motor de passo através da conexão a um drive de potência do motor à interface paralela do servidor (ÁLVARES & ROMARIZ, 1998). A figura 4.4 apresenta o mecanismo CGI, onde a URI aponta para o programa executável. A figura 4.5 apresenta uma parte do código fonte deste programa em linguagem "C" para controlar o acionamento de um motor de passo.

**Figure 4.4:** Servidor HTTP e CGI.
$\resizebox*{14cm}{9cm}{\includegraphics{fig/fig4_4.ps}}$

**Figure:** Programa CGI em "C ++" (pmp.c) para acionamento de motor de passo via interface paralela utilizado no sistema RobWebCam (ÁLVARES & ROMARIZ, 1998).
$\resizebox*{14cm}{14cm}{\includegraphics{fig/fig4_5.eps}}$

4.3.2 Servidor WWW: servidor WebCam e servidor de teleserviços industriais (WebRobot)

O Servidor HTTP (WWW) deve, preferencialmente, ser baseado em plataforma Unix o que possibilita maior robustez, flexibilidade, modularidade e até mesmo a necessidade de máquinas com menor capacidade de processamento, quando comparado ao ambiente Windows NT. O Sistema Ope-racional Linux em plataforma PC (Personal Computer) é uma opção extremamente atraente satis-fazendo todos os requisitos das aplicações de teleserviços para teleoperação de Robôs e máquinas de comando numérico. Neste contexto, o Servidor HTTP deve disponibilizar dois tipos de serviços básicos, que estão respresentados na figura 4.6 através de dois módulos:

WebCam: Visualização do objeto teleoperado, através de vídeo e/ou imagem;
WebRobot: Disponibilização de funções de controle remoto do objeto teleoperado.

4.3.2.1 Servidor WebCam: Visualização do objeto teleoperado

Este módulo é responsável pela captura de imagens através de câmeras CCD (Charge Coupled Device) utilizando-se da tecnologia WebCam (ÁLVARES & ROMARIZ, 1998) ou WebVideo (WOLF & FROITZHEIM, 1997). Imagens estáticas podem ser adquiridas em vários formatos como GIF (Graphics Interchaning Format) e JPEG (Joint Photographic Experts Group). O formato preferido devido à compressão de dados obtida é o JPEG. Imagens dinâmicas, no formato de vídeo digital, podem ser utilizadas com ou sem compressão de dados. Entre os padrões utilizados têm-se o MPEG (Moving Picture Experts Group), UYVY, RealVideo, M-JPEG (seqüência de imagens JPEG), CellB (Cell) e CuSee-Me, entre outros (SUN, 1994) e (CONNECTIX, 1996).

O sistema de vídeo (placa de captura mais software) deve capturar, digitalizar e comprimir um sinal de vídeo NTSC ou PAL não modularizado (composto ou S-Vídeo). O vídeo comprimido pode então ser armazenado em disco e/ou transmitido via rede para o cliente em um determinado padrão de compressão.

**Figure:** Servidor HTTP: módulos WebCam e WebRobot.
$\resizebox*{14cm}{10cm}{\includegraphics{fig/fig4_6.ps}}$

No caso de se utilizar seqüência de imagens JPEG, a taxa de compressão é muito baixa quando comparada com a MPEG ou RealVideo. A principal vantagem é que se pode enviar as imagens de vídeo utilizando o mecanismo server-push do Servidor HTTP diretamente para o cliente WWW, como o Netscape, sem a necessidade de se utilizar um software especial ou um plug-in para receber o formato de vídeo (OTSUKA, 1996). Para utilizar a compressão é necessário um software específico (plug-in) que deverá ser instalado pelo cliente e ajustado ao ambiente para receber imagens no formato especificado, normalmente, MPEG ou RealVideo (MELCHIORS, 1996). Com relação ao hardware para captura de imagens pode-se utilizar: câmeras de vídeo (NTSC ou PAL) conectadas a uma placa para frame grabber (SUN, 1994); ou câmeras com placa para captura de imagens com CCD utilizando a interface paralela ou USB (Universal Serial Bus) como entrada de vídeo para o micro-computador, como no caso da QuickCam (CONNECTIX, 1996). A grande desvantagem da utilização deste hardware esta associada a menor qualidade e a baixa velocidade de captura de imagens obtida, devido às restrições de velocidade da interface paralela e USB.

4.3.2.2 Servidor WebRobot: funções de controle remoto do objeto teleoperado.

A fim de teleoperar o sistema Robótico é necessário que o mesmo tenha como pré-requisito alguma capacidade de comunicação remota utilizando um protocolo de comunicação aberto através de uma interface serial, paralela ou mesmo de uma Ethernet, permitindo a conexão a um Microcomputador ou a uma Workstation. Utilizando-se desta capacidade é possível que qualquer equipamento industrial possa ser teleoperado via Internet. A partir desta abordagem, disponibiliza-se um Servidor Robótico, denominado WebRobot, conectado ao equipamento industrial através da interface de comunicação do equipamento. Este servidor pode ser um servidor HTTP, de forma similar ao descrito para o WebCam (figura 4.6). O mecanismo de acesso às funções do objeto teleoperado é também baseado em programas CGI e HTML. Para cada função disponibilizada pelo protocolo de comunicação do Robô existe um programa CGI que é acessado no servidor WebRobot pelo cliente utilizando um browser WWW. Pode-se utilizar o mesmo equipamento para disponibilizar os dois serviços: WebCam e WebRobot.

Por outro lado, pode-se também utilizar dois ou mais servidores para realizar as funções de WebCam e WebRobot. Uma segunda abordagem é utilizar um único Servidor WWW conectado a um ou mais PC servidores via sockets TCP/IP. Estes PC servidores não são necessariamente servidores WWW. São servidores específicos para controle do Robô e para captura de imagem, sendo que todo o tratamento das informações obtidas é realizado pelo Servidor WWW, concentrando todas as ações. A figura 4.7 apresenta esta abordagem.

**Figure 4.7:** Servidor WWW centralizado.
$\resizebox*{14cm}{10cm}{\includegraphics{fig/fig4.7.eps}}$

Nesta configuração todas as informações solicitadas passam pelo Servidor WWW que estabelece a comunicação via Rede Local de Comunicação (Intranet) através de sockets TCP/IP utilizando-se de programas CGI ou mesmo de servidores específicos.

4.3.3 Restrições do Protocolo Internet - TCP/IP

A Rede de Comunicação Internet apresenta uma largura de banda heterogênea e com taxas de transmissão não determinísticas que podem variar de 10 kbps (ligação discada) a mais de 100 Mbps em rede local (Fast Ethernet), dependendo da conexão Internet e do tráfego. Tendo limi-tação de largura de banda, aplicações em tempo real para captura de vídeo apresentam sérias restrições. Para vencer estas restrições é necessário utilizar compressão de dados e conexão de grande velocidade à Internet. Taxas típicas de transmissão de vídeo com compressão necessitam de 20 Kbps (RealVideo), e sem compressão, de 100 Kbps (seqüência de imagens JPEG) com 5 quadros/s (MELCHIORS,1996). Outra limitação é o delay (atraso) inerente ao protocolo TCP/IP, o que não é desejável para aplicações em tempo real. Esta restrição pode ser resolvida adicionando algum grau de autonomia para a aplicação, no caso um Robô, de tal forma a contornar situações de emergência, bem como, situações perigosas. Recomenda-se, sempre que possível, que o sistema de teleoperação seja concebido para trabalhar em uma arquitetura baseado no controle supervisório, ou seja, as ações de controle são executadas localmente. Assim este nível de autonomia é obtido localmente no Servidor WebRobot, que deve monitorar estas condições limites (HIRZINGER et al. , 1997). Apesar dos datagramas com informações de controle enviados para o Robô pelo cliente via Protocolo TCP/IP serem pequenos, da ordem de 2 a 3 Kbytes, o Protocolo TCP não garante aplicações em tempo real. Uma alternativa para o futuro é utilizar o Protocolo RTP (Real-Time Transport Protocol) para aplicações em tempo real (OTSUKA, 1996).

4.3.4 Interface com o Usuário

A interface gráfica com o usuário (GUI - Graphical User Interface) deve ser baseada nas linguagens de programação HTML, JAVAScript e JAVA (OTSUKA, 1996). A utilização de JAVA permite uma independência de arquitetura de hardware, pois o applet escrito em JAVA (aplicação JAVA) pode ser executado em qualquer plataforma com um browser WWW que tenha suporte para esta linguagem. O programa em JAVA/HTML permite que o cliente tenha uma interface amigável com o sistema de teleoperação aceitando comandos e disparando os programas CGI necessários para executar as funções disponibilizadas e apresentando as informações necessárias para o usuário que são recebidas pelo servidor (figuras 4.8 e 4.9).

**Figure:** Sistema RobWebLink: interface com o usuário.
$\resizebox*{16cm}{10cm}{\includegraphics{fig/fig4_8.eps}}$

A realimentação visual é feita através do Servidor WebCam, que do lado do cliente apresenta uma interface amigável que recebe as imagens em formato comprimido (MPEG ou RealVideo) ou em uma seqüência de imagens JPEG. As figuras 4.8 e 4.9 apresentam alguns exemplos de interfaces com usuários, que foram desenvolvidas em projetos de teleoperação executados no GRACO (Grupo de Automação e Controle) da Universidade de Brasília. A figura 4.8 apresenta a interface do sistema RobWebLink (http://webrobot.graco.unb.br) e a figura 4.9 do sistema RobWebCam (http://www.graco.unb.br/robwebcam). Outra abordagem é a utilização de VRML (Virtual Reality Modeling Language). VRML é uma linguagem de descrição de simulações interativas com vários participantes se comunicando através da Internet (OTSUKA, 1996). O objetivo do desenvolvimento desta linguagem é torna-la um padrão para a descrição de simulações interativas no WWW, assim como a linguagem HTML é o padrão para descrição de páginas Web. Sua principal característica para aplicações de TeleRobótica está associada a capacidade de operar em conexões com pequena largura de banda, o que a torna uma candidata em potencial para ser utilizada

**Figure:** Sistema RobWebCam: interface com o usuário.
$\resizebox*{14cm}{10cm}{\includegraphics{fig/fig4_9.eps}}$

4.4 Aplicações Desenvolvidas

São apresentadas quatro aplicações desenvolvidas pelo doutorando utilizando esta metodologia: RobWebCam (figura 4.9) e RobWebLink (figura 4.8), Robô Móvel MRL 1.0 e a teleoperação do robô Nomad XR4000, o que possibilitou a validação da metodologia.

4.4.1 Sistema RobWebCam (http://www.graco.unb.br/robwebcam)

O Sistema RobWebCam é constituído por um manipulador com 2 DOF (Degree-of-Freedom), que suporta uma câmera de vídeo, sendo acionado por motores de passo. Estes motores são controlados através de uma placa de circuito impresso, que contém o driver de potência e o módulo de alimentação elétrica do equipamento. A placa comunica-se com o servidor do manipulador (WebRobot) através da interface paralela. Este servidor, WebRobot, contém os programas de controle. A câmera (SunVideo) possui alimentação própria de energia e é interligada ao servidor WebCam através de um cabo de sinal de vídeo conectado na placa de captura de vídeo do Servidor. No Servidor WebCam estão alocados o driver (programa em CGI) para receber as imagens e as páginas WWW utilizadas para teleoperar o sistema. O cliente, via browser (figura 4.9), recebe as imagens e os comandos deste servidor via Internet. Esta arquitetura é minuciosamente descrita em ÁLVARES & ROMARIZ (1998). O sistema pode ser acessado através do endereço http://www.graco.unb.br/robwebcam.

4.4.2 Sistema RobWebLink (http://webrobot.graco.unb.br)

Este sistema permite o controle remoto do Robô Industrial com seis graus de liberdade IRB 2000 da Asea Brown Boveri (ABB) utilizando a Internet como via de controle. O controlador do Robô ABB IRB 2000 tem incorporado um sistema de controle remoto através da interface serial RS-232 baseado em 42 funções, que se utilizam de um protocolo de comunicação proprietário. A partir desta capacidade de comunicação remota, desenvolveu-se um servidor WWW (WebRobot) conectado ao robô via interface serial, disponibilizando o controle remoto do robô, através das 42 funções, em rede de comunicação utilizando o protocolo TCP/IP. A operação de controle remoto é monitorada através de captura de imagem em tempo real, utilizando o sistema RobWebCam (Servidor WebCam), além de informações e status do Robô enviadas pelo seu controlador. O sistema de teleoperação desenvolvido está disponível no endereço http://webrobot.graco.unb.br e pode ser operado remotamente permitindo a comunicação entre o servidor WWW e o Controlador do Robô.

A velocidade de transmissão de dados requerida para os serviços disponibilizados referentes aos comandos das funções do Robô é baixa, não comprometendo o sistema de teleoperação, apesar da latência inerente à Internet. Entretanto, esta latência faz com que a realimentação gráfica, através de vídeo on-line, seja viável quando se utiliza de velocidades de transmissão acima de 64 Kbps. Recomenda-se também a utilização de compressão de dados. O sistema está em operação desde maio de 1998. Só é permitido acesso a clientes devidamente cadastrados. Assim, o Servidor WebRobot solicita senha e password ao usuário do sistema, por questões de segurança (usuário devidamente cadastrado), bem como, devido à resposta do Robô e do Servidor WWW que pode ser degradada em função de atrasos de comunicação entre o servidor WWW e o cliente.

Entretanto serviços que necessitam de uma pequena largura de banda, como inicialização do Robô, iniciar programa, ligar e desligar Robô, dowload e upload de programas, entre outros, são plenamente satisfeitos. A evolução do sistema é prevista aplicando a mesma metodologia para controlar via Internet uma Célula Flexível de Soldagem.

4.4.3 Teleoperação do Robô Móvel MRL 1.00 (http://robomovel.graco.unb.br)

Este sistema é um Robô Móvel Autônomo controlado remotamente via Internet utilizando o sistema operacional Linux como plataforma de controle e comunicação. A locomoção é realizada através de motores de passo, controlados por um driver de potência e programas em linguagem C. A estrutura do robô foi fabricada em alumínio, consistindo em um chassi com três níveis: o primeiro contendo motores e alimentação elétrica (baterias ou alimentação elétrica externa). O segundo abrigando uma placa mãe Pentium (responsável pelo controle do sistema) e uma placa de Rede Ethernet. O terceiro nível é constituído por um link de comunicação via rádio/Internet (Adaptador Ethernet) e uma câmera CCD (Charge Coupled Device). O controle via Internet é realizado através de uma interface Java/CGI (Common Gateway Interface) que envia os comandos do usuário para o sistema de navegação do robô (via rádio) tendo uma realimentação visual através de um sistema de captura de vídeo baseado em uma WebCam.

4.4.4 Teleoperação do Robô Nomad XR4000 (http://nomad.graco.unb.br)

Este sistema permite a navegação do robô móvel XR4000 da Nomadic via Internet . O sistema de teleoperação utiliza como ferramenta de comunicação de dados a linguagem de programação Java, apresentando ao usuário imagens obtidas do ambiente remoto assim como dados sensoriais do robô, permitindo o controle de movimentos do robô e da câmera embarcada no sistema. Devido às restrições de velocidade de comunicação as imagens capturadas são comprimidas no formato JPEG, permitindo assim um menor consumo de banda de comunicação e melhorando a apresentação das imagens ao usuário. A necessidade de um sistema seguro de controle do robô e devido aos atrasos inerentes à comunicação via Internet levaram à utilização de um sistema de controle de velocidade do robô baseado na lógica fuzzy. Este controlador é responsável pela segurança do sistema, através do monitoramento dos dados sensoriais do ambiente e do controle da velocidade do robô. Testes realizados com o sistema validaram a metodologia de teleoperação desenvolvida.

4.5 Telerobótica: Teleoperação do Robô ABB IRB 2000 Via Internet

O controlador do Robô ABB IRB 2000 tem incorporado um sistema de controle remoto através da interface serial RS-232 baseado em 42 funções. O sistema utiliza-se desta capacidade de comunicação remota interligando o sistema, em rede local de comunicação, utilizando o protocolo TCP/IP (Transport Control Protocol/Internet Protocol). O sistema concebido é baseado na arquitetura cliente/servidor, tendo como servidor uma plataforma UNIX (Linux) que disponibiliza o serviço WWW, que será acessado pelo cliente utilizando um browser (Netscape ou Explorer). O servidor WWW conectado ao Robô via interface serial disponibiliza as funções de controle. A teleoperação é monitorada através da captura de imagem em tempo real e informações/status do Robô são enviadas pelo seu controlador.

4.5.1 Arquitetura do Sistema (Módulos WebCam e WebRobot)

Sistemas teleoperados remotamente necessitam de dados e/ou imagens do objeto de controle, bem como, da transmissão de comandos através de um link de comunicação, que neste caso é baseado em conexão via Rede de Comunicação (SCHILLING et al. , 1997), através do Protocolo Internet (IP). A figura 4.10 apresenta a arquitetura do sistema, onde o Servidor Unix HTTP (Hypertext Transfer Protocol) disponibiliza dois tipos de serviços básicos, que estão representados na figura 4.1 através de dois módulos: WebCam e WebRobot, já descritos anteriormente.

4.5.1.1 Servidor WebCam: visualização do objeto teleoperado

É utilizado o sistema RobWebCam desenvolvido no GRACO em 1997 (ÁLVARES & ROMARIZ, 1998) como servidor WebCam. O sistema de vídeo é baseado na SunVideo (SUN, 1994) que possibilita a captura, digitalização e compressão em formato JPEG (Joint Photographic Experts Group) de um sinal de vídeo NTSC ou PAL não modularizado (composto ou S-Vídeo). Assim, utilizou-se a plataforma Solaris como WebCam. Cabe destacar que o sistema RobWebCam tem um manipulador (Pan-tilt) que pode posicionar a câmera para possibilitar uma melhor monitoração do ambiente (ÁLVARES & ROMARIZ, 1998). Utiliza-se uma seqüência de imagens JPEG, cuja principal vantagem está associada no envio de imagens de vídeo utilizando o mecanismo server-push do Servidor HTTP diretamente para o cliente WWW, como o Netscape, sem a necessidade de se utilizar um software especial ou um plug-in para receber o formato de vídeo (OTSUKA, 1996).

**Figure:** Arquitetura do sistema de teleoperação via Internet: WebCam e WebRobot.
$\resizebox*{14cm}{8cm}{\includegraphics{fig/fig4_10.eps}}$

O driver WebCam utilizado pode ser obtido no endereço: http://lrcwww.epfl.ch/ oechslin/ wc_download.html. O WebCam possui um modo de operação que permite a renovação periódica da imagem de maneira que o cliente possa visualizar a última imagem atualizada. Este driver é um aplicativo escrito em linguagem C para plataforma Solaris que pode ser utilizado como um programa CGI (Commom Gateway Interface) a partir do servidor HTTP. Este pode reproduzir desde imagens JPEG simples até seqüências de imagens JPEG formatadas em mensagens MIME de múltiplas partes.

4.5.1.2 Servidor WebRobot: funções de controle remoto do objeto teleoperado

A fim de teleoperar o Robô utiliza-se o protocolo de comunicação ADLP-10 da ABB através de uma interface de comunicação serial conectado ao Servidor HTTP - WebRobot. O servidor WebRobot é implementado no sistema operacional Linux. O mecanismo de acesso às funções do objeto teleoperado é também baseado em programas CGI e HTML (Hypertext Markup Language). Para cada função disponibilizada pelo protocolo de comunicação do Robô existe um programa CGI que é acessado no servidor WebRobot pelo cliente utilizando-se de um browser WWW.

4.5.2 Definição dos sub-sistemas para a interface de teleoperação

A partir da arquitetura definida para o sistema implementou-se o ambiente de teleoperação em uma plataforma multiusuário utilizando os Sistemas Operacional Linux e Solaris, desenvolvendo-se três sub-sistemas de interface com o usuário (fig. 4.11):

interface cliente/servidor (Páginas visualizadas com Browser);
interface de comunicação servidor/controlador do Robô (Servidor HTTP - WebRobot);
interface de monitoração visual do sistema (Servidor HTTP - WebCam).

4.5.2.1 Interface cliente e servidor

A utilização do protocolo TCP/IP, Internet/Intranet (ECKEL & HARE, 1995), para a comunicação entre o cliente e o servidor é bastante atrativa devido a sua presença no mundo inteiro, através da Internet. Há alguns problemas quando se utiliza o protocolo TCP/IP, pois a aplicação pode sofrer atrasos (delays) não apresentando um tempo determinístico de acesso, o que não é desejável para aplicações em tempo real. A utilização de servidor WWW apresenta uma interface rica e simples de ser utilizada. Os clientes/navegadores apresentam texto, gráficos, vídeo e áudio, permitindo uma comunicação multimídia entre cliente e servidor. O cliente acessa o servidor UNIX via WWW, e de maneira interativa define as tarefas a serem executadas pelo Robô, que retornará uma confirmação ou negação da execução para o cliente, bem como, uma imagem em tempo real do ambiente onde se encontra o Robô.

**Figure:** Sub-sistemas do sistema telerobótico RobWebLink (Robot Web Link).
$\resizebox*{14cm}{8cm}{\includegraphics{fig/fig4_11.eps}}$

4.5.2.2 Servidor e controlador

O Robô ABB IRB 2000 dispõe de uma porta serial para a comunicação com um computador pessoal (Computer Link) através do protocolo ADLP-10 (ABB Data Link Protocol) (ABB ROBOTICS, 1993), utilizando comunicação assíncrona entre o servidor UNIX e o controlador do Robô, com palavras de oito bits, paridade e stop bit. A função básica do protocolo é estabelecer a comunicação, coordenando o envio e recebimento de dados, enviados em bloco. Cada bloco de dados é composto de um telegrama, que por sua vez é descrito pela biblioteca ARAP (ABB Robot Aplication Protocol). O procedimento de comunicação é somente aplicável ponto-a-ponto, ou seja a comunicação de duas unidades de equipamento onde uma é superior a outra (master/slave). A biblioteca ARAP é composta de 42 funções de troca de dados entre o Robô e o computador, des-crevendo a forma como os dados e respostas do Robô são enviados e códigos de erro que podem ocorrer em uma transmissão de dados.

4.5.2.3 Monitoramento

Para garantir a segurança na execução das funções de comando, além das respostas enviadas pelo controlador do Robô, é necessário o monitoramento através da captura de imagens em tempo real. Outro fator importante para a segurança é verificar quais são os usuários que estão acessando o servidor e controla-lo por meio de senhas. O monitoramento por vídeo é feito por uma câmera (SUN, 1994) conectada a um servidor que envia as imagens via WWW. A realimentação gráfica é viável quando se utiliza de velocidades de transmissão acima de 64 Kbps.

4.5.2.4 Especificação do hardware: WebRobot

O hardware utilizado para o sistema é composto pelo Robô ABB IRB 2000, pelos servidores WWW (Linux e Solaris) e pelo cliente que acessará os servidores que controlam a teleoperação do Robô, a captura de imagem e posicionamento da câmera que possibilita a realimentação visual. O modelo IRB 2000 da Asea Brown Boveri, é um manipulador industrial equipado com funções para soldagem a arco, com seis graus de liberdade, capacidade máxima de carga de 10 kg e sua linguagem de programação nativa é a ARLA. Os servidores UNIX são: um computador pessoal com o sistema operacional (OS) Linux e uma Workstation Sparc20 com OS Solaris 2.6.

4.5.3 Descrição do protocolo ADLP-10/ARAP

O protocolo ADLP-10 é um procedimento para comunicação assíncrona entre duas estações com um sistema de hierarquia, transmissão assíncrona serial no modo half-duplex, possibilidade de início de transmissão por ambos os lados (superior e subordinado). O quadro de dados é composto por: palavra de 8 bits + 1 bit de paridade + 1 stop bit. A função básica do ADLP-10 é estabelecer a comunicação verificando o envio e recebimento de mensagens, que são divididas em blocos, garantindo a integridade dos dados transmitidos. A verificação da integridade é feita através da paridade e pela soma de checagem do bloco. Cada bloco de dados é composto de um telegrama, descrito pela biblioteca ARAP.

4.5.3.1 O protocolo ADLP-10

O protocolo de comunicação define alguns sinais que podem ser utilizados por qualquer uma das estações (computador ou Robô) para iniciar uma comunicação. Cada sinal tem uma função durante o processo de comunicação. Se os sinais não forem enviados de maneira correta a comunicação é interrompida. Para iniciar a comunicação a estação envia um ENQ (enquiry) dessa forma ela espera uma resposta da outra estação para verificar se ela está pronta para continuar o processo de comunicação. As respostas possíveis são: ACK (acknowledge) que a estação receptora responde quando está pronta para comunicar-se; WACK (wait and acknoeledge) indica que a estação receptora está funcionando mas não está pronta para a comunicação; RVI (reverse interrupt) indica que a estação deseja enviar a mensagem e não recebê-la; NAK (negative acknowledgement) indica que a estação receptora não reconhece a comunicação. Para o controle do telegrama existem outros sinais: DLE (Data Link Escape) indica quando inicia e quando termina o campo de dados do telegrama, STX (Start of text) verifica a paridade do envio de mensagens podendo ser par ou ímpar e EOT (End of Transmission) que finaliza a comunicação entre as estações.

4.5.3.2 A biblioteca ARAP

A Biblioteca ARAP descreve 42 funções de troca de dados entre o Robô e o computador e a formatação dos telegramas de envio de dados e de recebimento, bem como, os códigos de erro respondidos pelo Robô. Um telegrama sempre consiste de um Cabeçalho e um Campo de Dados. Todos os dados enviados pelo telegrama são enviados na forma binária. O Cabeçalho sempre possui o mesmo número de bytes e é composto por campos que estão sempre na mesma posição. O campo de dados possui tamanho e conteúdo variável dependendo da função a ser executada. O cabeçalho contém informações a respeito do tamanho do telegrama e do tipo do telegrama. O código da função a ser executada, pode ser visualizada na estrutura do telegrama na figura 4.12. O Number of Bytes ou NOB determina o número de bytes pelos quais o telegrama é composto. Este ocupa dois bytes do cabeçalho. O Destination Adress determina quem será o a estação receptora do telegrama, utiliza-se normalmente 1 para o Robô e zero para o computador, esse byte (byte 2) é semelhante ao Source Adress que determina a estação que enviou o telegrama.

**Figure 4.12:** Estrutura do telegrama definido pela biblioteca ARAP.
$\resizebox*{12cm}{7cm}{\includegraphics{fig/fig4_12.eps}}$

O Function Code especifica o número da função a ser executada. As funções foram divididas em três grupos de operações básicas: as funções de programa, as funções de leitura e as funções de escrita. Os valores para MLI (Message Lenght Indicator), RS (Response Status) e TT (Telegram Type) são alinhados e enviados como um único byte. O MLI refere-se ao comprimento do telegrama (se possui ou não uma continuação). O RS comunica se a resposta é ou não um código de erro. O TT indica se o telegrama é um comando, uma resposta ou uma mensagem espontânea enviada pelo Robô. O Function Suffix é específico para cada função dando opções para o uso daquela função.

4.5.4 Especificação do software de teleoperação do Robô: interface RobWebLink

As funções especificadas pela biblioteca ARAP foram divididas em três grupos, conforme apresentado na figura 4.13.

**Figure:** Arquitetura, fluxo de dados e funções disponibilizadas pelo RobWebLink.
$\resizebox*{14cm}{12cm}{\includegraphics{fig/fig4_13.eps}}$

Através das funções de leitura são obtidos os dados de configuração e memória do Robô. Com as funções de escrita o usuário pode alterar as configurações. Com as funções de programa o usuário pode fazer uploads e downloads de programas, bem como executar programas que estejam na memória do Robô. Utilizou-se para o desenvolvimento do sistema as linguagens de programação C, HTML, CGI, JAVA e JAVASCRIPT (MONTEIRO et al. , 1997). O sistema de teleoperação desenvolvido está disponível em http://webrobot.graco.unb.br/. O cliente acessa a homepage com uma tela de comando dividida em frames correspondentes as funções, bem como às várias informações referentes ao Robô. Cada função possui uma página WWW correspondente, que descreve o funcionamento da função e pede para que o usuário defina os parâmetros da função. A leitura desses parâmetros é feita por um CGI, programado em C da GNU. A interface entre o servidor e o controlador do Robô estabelece a comunicação segundo o protocolo ADLP-10, enviando via RS232C os telegramas e recebendo suas respectivas respostas ou mensagens de erro, que são apresentadas no formato html e visualizadas na tela de comando.

4.5.5 Implementação do sistema RobWebLink (http://webrobot.graco.unb.br)

O sistema implementado é baseado em uma arquitetura cliente/servidor em plataforma UNIX, utilizando o Linux, como servidor HTTP para a disponibilização do serviço WWW. Para o moni-toramento utiliza-se o sistema RobWebCam (ÁLVARES & ROMARIZ, 1998). A figura 4.14 apre-senta a estrutura do sistema. O cliente conecta-se ao Robô através do servidor Telerobótico (WebRobot). O cliente envia formulários WWW e recebe os telegramas de resposta do Robô. O servidor WebCam está conectado ao WebRobot fazendo a captura de vídeo e enviando comandos para a movimentação da câmera. O acesso ao sistema é permitido a partir de senhas.

4.5.5.1 Interface cliente/servidor

Foi desenvolvida uma Interface com o usuário onde são controladas todas as funções (Figura 4.8). Através dos menus pode-se acessar os arquivos correspondentes as funções da biblioteca ARAP. Foi criado um arquivo HTML para cada função que pode ser executada pelo Robô, que aparece na tela de funções. Há um menu de opções que permite ativar a realimentação gráfica. A tela de status permite que o estado do Robô apareça na tela (posição, modo de operação e configurações principais). A tela de envio (caixa de envio) apresenta o telegrama a ser enviado, podendo ser corrigido ou editado antes do envio. A tela de recebimento mostra o campo de dados do telegrama recebido do Robô. A figura 4.8 apresenta a tela principal do Sistema RobWebLink, onde pode ser visualizado nos frames superiores os menus onde o usuário seleciona as funções. Na segunda linha de frames as três janelas são: a janela de status, a janela de realimentação gráfica e a janela de função. Na terceira linha estão as janelas de envio e recebimento de mensagens.

**Figure 4.14:** Diagrama de fluxo de dados do sistema.
$\resizebox*{14cm}{8cm}{\includegraphics{fig/fig4_14.eps}}$

Utilizou-se os formulários eletrônicos do HTML para permitir o envio de parâmetros necessários em cada uma das diferentes funções. Cada função é tratada individualmente por um CGI, de forma modular

4.5.5.2 Servidor e Controlador

O sistema foi desenvolvido em C++ da GNU para Linux. Desenvolveu-se os programas para serem executados via WWW/HTTP por programas CGI, que implementam o protocolo ADLP/10. Desta forma cada uma das funções tem o seu programa correspondente. Cada programa CGI possui módulos que realizam as seguintes tarefas:

Leitura dos dados enviados pelo formulário;
Montagem do Telegrama a ser enviado;
Inicialização da Porta Serial;
Estabelecimento da comunicação com o Robô;
Envio e recebimento de Telegramas;
Verificação do telegrama recebido;
Montagem da webpage que será apresentada ao usuário com a resposta.

4.5.5.3 Monitoramento - RobWebCam (http://www.graco.unb.br/robwebcam)

Foi utilizado o sistema RobWebCam (ÁLVARES & ROMARIZ, 1998) para monitoração visual da operação do sistema. O usuário pode acessar o menu de opções e movimentar a câmera através de um joystick virtual (figura 4.9). O ideal seria ter várias câmeras em várias posições diferentes para que o usuário escolhesse a melhor visão, detalhada e/ou global.

4.6 Telerobótica: Teleoperação do Robô Móvel MRL 1.0 Via Internet

A arquitetura do sistema baseia-se no modelo cliente-servidor, que divide as atribuições do sistema em um servidor, representado pela página HTML (Hiper Text Markup Language) e programas CGI localizados no robô móvel; e o cliente, representado pelo applet Java, funcionando no browser do usuário. Entre o cliente e o servidor encontra-se a rede Internet, que permite a comunicação entre os módulos (figura 4.15). O servidor MRL é composto de dois módulos principais (ÁLVARES, 1999): WebCam e WebRobot.

O applet Java, carregado no browser do usuário no instante que o mesmo acessa a página HTML do sistema (http://robomovel.graco.unb.br), é responsável pelo envio de comandos de movimentação do robô, através de requisições à programas CGI-BIN, desenvolvidos em linguagem C, localizados no servidor. O servidor, além de processar os comandos CGI, é responsável pela captura de vídeo, WebCam, e o envio das imagens para o browser. Tem-se, assim, uma interação entre o usuário e o ambiente em que o robô se encontra.

**Figure:** Arquitetura do sistema de teleoperação.
$\resizebox*{14cm}{9cm}{\includegraphics{fig/fig4_15.eps}}$

4.6.1 Implementação Física do Robô Móvel

A estrutura desenvolvida visa a modularização, sendo organizada em níveis (figura 4.16):

na parte inferior (primeiro nível) encontram-se os sistemas de movimentação, sensorial e energia;
no segundo nível tem-se o controlador (placa mãe de um Pentium de 75 Mhz);
e no terceiro nível o sistema de comunicação e vídeo.

Figure: (a) Arquitetura física do robô desenvolvido ; (b) Circuito de potência dos motores de passo; (c) Adaptador Ethernet utilizado no robô móvel (RangeLan 2 7921, Proxim).
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig4_16.ps}}$

**Figure:** (a) Arquitetura física do robô desenvolvido ; (b) Circuito de potência dos motores de passo; (c) Adaptador Ethernet utilizado no robô móvel (RangeLan 2 7921, Proxim).
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig4_16.ps}}$

A figura 4.17 mostra um diagrama de fluxo de dados entre os módulos do sistema. O sistema de alimentação é representado por uma fonte de tensão de computador ligada à rede elétrica, colocada na parte posterior do nível inferior. Uma implementação futura incluirá a utilização de baterias recarregáveis para permitir uma maior autonomia do sistema. Ainda no primeiro nível estão presentes duas "antenas" ou whiskers que funcionam como sensores de toque para o reconhecimento de obstáculos pelo robô. São utilizados sensores binários, tipo liga-desliga, conectados às entradas da interface paralela do controlador. No futuro serão utilizados sensores para medição de distâncias ultrasônico e infravermelho com saída TTL (Transistor-Transistor Logic) conectados diretamente à interface paralela.

O sistema de locomoção é composto por um conjunto de motores de passo, que controlam os movimentos do robô através do deslocamento diferencial de duas rodas. Uma terceira roda de borracha é utilizada como apoio do conjunto. Os motores são alimentados através de um driver de potência, baseado no chip ULN 2003A (GADRE, 1998) e no transístor TIP 120. Este driver é controlado através da interface paralela do módulo controlador. A figura 4.16 mostra um esquema do circuito desenvolvido.

O controlador é representado por um computador pessoal tipo PC (Personal Computer) Pentium, funcionando sob o sistema operacional Linux e programado através da linguagem C. O sistema de comunicação utilizado (terceiro nível) baseia-se em um rádio adaptador Ethernet da Proxim (figura 4.17), que conecta-se a um bridge (RangeLan2 7510, Proxim) presente no laboratório, interligando o sistema à rede Internet. A utilização de um sistema de rádio para a comunicação com o robô deu-se devido aos seguintes fatores:

mobilidade, ou seja, um sistema robótico móvel não deve possuir cabos ligando-o a uma base fixa;
sistemas a rádio são adequados para pequenas distâncias (300 m), entre o adaptador e o bridge, ou para maiores distâncias utilizando antenas mais potentes e vários repetidores/bridge em um ambiente de células, similar à telefonia celular.

Figure: Módulos integrantes do sistema.
$\resizebox*{15cm}{15cm}{\includegraphics{fig/fig4_17.ps}}$

**Figure:** Módulos integrantes do sistema.
$\resizebox*{15cm}{15cm}{\includegraphics{fig/fig4_17.ps}}$

A figura 4.18 apresenta a infra-estrutura de comunicação utilizada no laboratório do GRACO, incluindo o servidor, o robô móvel desenvolvido e o robô Nomad XR4000 (http://www. robots. com), também integrante do ambiente. Observa-se que a bridge é a parte responsável pela interconexão entre os diversos adaptadores móveis à rede local do laboratório. A captura de imagens é reali-zada através de uma câmera tipo WebCam (ÁLVARES, 1998), que envia suas imagens através de um driver para páginas HTML (Hiper Text Markup Language) ou aplicativos Java. O sistema de animação utilizado para as imagem é provido automaticamente pelo browser utilizado pelo usuário.

**Figure:** Arquitetura de comunicação utilizada no robô móvel.
$\resizebox*{14cm}{6cm}{\includegraphics{fig/fig4_18.ps}}$

A figura 4.19 apresenta fotos do robô desenvolvido, onde podem ser observados os módulos.

**Figure:** Robô móvel desenvolvido no GRACO (MRL 1.00).
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig4_19.ps}}$

4.6.2 GUI (Graphical User Interface) Para Teleoperação

A interface de teleoperação (GUI) desenvolvida é baseada na linguagem de programação Java, permitindo uma boa interação usuário-robô. São utilizados quatro botões que controlam a translação e a rotação do robô, no plano XY, e um quinto botão responsável pela implementação do algoritmo de navegação autônoma.

A figura 4.20(a) apresenta a página de entrada do sistema na Internet. Na figura 4.20(b) pode ser vista a interface desenvolvida. Na parte superior do console encontra-se a imagem recebida pela câmera localizada no robô, o que possibilita a visualização do ambiente remoto. A parte inferior do console é responsável pelo controle posicional do robô. Destaca-se nesta parte o botão Walk, responsável pela navegação autônoma do sistema.

Assim, se o usuário deseja que o robô caminhe 3 metros adiante, evitando possíveis obstáculos, deve ajustar a distância D para 3000 mm, ativar o sistema autônomo através do checklist Auto, e enviar o comando através do botão Walk. O robô tentará então, utilizando seus sensores de toque, navegar de forma autônoma até o ponto final desejado, a 3 metros a frente. Ainda na parte inferior são localizados dois botões, Help e Configure, responsáveis, respectivamente, pela abertura de uma janela de ajuda ao usuário, contendo instruções sobre o funcionamento do sistema; e pela configuração de aspectos relativos à recepção da imagem, como luminosidade e qualidade, permitindo assim uma melhor interação usuário-ambiente remoto.

**Figure:** (a) Página HTML do sistema de teleoperação; (b) Applet Java desenvolvido para a teleoperação.
$\resizebox*{16cm}{10cm}{\includegraphics{fig/fig4_20.eps}}$

4.6.3 Análise do Resultados

A aplicação de sistemas robóticos de teleoperação implica a utilização de um sistema em tempo real. Entretanto, o ambiente WWW e o protocolo TCP/IP não são adequados para aplicações em tempo real, devido à sua limitação de largura de banda (para transmissão de vídeo) e o delay (atraso) do envio dos pacotes TCP/IP entre servidor e cliente. Parte desses problemas podem ser reduzidos através do uso de imagens JPG (compactadas) e a implementação de um certo grau de autonomia no robô (sensoriamento e navegação autônoma), inseridos no sistema desenvolvido.

A utilização do Linux como sistema operacional foi guiada pela capacidade deste de prover serviços gerais (como conexão Internet, HTTP) assim como permitir, através da linguagem C, controle sobre dispositivos como sensores e motores. A sua robustez e confiabilidade, quando comparados a outros sistemas operacionais, tornam-no adequado à aplicações em robótica.

A necessidade de aplicação em tempo real, internamente ao robô, para gerenciar simultaneamente captura de vídeo e navegação, foi implementada através da definição de prioridades para os processos: assim, o processo responsável pela navegação é disparado com maior prioridade que os demais processos, garantindo a segurança do sistema, embora reduzindo a transmissão das imagens capturadas. Uma outra abordagem possível para o problema seria a utilização da extensão de tempo real para o Linux (RTLINUX, 1999), o que permitiria uma melhor aplicação do sistema ao controle do robô.

O algoritmo de navegação implementado foi simulado através do software MatLab, sendo realizados testes em diversas configurações de obstáculos, com a simulação de um sistema de sensores de toque. Verificou-se uma boa estabilidade do método, embora em alguns casos o sistema demore a convergir. A futura substituição dos sensores de toque para sensores do tipo sonar no robô é compatível com o algoritmo implementado, já tendo sido inclusive realizados testes do mesmo nessa nova configuração.

4.7 Telerobótica: Teleoperação do Robô Nomad XR4000

A arquitetura do sistema baseia-se no modelo cliente-servidor, que divide as atribuições do sistema em um servidor, representado pela página HTML (Hiper Text Markup Language) e programas em linguagem C localizados no robô móvel XR4000 (figura 4.21); e o cliente, representado por applets Java, funcionando no browser do usuário. Como pode ser observado na figura 4.22, o robô XR4000 possui dois computadores embarcados, um responsável pelo controle de movimentos do sistema (servidor de controle) e um responsável pela captura e processamento das imagens de uma câmera CCD (servidor de vídeo).

**Figure:** Robô Nomad XR4000.
$\resizebox*{4cm}{6cm}{\includegraphics{fig/fig4_21.ps}}$

O robô móvel XR4000, produzido pela Nomadic Technologies, é um sistema avançado de robótica móvel, compreendendo sistemas de controle, sensores, comunicação e programação necessários para pesquisa e desenvolvimento na área de manipulação robótica, visão computacional, navegação por sensores e aprendizado.

**Figure:** Arquitetura de teleoperação do sistema.
$\resizebox*{12cm}{6cm}{\includegraphics{fig/fig4_22.ps}}$

4.7.1 Servidores desenvolvidos

Os servidores desenvolvidos no sistema de teleoperação do robô utilizam o servidor ``inetd'' como gerenciador das conexões Internet, diferentemente dos servidores CGI utilizados nos projetos de teleoperação do laboratório do Graco descritos nas seções anteriores. O servidor de controle é composto por três serviços em linguagem C, localizados na máquina ``lower'' (http://lower.graco.unb.br):

robserver, responsável pelo controle de movimentos do robô, contendo um sistema de controle fuzzy de velocidade;
stopserver, responsável pela segurança através de uma parada de emergência;
e senserver, que realiza a captura de dados sensoriais do robô e o envia para o applet Java.

O servidor de imagens é composto por três serviços localizados na máquina ``upper'' (http://upper.graco.unb.br) e programados em linguagem C:

camserver, responsável pelo controle de orientação do pan-tilt da câmera;
JPGStd, que realiza a captura de uma imagem de alta qualidade no formato JPEG;
e JPGPush, que realiza a captura e animação de imagens JPEG de baixa qualidade através do mecanismo de animação push-server do browser Netscape.

4.7.2 Sistema de controle de velocidade baseado em Lógica Fuzzy

Aplicações de teleoperação necessitam de uma certa autonomia para se garantir a segurança do sistema, visto que o tempo entre o envio de um comando e o recebimento das imagens ou dados sensoriais pode ser da ordem de segundos. Este sistema utiliza-se da lógica fuzzy como forma de controle de velocidade do robô móvel, baseando a velocidade de saída na distância a ser percorrida (definida pelo usuário) e na distância dos obstáculos presentes no ambiente (aleatórios e transientes). Foram utilizados duas variáveis de entrada: distância a ser percorrida, definida em 5 conjuntos fuzzy; e a distância dos obstáculos (obtida através de sensores ultrasônicos), definida em 5 conjuntos fuzzy. Utilizando-se o método de desfuzzyficação do centróide e de regras do tipo "se a distância é longe e o obstáculo é médio então a velocidade é média", obteve-se a superfície de resposta do controlador mostrada na figura 4.23.

**Figure:** Superfície de resposta do controlador fuzzy.
$\resizebox*{9cm}{5cm}{\includegraphics{fig/fig4_23.ps}}$

4.7.3 GUI de Teleoperação do sistema baseado em Applets Java

A interface de controle do sistema é baseada na linguagem de programação Java, atualmente a plataforma de desenvolvimento de software mais adequada para aplicações na Internet. O sistema desenvolvido consiste em dois applets, ou seja, programas carregados pelo browser que funcionam na máquina remota do cliente. Esses applets conectam-se com os servidores localizados no robô móvel, permitindo assim o envio e recebimento de dados entre o usuário e o robô.

O applet de controle do pan-tilt é responsável pelo posicionamento da câmera de vídeo do robô, possibilitando uma visualização do ambiente no qual o robô se encontra, seja na direção de seu movimento como em outras direções. O applet de controle de movimentos é responsável pela interface entre o usuário e os servidores robserver, sensenver e stopserver localizados no robô. Com base nesta interface, o cliente é capaz de posicionar o robô no plano, realizar ajustes de deslocamento linear e angular assim como receber dados sensoriais e o estado geral das baterias do robô. A recepção das imagens animadas pelo servidor é responsabilidade do navegador Netscape. Durante o funcionamento do sistema o usuário inicialmente visualiza a animação gerada pelo sistema, sendo capaz de movimentar e explorar o ambiente remoto através dessas imagens.

Caso seja necessário, o usuário pode realizar um ``zoom'' da imagem pressionando o mouse sobre a animação, sendo então mostrada uma imagem estática ampliada do servidor de imagens do robô (servidor JPGStd). A figura 4.24 apresenta a página Web de teleoperação do sistema. Na parte superior direita encontra-se o applet de controle do pan-tilt. Na parte inferior direita encontra-se o applet de controle de movimentos. Na parte superior esquerda apresenta-se as imagens capturadas pelo robô (animação JPEG) e na inferior esquerda apresenta-se imagens do laboratório através de uma câmera externa ao robô.

**Figure:** GUI de teleoperação do sistema.
$\resizebox*{14cm}{16cm}{\includegraphics{fig/fig4_24.ps}}$

4.7.4 Análise dos Resultados

A tecnologia de teleoperação via Internet encontra-se em seu estágio inicial de desenvolvimento, tendo sua aplicabilidade ainda reduzida devido à baixa velocidade de transmissão de dados da atualidade. Este sistema de teleoperação utiliza como ferramenta de comunicação de dados a linguagem de programação Java, atualmente a plataforma mais adequada ao desenvolvimento de aplicações na Internet. O sistema apresenta ao usuário imagens obtidas do ambiente remoto assim como dados sensoriais do robô, e permite ao mesmo o controle de movimentos do robô e da câmera embarcada no sistema. Devido às restrições de velocidade de comunicação as imagens capturadas são comprimidas no formato JPEG, permitindo assim um menor consumo de banda de comunicação e melhorando a apresentação das imagens ao usuário. A necessidade de um sistema seguro de controle do robô e devido aos atrasos inerentes à comunicação via Internet levaram à utilização de um sistema de controle de velocidade do robô baseado na lógica fuzzy. Este controlador é responsável pela segurança do sistema, através do monitoramento dos dados sensoriais do ambiente e do controle da velocidade do robô. Foi verificado, através de experimentos, que o controlador fuzzy é sensível aos dados obtidos através dos sensores ultrasônicos do robô, o que leva à necessidade de se desenvolver uma espécie de filtro de dados sensoriais para obter uma maior estabilidade e confiabilidade no sistema de controle de velocidade. A utilização do sistema teleoperado em ambientes conhecidos também requer o posterior desenvolvimento de um sistema autônomo de navegação, o que simplificaria a teleoperação do robô móvel XR4000 em ambientes estruturados.

4.8 Teleoperação e o CAM

Manufatura Auxiliada por Computador é o estágio final do auxílio do computador na produção de peças mecânicas. Dessa forma, em referências mais antigas (pré-década de 90), CAM se encontra definido como o uso de sistemas de computação para planejar, gerenciar e controlar as operações de uma planta, através de interface computadorizada direta ou indireta com a produção (GROOVER, 1985). Dentro dessa definição, Groover dividiu o CAM em duas grandes categorias:

Execução (monitoramento e controle por computador): Estas são as aplicações diretas nas quais o computador se conecta diretamente com o processo de manufatura com o propósito de monitorar ou controlar o processo. A teleoperação está intimamente ligada a esta etapa do CAM.
Planejamento (aplicações de suporte à manufatura): Estas são as aplicações indiretas nas quais o computador é usado como suporte das operações de produção na planta, mas não há interface direta entre o computador e o processo de manufatura. O ambiente integrado CAD/CAPP/CAM se insere nesta categoria.

O monitoramento de processo envolve uma interface direta com o processo de manufatura com o propósito de observar o processo e o equipamento associado e coletar dados do processo. O computador não é usado para controlar a operação diretamente. O controle continua nas mãos de ope-radores humanos, que podem ser guiados pelas informações compiladas pelo computador. O con-trole do processo por computador vai um passo além de apenas observar o processo, controlando-o a partir das observações. Novamente atividades associadas a teleoperação da máquina-ferramenta CNC, Robô Industrial, entre outros estão presentes no CAM. Ou seja, as atividades de chão-de-fábrica que são executadas pelo CAM, são agora atribuições do sistema de teleoperação como: Download e Upload de programas, inicialização da máquina, status da máquina, e outras funções associadas ao DNC (Comando Numérico Distribuído).

Além das aplicações envolvendo uma interface direta computador-processo com o propósito de controle ou monitoramento do processo, a Manufatura Auxiliada por Computador também inclui aplicações indiretas nas quais o computador faz um papel de ajudante nas operações de manufatura da planta. Nessas aplicações o computador é usado fora da linha para prover planos, cronogramas, previsões, instruções e informações através das quais os recursos produtivos da empresa podem ser gerenciados mais efetivamente. Alguns exemplos de CAM para suporte à manufatura são:

Programação de máquinas de controle numérico por computadores: Programas de controle são preparados para máquinas-ferramenta automáticas.
Planejamento de processos automatizado por computador: O computador prepara uma lista de seqüências de operações necessárias para processar um particular produto ou componente.
Padrões de trabalho gerados por computador: O computador determina o padrão de tempo para uma operação particular.
Programação de produção: O computador determina o programa adequado para atender às necessidades da produção.
Planejamento das necessidades de materiais: o computador é usado para determinar quando pedir matérias-primas, componentes e quantos devem ser pedidos para atender à programação de produção.
Controle de chão-de-fábrica: Nesta aplicação, dados são coletados da fábrica para determinar o progresso das várias ordens de produção.

Segundo TEICHOLZ (1985) CAM está associado apenas com a geração de programas NC auxiliada por computador. ZEID (1991), propoem um gráfico onde se inclui, dentro do que ele chama de o processo CAM, desde o planejamento do processo, passando pelo planejamento da produção, o projeto e obtenção de novas ferramentas, o controle de pedidos, a programação NC, DNC (Comando Numérico Distribuído), a produção, o controle de qualidade e até a embalagem. Nesta abordagem CAM é visto como sendo a soma de ferramentas computacionais de manufatura sendo dividida em três tipos:

Hardware: unidade central, terminais, unidades de entrada e saída.
Software: bases de dados, CAD, NC, MRP, etc.
Redes: de robôs, de células de manufatura, de sistemas de manipulação de materiais, etc.

É interessante notar que em todas as referências a CAM é sempre muito relacionada ao CAD, pois o objetivo sempre é passar do projeto à manufatura da maneira mais rápida e fácil possível. Desse modo, muitas vezes eles são citados de forma conjunta (sistemas CAD/CAM). A relação também é obvia uma vez que as atividades CAM quase sempre necessitam de alguma informação CAD como entrada.

CAM sempre foi relacionado ao controle da manufatura como um todo. No entanto, atualmente, as ferramentas de software consideradas para CAM são aquelas ligadas unicamente à geração de programas para máquinas CN. Aparentemente, o nome CAM ficou associado a esse tipo de aplicação, já que esta, dentre as aplicações que se incluem sob o nome de CAM, foi a que se desenvolveu primeiro. As outras aplicações, ao se desenvolverem posteriormente, com o aumento generalizado do uso de computadores, ganharam depois nomes próprios, como CAPP (Planejamento do Processos Auxiliado por Computador) e CAPPC ou CAP (Planejamento e Controle da Produção Auxiliado por Computador, que inclui MRP, controle de chão-de-fábrica, etc).

4.8.1 Integração ao ambiente

O software de CAM tem uma íntima relação com o CAD e na maioria das vezes importando modelos de produto a partir deste. Além disso, o software deve transmitir seus dados corretamente para a máquina-ferramenta, para que a usinagem seja realizada a contento. Assim a integração do CAM ao ambiente se dá nessas duas frentes: a comunicação CAD-CAM e a comunicação CAM-máquina-ferramenta.

Comunicação CAD-CAM: O programa de CAM em geral recebe como entrada um desenho (ou desenhos) do CAD, e a partir dele é feita a geração de caminhos de ferramenta, etc. O padrão de comunicação mais importante, sendo inclusive um padrão ANSI, é o IGES (Initial Graphics Exchange Specification). Ele foi aprovado em setembro de 1981 como Padrão ANSI Y14.26M. Ele permite a troca de dados entre sistemas CAD/CAD. IGES funciona no nível de base de dados de objetos ou estrutura de dados de aplicações. Basicamente todos os pacotes comerciais de CAM lêem arquivos padrão IGES. Além do padrão IGES, existem outros tipos de arquivo que, por serem de larga utilização, também são suportados por grande parte dos pacotes. Alguns exemplos são o padrão DXF®, do AutoCAD®, o padrão VDA, o padrão CATIA®, etc.
Comunicação CAM-Máquinas-ferramenta: Como já foi dito anteriormente, o controlador das máquinas-ferramenta somente tem condições de ler arquivos em linguagem G e semelhantes, que são a linguagem de mais baixo nível para esse tipo de aplicação. Assim, o sistema CAM deve gerar esse tipo de código para que ele seja carregado na máquina. Para isso existem os pós-processadores: gerar o código G a partir do formato de alto nível usado no pacote. No entanto, para cada combinação de controlador-máquina, é necessário um código diferente. Assim existem inúmeros pós-processadores diferentes. Os mais comuns costumam ser fornecidos junto com os sistemas CAM, porém em alguns casos pode ser necessário gerar um novo pós-processador.

4.9 Conclusão

O capítulo situa-se na área de teleoperação apresentando uma metodologia para o desenvolvimento de sistemas Robóticos teleoperados via Internet e situando a teleoperação na fase de execução do CAM. A metodologia foi testada através do desenvolvimento de cinco sistemas que estão disponíveis em http://www.graco.unb.br.

O sistema RobWebCam foi validado comprovando a sua funcionalidade estando em operação desde setembro de 1997. Foram observadas algumas possibilidades de otimizações, decorrentes das análises feitas, para evolução do sistema (ÁLVARES & ROMARIZ, 1998). O manipulador cons-truído apresenta baixo ruído nos deslocamentos realizados e possui dimensões reduzidas quando comparado a outros sistemas de posicionamento de câmera existentes no mercado. Além disso, os custos foram bastante reduzidos. Como áreas de aplicação características do sistema têm-se: vigilância de estabelecimentos, visualização de ambientes de trabalho, visualização de ambientes comerciais para propaganda, visualização de ruas ou pontos turísticos, entre outras.

Um dos grandes empecilhos à tecnologia de teleoperação via Internet, atualmente, é o tempo de espera elevado em função da largura de banda existente na rede, ou seja, ainda é considerável o intervalo de tempo entre o envio do comando, a efetivação do posicionamento e a visualização da nova situação monitorada, o que compromete aplicações em tempo real que requerem maior confiabilidade e segurança, como no caso do sistema RobWebLink.

O sistema RobWeblink apresentou bons resultados no que concerne as funções diretamente relacionadas ao controle do Robô através do seu protocolo de comunicação, por requerer arquivos de 1 a 2 Kbytes de tamanho para implementar estas funções. Entretanto, a realimentação através de vídeo exige maior largura de banda para aplicações em tempo real. Uma opção seria a utilização de Realidade Virtual ao invés de se utilizar sinal de vídeo, através de VRML (OTSUKA, 1996).

O robô móvel desenvolvido mostrou-se adequado para a proposta de desenvolvimento de um sistema simples e barato de robótica móvel voltado para aplicações didáticas e de pesquisa. A sua tecnologia pode ser aplicada para utilizações diversas, como inspeção de sistemas industriais, ou mesmo aplicações em televigilância.

A utilização da Internet como meio de transmissão de dados para o robô (Nomad XR4000) mostra-se adequada, e permite que o sistema seja amplamente disponível para usuários, sem limitações geográficas. A tecnologia de TeleRobótica via Internet é ainda incipiente e está tendo um grande desenvolvimento em virtude dos grandes avanços obtidos na tecnologia de compressão de dados e no grande impulso que está se dando a tecnologia de WebTV e Vídeo Conferência e outras aplicações que dependem de uma maior largura de banda.

Certamente, estas tecnologias associadas a maior largura de banda da Internet irá viabilizar aplicações em tempo real no futuro, como menos restrições que se tem atualmente. Empresas como a National Instruments, fabricante do LabView (http://www.ni.com), desenvolvem sistemas de teleoperação e instrumentação remota via Internet para aplicação em Automação Industrial e certamente outras empresas seguirão este caminho. Segundo STEINEL (2001) empresas como a Volkswagem desenvolvem laboratórios remotos para testes de motores visando a diminuição de custos e compartilhamento de sua estrutura laboratorial entre a matriz na Alemanha e sua filial no México.

5. Metodologias e Sistemas CAD/CAPP/CAM Baseados na Web

A integração entre as etapas do ciclo produtivo é um dos caminhos que devem ser explorados na busca pela redução de custos e tempos de produção. De acordo com SJAJ e MÄNTYLA (1995) a modelagem do produto é o ponto central para a promoção de tal integração. A abordagem baseada em features é um importante elemento no projeto e na manufatura auxiliada por computador. As features podem ser consideradas como um elemento de integração potencial entre o projeto e a manufatura.

Num sistema de produção integrado, o modelo do produto, definido no módulo de CAD, deve estar disponível para outros módulos (CAE, CAPP, CAM, CAQ, etc) para que estes possam realizar suas funções, assim como estes módulos devem ser capazes de enviar informações de volta para o módulo de CAD a fim de que alterações que sejam necessárias na peça possam ser efetuadas ainda na etapa de projeto (por problemas detectados na fabricação, por exemplo). A utilização de features como base de informação para a modelagem do produto é o caminho para se atingir esta integração (TÖNSHOFF et al, 1994). De acordo com SALOMONS et al. (1993) a tecnologia de features é o caminho mais adequado para se promover a integração entre as atividades de projeto, planejamento do processos, fabricação, inspeção, etc.

Neste capítulo é apresentada uma revisão bibliográfica sobre arquiteturas e sistemas CAD/CAPP/CAM cooperativos e correlatos, centrados em rede e distribuídos. Duas arquiteturas que se destacam são o Cybercut e o WebSpiff, ambas baseadas na tecnologia de features.

5.1 Introdução

A Tecnologia da Informação, em especial, a tecnologia de redes de comunicação e Internet, está abrindo um novo domínio para construção dos futuros ambiente CAD/CAPP/CAM (LEE et al, 2001). Este é um novo paradigma para estes sistemas computacionais baseados em ambiente globa-lizados, centrados em rede e espacialmente distribuídos. Isto permitirá que os desenvolvedores de produtos, projetistas, tenham maior facilidade de comunicação possibilitando o compartilhamento e o projeto cooperativo durante o desenvolvimento do produto, bem como, a teleoperação e moni-toração dos dispositivos de manufatura. Com o crescimento da popularidade dos navegadores baseados no WWW está ficando mais evidente que o ambiente de projeto e manufatura orientado a rede se tornará um novo paradigma para o desenvolvimento de produto.

No chão-de-fábrica vários exemplos de arquiteturas para protocolos de camada de aplicação do Modelo ISO/OSI, Manufacturing Message Specifications (MMS), estão sendo desenvolvidos. Estas arquiteturas utilizam-se do protocolo TCP/IP, por apresentar menores custos de implementação e devido ao fato da maioria dos dispositivos de manufatura (CNC, PLC, Robôs, entre outros) não suportarem o MMS. Segundo CHEAH, LEE e LIM (1997) o TCP/IP é uma ótima alternativa para suportar o protocolo MMS como um padrão de fato em redes de computadores. Assim o CAM em sua fase de execução, também pode usufruir dos benefícios do TCP/IP.

5.1.0.1 CAD/CAM COOPERATIVO

A filosofia de aplicações CAD/CAM tradicionais é baseada no ambiente computacional desenvolvido na década de 70 e restrito à aplicações tipo "single-location" (KAO e LIN, 1996). A Tecnologia CAD/CAM foi concebida como uma aplicação "single-user" e um usuário CAD/CAM pode apenas se comunicar com a unidade de processamento central (CPU) do seu computador. Em sistemas CAD/CAM comerciais os usuários não podem se comunicar entre eles, mesmo que a CPU seja um sistema de tempo compartilhado como uma estação de trabalho Unix ou um mainframe. Com a popularização das Redes de Comunicação Local (LAN) sistemas CAD/CAM foram implementados em servidores de redes, permitindo que os usuários acessem de qualquer computador conectado a LAN o servidor. Contudo, a interação entre os usuários CAD/CAM ainda ocorre da mesma forma que antes, apesar da utilização dos modernos serviços de comunicação disponíveis como E-mail, fax, ftp, http, entre outras, que diminui o tempo gasto para comunicações.

Passadas mais de três décadas a tecnologia CAD/CAM tem tido um grande sucesso em aplicações industriais tendo como resultado um significativo aumento na produtividade e competitividade. A Engenharia Simultânea (CE) tem sido reconhecida como uma filosofia de manufatura capaz de possibilitar a concretização da Manufatura Integrada por Computador (CIM) que não pode alcançar todo seu potencial sem CAD/CAM. Já é uma realidade a Manufatura Global que aumenta de forma acentuada a implementação de empreendimentos multinacionais e multiregionais. Assim, é necessário a utilização de tecnologias CAD/CAM para facilitar a Engenharia Simultânea (CE) nas Empresas Integradas por Computador (CIE) em operações multiregionais ou multinacionais.

Histórias de sucesso sobre CE usualmente enfatizam a ligação entre muitas divisões na empresa para compartilhamento e troca de idéias e experiências. Este estilo de trabalho emprega uma equipe multifuncional, equipe virtual ou uma força tarefa multidisciplinar. Para que isto ocorra os engenheiros deverão trabalhar efetivamente como time/equipe, sendo este um fator crítico para o sucesso do desenvolvimento de produto de forma Simultânea (HARTLEY, 1992). O engenheiro de projeto define toda a geometria CAD, passando-a para a divisão de engenharia no estilo tradicional de trabalho over-the-fece ou over-the-wall. Por outro lado, com a equipe de projeto organizada como uma força tarefa (CE), o engenheiro de projeto e o desenhista podem sentar-se lado a lado e trabalhar juntos, se eles estiverem lotados no mesmo departamento. Isto resulta em um processo de desenvolvimento contínuo, melhor que um modelo seqüencial onde os projetos são passados de um lado para o outro. Portanto, em empresas que mantêm operações multiregionais ou multinacionais, uma necessidade por sistemas computacionais CAD/CAM cooperativos têm surgido, para facilitar o trabalho em equipe de forma fechada entre engenheiros localizados em diferentes regiões geográficas.

Um sistema CAD/CAM cooperativo deve prover aos projetistas, em duas ou mais localizações remotas, capacidade de trabalhar juntos sobre atividades de projeto comuns, o que significa que um novo ambiente de projeto terá de ser criado para se ter um uso total de todos os conhecimentos relevantes, tecnologias e recursos do mercado mundial. Para atingir esta tarefa desafiadora, tecnologias de rede e computadores devem ser usadas para acentuar a comunicação entre os projetistas. Por exemplo, multimídia, sistemas whiteboard 2D e 3D, browsers, www, ferramentas de aplicação compartilhada, etc, têm demonstrado serem de grande utilidade para acentuar as liga-ções entre projetistas geograficamente separados, mas ainda não são suficientes para o trabalho cooperativo.

5.1.0.2 CAD COOPERATIVOS

Na prática de projeto de engenharia, cada vez mais as atividades associadas aos vários aspectos de manufatura estão sendo considerados durante a fase de projeto. Modelagem baseada em Featurestypeset@protect @@footnote SF@gobble@opt Tecnologia de Features já foi analisada na primeira disciplina de estudo dirigido cursada no terceiro período de 2001. Maiores informações podem ser consultadas através da URL ftp://omega.enm.unb.br/pub/doutorado/estudo_dirigido. tem sido considerado como um novo paradigma para integração das atividades de engenharia, desde o projeto até a manufatura. Assim o conceito de features tem sido usado em uma ampla gama de aplicações como projeto de peças e montagem, projeto para manufatura, planejamento de processo e inúmeras outras aplicações. Estas aplicações estão migrando para ambientes computacionais heterôgeneos e distribuídos para suportar o processo de projeto e manufatura que serão distribuídos tanto na dimensão espacial quanto temporal.

Nota-se que é indesejável e freqüentemente improvável requerer que todos os participantes nas atividades de projeto e manufatura de um produto usem o mesmo sistema de hardware e software. Então os componentes devem ser modular, e comunicar-se com os demais através de uma rede de comunicação para efetiva colaboração.

Muitos esforços de pesquisa têm sido empregado no desenvolvimento de ambientes de projeto orientados à redes de computadores, normalmente, denominados de centrados em rede. SHAH et al. (1997) desenvolveram uma arquitetura para padronização da comunicação entre o núcleo de um sistema de modelagem geométrica e as aplicações. HAN e REQUICHA (1998) propõem uma abordagem similar que possibilita o acesso transparente para diversos modeladores sólidos. WANG e WRIGHT (1998) descrevem um serviço de manufatura distribuído denominado de Cybercut (http://cybercut.berkeley.edu). Eles enfatizam como ferramentas de CAD são desenvolvidas para facilitar o projeto distribuído e o processo de fabricação.

HARDWICK et al. (1996) propõem uma infra-estrutura que permite a colaboração entre compa-nhias no projeto e manufatura de novos produtos. Esta arquitetura integra o WWW para compartilhamento de informações na Internet utilizando o padrão STEP para modelagem de produto. MARTINO et al. (1998) propõem uma abordagem para integrar as atividades de projetos com as demais atividades de manufatura e produção baseado na abordagem de modelagem baseada em feature integrada, que suporta Projeto por Features e Reconhecimento de Features. Entretanto estes trabalhos são conceituais em sua essência e não apresentam uma representação bem estruturada e nem algoritmos detalhados. Por exemplo, estes trabalhos não definem como distribuir o processamento computacional necessário entre os componentes distribuídos, e como modular a comunicação entre os componentes para minimizar o delay da rede. Se as ações de troca de dados entre as aplicações não puderem ser disparadas apropriadamente, isto acarretará em um problema crítico para a computação distribuída. Logo, é crucial o desenvolvimento de um sistema bem integrado, centrado em rede e com arquitetura baseado em agentes para projeto e manufatura distribuída e cooperativa.

LEE et al. (1999) apresentam a arquitetura de um sistema de modelagem baseada em features centrado em rede, em um ambiente de projeto distribuído, denominado de NetFeature System. Esta abordagem combina técnicas de modelagem baseada em features com tecnologia de comunicação e de computação distribuída para suportar atividades de modelagem de produto e projeto cooperativo em uma rede de computadores. A abordagem é implementada em uma arquitetura cliente/servidor, na qual os clientes realizam a modelagem baseada em features através da Web, o servidor cria o modelo de features neutras e outras aplicações se comunicação umas com as outras usando um protocolo de comunicação padrão para acessar os objetos remotos. O sistema foi concebido a fim de ter um bom balanceamento entre as funcionalidades disponíveis no lado do cliente e largura de banda disponível na Internet.

O processamento no lado do cliente é importante quando a aplicação é baseada na Web. Isto significa que o servidor dá ao cliente alguma responsabilidade pelo processamento dos dados, ou seja, o cliente deve ter mais funcionalidades do que simplesmente um Front-End desprovido de processamento local denominado como um de thin clients. Foi utilizado um protocolo de comunicação padronizado baseado em CORBA (Commom Object Request Broker Architecture).

De forma semelhante às atividade de modelagem de produto (CAD by features), planejamento de processo (CAPP) e a manufatura assistida por computador na fase de planejamento (CAM Planejamento) e na teleoperação (CAM Execução) necessita-se de um bom balanceamento entre largura de banda e funcionalidades do cliente, implementada na GUI.

5.2 Ferramentas CAD com Área de Trabalho Compartilhada

Segundo BERG (1999 e 2000) ferramentas CAD com área de trabalho compartilhada (workspace-sharing tools) são aplicações que podem ser usadas como um programa stand-alone, mas que possuem facilidades para conectar-se com outras aplicações de modelagem, de maneira a estabelecer um ambiente de trabalho cooperativo. Podem também ser adicionados à aplicações existentes, para prover a funcionalidade necessária para um ambiente cooperativo. Algumas destas aplicações utilizam base de dados compartilhadas ou gerenciadores de sessões.

Sistemas cooperativos podem ser definidos como sistemas multi-usuários distribuídos sendo ao mesmo tempo concorrente e sincronizado (BIDARRA et al. , 2000). Concorrência envolve gerenciamento de diferentes processos que tentam simultaneamente acessar e manipular o mesmo dado. Sincronização envolve propagação, envolvendo dados entre usuários de uma aplicação distribuída, de forma a deixar seus dados consistentes.

Sistemas de modelagem cooperativa tipicamente tem uma arquitetura cliente/servidor, diferindo na distribuição de funcionalidade e de dados entre clientes e servidores. Um problema recorrente nos sistemas cliente/servidor está associado ao conflito entre a limitação da complexidade da aplicação cliente e a minimização do carregamento da rede. Em um contexto de modelagem coo-perativa, a complexidade do cliente é principalmente determinada pelas facilidades de modelagem e interatividade implementadas no cliente, enquanto que o carregamento da rede é determinado principalmente pelo tipo e tamanho do modelo de dados sendo transferido de/para os clientes.

Uma solução de compromisso pode ser concebida entre os dois extremos, os chamados thin clients e fat clients. Uma arquitetura pura thin client tipicamente coloca toda a funcionalidade no servidor, o qual envia uma imagem de sua interface de usuário para ser mostrada no cliente. Clicando na imagem é gerado um evento, contendo as coordenadas da tela de localização que o usuário clicou. Os eventos são enviados para o servidor, o qual associa com uma ação sobre um particular widgate. A seguir esta ação é processada e a imagem atualizada do resultado da ação do usuário é enviada de volta para o cliente onde é mostrada. Esta abordagem requer um fluxo de informação contínua entre o servidor e os clientes, sendo muito pesada em termos de tráfego de rede. Sistemas de gerenciamento de Terminal Remoto para conectividade entre sistemas Windows e/ou Unix utilizam esta abordagem, como Citrix (http://www.citrix.com) e XFree/XDM (http://www.X11.org)

O outro extremo, um puro fat client oferece total facilidade de interação e modelagem local, mantendo seu próprio modelo local. Comunicações com o servidor é então requerida quando houver necessidade de sincronizar as modificações de dados do modelo local com os outros clientes. Em ambiente cooperativo onde clientes podem concorrentemente modificar o modelo de dados local, a prevenção da inconsistências de dados entre diferentes clientes torna-se um problema crucial. Um exemplo prático desta arquitetura é o sistema de declaração de imposto de renda via Internet adotado no Brasil, onde toda a funcionalidade é colocada no cliente e quando a declaração está concluída é enviada para o servidor, estando disponível na base de dados da Receita Federal. A seguir são apresentadas algumas arquiteturas levantadas na revisão bibliográfica.

5.2.1 CSCW-FeatureM

Feature M (STORK, 1998) é um sistema CAD 3D que suporta modelagem sólida baseada em features utilizando o ACIS-kernel e uma linguagem interpretada denominada de MCL+, que permite ao usuário a adição de funcionalidade. MCL+ também é utilizado para comunicação interna entre os módulos em FeatureM. O sistema usa a abordagem replicada, onde cada aplicação cliente tem um modelo local que é atualizado localmente e incrementado. Isto implica em clientes mais complexos e menos tráfego na rede.

Dois sistemas executando o sistema CAD FeatureM são conectados um com o outro pela rede, como mostra a figura 5.1.

**Figure 5.1:** Arquitetura do CSCW-FeatureM.
$\resizebox*{14cm}{6cm}{\includegraphics{fig/fig5_1.ps}}$

5.2.2 CollIDE

O sistema Collaborative Industrial Design Environment (CollIDE) desenvolvido por NAM (1998a e 1998b) oferece uma área de trabalho 3D compartilhada para muitos usuários de uma aplicação stand-alone CAD. É concebido como um plug-in para um sistema Alias CAD 3D e disponibiliza áreas de trabalho para os usuários, chamado de estágios. Estágios são áreas de uma aplicação onde a modelagem real tem lugar. A arquitetura do CollIDE é apresentada na figura 5.2.

**Figure 5.2:** Arquitetura CollIDE.
$\resizebox*{14cm}{9cm}{\includegraphics{fig/fig5_2.ps}}$

5.2.3 TOBACO

Tool Based Co-operation (TOBACO) foi desenvolvida por DIETRICH (1997). Fornece um componente integrado no topo de programas de projeto existentes para habilitá-los a participar na modelagem cooperativa. Isto possibilita a redução do tempo de desenvolvimento e melhora a quali-dade do projeto. TOBACO usa o padrão CORBA com IDL (Interface Definition Language), que define uma descrição formal dos serviços. TOBACO trabalho como um programa adicional para o programa de projeto que é familiar ao usuário. A GUI é definida usando wxWindows (SMART, 1999), uma ferramenta que possibilita código GUI independente de plataforma. A figura 5.3 mostra a estrutura de TOBACO.

**Figure:** Estrutura de TOBACO com troca de dados no nível de modelo.
$\resizebox*{12cm}{10cm}{\includegraphics{fig/fig5_3.ps}}$

5.2.4 ARCADE

O objetivo dos desenvolvedores (STORK, 1997) do ARCADE (Advanced Realism CAD Environment) foi criar um método de discussão aprimorado para ser usado sobre a Internet. O método permite que muitos usuários trabalhem juntos sobre uma projeto, interagindo um com o outro em tempo real. A figura 5.4 apresenta a arquitetura do sistema.

**Figure 5.4:** Arquitetura do sistema ARCADE.
$\resizebox*{10cm}{6cm}{\includegraphics{fig/fig5_4.ps}}$

5.2.5 Problemas

Em ambiente cooperativo todos os clientes devem ter o mesmo modelo geométrico. Quando um usuário altera o modelo, todos os clientes devem ser atualizados. Para que o processo tenha consistência as mensagens de atualização devem ser entregues na mesma ordem para todos os clientes. Este problema é caracterizado como uma questão de sincronização e consistência do modelo geométrico.

Um segundo problema está associado à concorrência e diversas soluções são adotadas nos sistemas descritos (BERG, 1999). O carregamento da rede, associado a largura de banda, ambiente computacional heterogêneo e problemas específicos de aplicações são também relacionados na análise feita por BERG (1999).

Sem dúvida a redução do carregamento da rede de comunicação é uma das principais metas para os desenvolvedores de sistema de modelagem distribuída e interativa, seguido da consistência e sincronização do modelo geométrico.

5.3 Sistemas CAD Baseados na Web

5.3.1 WebSpiff (http://www.webspiff.org)

WebSpiff (BIDARRA et al. , 2000) é baseado em uma arquitetura cliente/servidor consistindo de muitos componentes (figura 5.5). No lado do servidor tem-se dois componentes principais:

Sistema de Modelagem SPIFF: fornece toda a funcionalidade para modelagem baseada em feature, utilizando o kernel de modelagem ACIS.
Gerenciador de Sessão: fornece funcionalidade para iniciar, associar-se, sair e fechar uma sessão de modelagem, bem como, gerência todas as comunicações entre o sistema SPIFF e os clientes.

Os componentes do portal WebSpiff fornecem o acesso inicial a uma sessão WebSpiff para um novo cliente, que inclui um servidor web onde os dados do modelo é disponibilizado para download pelos clientes. Os clientes executam operações localmente, associado com a visualização, interação com o modelo em features, mensagens semânticas de alto nível, especificação de operações de modelagem, bem como, atualização de dados do clientes são enviados via rede.

O servidor coordena a sessão de colaboração, mantem um modelo de produto centralizado e provê todas as funcionalidades que não podem, ou não devem, ser implementados no cliente. Uma importante vantagem desta arquitetura é que existe apenas um modelo de produto centralizado, então envita-se inconsistências entre múltiplas versões do mesmo modelo.

**Figure 5.5:** Arquitetura do Sistema WebSpiff.
$\resizebox*{14cm}{6cm}{\includegraphics{fig/fig5_5.ps}}$

A atual versão do sistema WebSpiff (servidor) oferece múltiplas visões sobre o modelo do produto. Cada visão consiste de um modelo de feature com features específicas para a aplicação correspondente à visão. São duas visões disponíveis: uma de projeto e uma outra para planejamento do processo, manufatura, de peças. Na visão de projeto, o modelo de features consiste de features aditivas (protusions) e features subtrativas (slots e furos). Na visão de planejamento de manufatura, o modelo de features consiste apenas de features subtrativas. Também, estão disponíveis funcionali-dades associadas a validação e manutenção de features. Finalmente são oferecidas sofisticadas técnicas de visualização de features.

Os clientes do WebSpiff usam web browser mais plug-ins para Java e Java 3D, a fim de ter capacidade de conectar-se ao portal WebSpiff, fazendo o carregamento de um Java applet, que implementa a GUI, fazendo a conexão com o Gerenciador de Sessão, disparando-o no lado do servidor. O usuário pode agora conectar-se a uma sessão cooperativa em andamento ou iniciar uma nova sessão.

Muitas das funcionalidades do sistema de modelagem SPIFF, baseado no kernel ACIS e na linguagem TCL/TK (JOHNSON, 1997), foram portados para o cliente. Dentre estes destacam-se câmeras windows, ou seja, janelas separadas na qual uma representação gráfica do modelo do produto é apresentada. Facilidades de visualização incluem a apresentação da imagem do modelo em 3D utilizando a API Java3D, realizando a renderização no servidor. A seguir é feita a apresentação das imagens renderizadas no formato ``jpeg'' no cliente. O servidor, também, gera o formato ``VRML'' sendo enviado para o cliente, onde é carregada utilizando Java3D cena .

O envio de um arquivo VRML para o cliente demanda pequena largura de banda, algo em torno de 100 kbytes para um modelo de feature de média complexidade. Os arquivos no formato jpeg são da ordem de 10 kbytes.

5.3.2 Modelagem Sólida Cooperativa (CSM)

O sistema CSM (Collaborative Solid Modelling) é um sistema de modelagem cooperativa baseado na Web (CHAN, 1999) que usa muitos métodos de concorrência. É criado um ambiente multi-usuário onde um modelo compartilhado pode ser acessado e modificado por vários usuários em tempo real, sendo que cada usuário tem seu próprio modelo local. Novamente a abordagem replicada é usada neste sistema. A estrutura do sistema CSM é apresentada na figura 5.6. Quando muitos clientes distribuídos desejam iniciar uma sessão de modelagem, Java applets são iniciados nos browsers dos clientes conectados ao servidor CSM. Este servidor é usado para sincronizar os clientes. Mudanças realizadas por um dos clientes são primeiramente aplicadas à cópia local do modelo. Depois, as mudanças são enviadas para o servidor, que atualiza o modelo global no lado do servidor. Finalmente, as mudanças são enviadas para todos os outros clientes, que atualizam suas cópias locais.

**Figure 5.6:** Arquitetura do sistema CSM.
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig5_6.ps}}$

5.3.3 NetFeature

NetFeature (LEE, 1999) é um sistema de modelagem baseado em features e na web. Diversos browsers distribuídos são os clientes que conectam-se ao servidor de modelo de feature neutro. O servidor NetFeature tem muitos componentes como mostrado na figura 5.7. O Modelo de Features Neutro comunica-se com um servidor de Base de Dados, que gerência todos os dados do modelo. O Modelo de Features Neutro mantém uma B-rep do modelo de feature usando atributos para armazenar informações como superfície de acabamento, tolerâncias dimensionais e de forma. Os atributos podem ser incorporadas a cada feature sólida, face, aresta e vértice do modelo R-rep. O Modelo de Feature Neutro é construído a partir do kernel de modelagem sólida ACIS. O Gerenciador de Agentetypeset@protect @@footnote SF@gobble@opt Sistemas Multi-Agentes (MAS) serão descritos no capítulo 7. Feature controla todos os agentes, onde cada agente é responsável por um cliente e fornece serviços para este cliente respondendo suas solicitações. O servidor fornece algumas funções básicas para o Modelo de Feature Neutra, incluindo a criação de entidades geométricas, operações Booleanas, entre outros.

**Figure 5.7:** Arquitetura do NetFeature.
$\resizebox*{14cm}{6cm}{\includegraphics{fig/fig5_7.ps}}$

5.4 Outros Sistemas Correlatos

Serão analisados alguns sistemas correlatos, assíncronos ou não concorrentes, sendo portanto não cooperativos segundo a definição adotada. Entretanto estes sistema utilizam-se de computação distribuída como ocorre com os sistema cooperativos.

5.4.1 WebCAD3D

WebCAD3D (WANG, 1998) é um sistema de manufatura ``rápido'' que faz uso do WWW como mecanismo de integração. O sistema tenta integrar os ambientes de projeto e manufatura distribuído, através do projeto criado em um cliente web e enviado para um servidor de manufatura sobre a Internet. No servidor de manufatura, uma aplicação envia os comandos necessários para uma fresadora CNC.

O sistema WebCAD3D é parte do sistema denominado de CyberCut (http://cybercut.berkely.edu) que realiza a integração CAD/CAPP/CAM para fabricação de peças prismáticas a partir do WebCAD3D que é um applet, iniciado a partir de um browser. A arquitetura do WebCAD3D, Cybercut, é apresentada na figura 5.8. Segundo WANG (1998) uma comunidade de manufatura globalizada será o futuro do ambiente de manufatura. Cada membro da comunidade irá fornecer seus próprios serviços e ferramentas. Este novo paradigma para o ambiente de manufatura foi definido de TeleManufatura.

**Figure 5.8:** Arquitetura do sistema WebCAD3D (Cybercut).
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig5_8.ps}}$

O sistema é disponível para os usuários como um Java applet que pode ser usado em combinação com um web browser. É usado a Modelagem Sólida Destrutiva (DSM) de maneira a refletir o processo de fabricação que trabalham com operações de fresamento, utilizando o conceito de features de usinagem/manufatura (subtrativas). Uma ferramenta de modelagem 2D no lado do cliente (applet) é usada para criar peças prismáticas 3D. Uma versão 3D-wireframe do projeto é visualizada pelo cliente.

Como um meio termo entre os ambientes de manufatura e projeto, uma variação do DSM, o DSM Solid Interchange Format (SIF) é usado. Este contem informações adicionais da peça, como tolerâncias e informações específicas de usinagem, como raio de canto. O cliente faz uso de um conjunto pré-definidos de features de usinagem, armazenadas em uma biblioteca, que podem ser fabricadas na máquina disponível. Esta biblioteca de projeto está situada no servidor.

A modelagem por features de usinagem permite uma fácil inter-operabilidade entre projeto e fabricação e é extremamente adequado para sistemas deste tipo (projeto e fabricação de peças prismáticas). Durante a criação das features, um checador de regras de projeto garante a manu-faturabilidade do modelo. Exemplos de regras de projeto incluem as condições que furos e de certas features que não podem ser posicionadas com relação a uma aresta.

5.4.1.1 Cybercut (http://cybercut.berkeley.edu)

Cybercut é um sistema orientado ao problema de Projeto e Fabricação baseado na web (BROWN e WRIGHT, 1998), consistindo de três componentes:

Software de CAD escrito em Java usando applets via páginas web. O sistema CAD é baseado no conceito de Destructive Solid Geometry (DSG); o qual, obriga o usuário a remover entidades geométricas (features) de uma peça de formato regular através do fresamento da peça bruta, de tal forma que o processo de manufatura da peça é incorporado, de forma inerente, ao projeto;
Um sistema de Planejamento de Processo Auxiliado por Computador (CAPP) que acessa uma base de conhecimento contendo informações sobre ferramentas e fixações;
Uma fresadora CNC de arquitetura aberta que pode receber informações de planejamento e projeto em linguagem de alto nível e executar a usinagem sobre uma fresadora Haas VF-1.

Com acesso à interface de CAD (WebCad3D), a partir da internet, qualquer engenheiro com um browser WWW torna-se um potencial usuário desta ferramenta de prototipagem rápida on-line. A GUI possibilita que um usuário remoto seja capaz de fazer o download de um arquivo CAD em um formato específico, de troca de dados universal, para o servidor Cybercut, o qual irá executar o planejamento de processo necessário e gerar o apropriado Código G para a fresadora. A peça poderá ser usinada e enviada para o projetista. O engenheiro pode ter um protótipo funcional dentro de poucos dias por uma fração do custo que a fabricação in-house exigiria. O Cybercut trabalha com os processos de Fresamento, Furação e Fresamento de Forma Livre (Freeform).

5.4.2 CyberView

CyberView (KIM, 1988) usa modelagem assíncrona combinada com visualização via web browser. A estrutura do sistema é mostrada na figura 5.9. Uma Base de Dados Orientada a Objetos (OODB) é localizada no lado do servidor. Esta contêm arquivos de dados dos produtos utilizando o padrão STEP, produzido por uma aplicação CAD independente. Os arquivos STEP são enviados para a base de dados pelo protocolo FTP. Desde que a maioria das aplicações CAD não podem ser executadas sobre o mesmo sistema computacional, esta abordagem foi o modo mais fácil de garantir que os usuários pudessem usar seus próprios sistemas CAD. A modelagem não síncrona é naturalmente possível, pois aplicações CAD stand-alone são usadas para produzir e manipular arquivos STEP. Para visualizar em um web browser, VRML é usada. Certamente o browser deve ter integrado um visualizador VRML. KIM (1998) discute a tradução do formato STEP para um modelo VRML. Por exemplo, B-splines e NURBS têm de ser transformados em uma malha de poligônos, pois VRML não é capaz de manipular primitivas como estas. O usuário pode navegar através do modelo VRML e avaliá-lo olhando todos os seus lados, adicionar comentários que serão gerenciados pelo gerenciador de visualização e comentários, possibilitando que outros usuários vejam o modelo um pouco mais tarde, tendo acesso aos comentários já feitos e armazenados na OODB.

**Figure 5.9:** Arquitetura do sistema CyberView.
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig5_9.ps}}$

5.4.3 Prototipagem Rápida Baseada na Web

A URL http://tmf.sdsc.edu apresenta um projeto da pesquisa e desenvolvimento chamado Tele-Manufacturing Facility (TMF). O TMF oferece um serviço de Prototipagem Rápida (RP) automatizado baseado na Internet. O sistema disponibiliza um serviço para que usuários remotos tenham a possibilidade de fabricarem um protótipo de uma peça a partir do arquivo em formato ``.STL'' (estereolitografia).

Ao estabelecer uma conexão através da Web, o usuário submete o trabalho a ser produzido, e o sistema automaticamente o mantém em uma fila para ser processado posteriormente em uma máquina Z 402 da Z Corporation. Um outro esforço tem sido empreendido no sentido de reduzir a necessidade de verificação manual, por uma pessoa, dos arquivos de peças RP. Os arquivos ``.STL'', para Prototipagem Rápida, contêm falhas geométricas e topológicas. Atenção especial está sendo dada no processo de verificação automática para determinar estas falhas nos arquivos ``.STL'', e em muitos casos, corrigi-los automaticamente.

LUO et al. (1999) apresentam a arquitetura de outro sistema de prototipagem rápida baseado na Web (http://www.ia.ee.ccu.edu.tw). O sistema utiliza uma arquitetura Cliente/Servidor para acessar a máquina de RP fazendo a sua teleoperação remota. O sistema TFM, descrito anteriormente, não permite a teleoperação da máquina apenas a submissão do arquivo de uma peça a ser processada posteriormente sem intervenção do cliente. É utilizado a mesma arquitetura dos sistemas de teloperação desenvolvidos na UnB/Graco. A geração do arquivo ``.STL'' não está disponível no sistema, ou seja, o usuário terá de fazer o download de seu arquivo .STL gerado em seu próprio sistema de modelagem CAD. Todos os sistemas relacionados na literatura só realizam o serviço de RP desde de que seja enviado o arquivo ``.STL'' e/ou a teleoperação da máquina pelo cliente usando a Internet.

5.4.4 MAS: Manufacturing Advisory Service

MAS é uma ferramenta computacional para auxíliar o projetista durante o ciclo de desenvolvimento de produto, em especial na seleção de material e processo de manufatura, desenvolvida por SMITH (1999) na sua tese de doutorado. MAS gera um diálogo com o projetista, inquerindo-o sobre tamanho de lote, tolerâncias típicas, dimensões, forma, requisitos de custos, entre outros. A cada passo é apresentado ao usuário uma lista com um ranking das opções de manufatura. Um método similar é usado para definir os requisitos para seleção de materiais (propriedades mecânicas, físicas e químicas), geramdo um ranking de materiais.

MAS foi desenvolvido como um applet Java disponível via Web através da URL http://cybercut.berkeley.edu/mas2typeset@protect @@footnote SF@gobble@opt MAS2 é parte do sistema Cybercut. . MAS executa os cálculos utilizando a dados disponibilizados através de base de dados remotas, que podem ser manuseadas e atualizadas através de ferramentas administrativas através da Web.

5.5 Estruturas Para Desenvolvimento de Sistemas Cooperativos

São descritas algumas estruturas que podem ser usadas no desenvolvimento de sistemas e aplicações cooperativas.

5.5.1 WELD

O WELD (Web-based Electronic Design Environment) fornece uma estrutura de plataforma independente para acoplamento de aplicações e ferramentas CAD existentes de maneira a criar um ambiente de projeto cooperativo (CHAN, 1998). A arquitetura WELD (figura 5.10) está conectada a servidores remotos, serviços de rede e clientes. Os clientes podem ser Java applets ou browsers, com suporte em rede fornecido por um web browser, ou clientes genéricos com suporte à rede integrado. Estes clientes genéricos podem ser implementados em linguagem C, C++ ou Java.

**Figure 5.10:** Ambiente WELD.
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig5_10.ps}}$

5.5.2 COCA

O COCA (Collaborative Objects Coordination Architecture) é uma arquitetura de coordenação genérica que permite aos usuários utilizarem regras sociais em um sistema cooperativo (LI, 1998). Estas são especificadas usando uma linguagem de especificação baseada em lógica. A arquitetura COCA consiste de três camadas (Figura 5.11). O nível mais baixo é a camada de comunicação, que usa IP Multicast e Unicast, mandando mensagens para um endereço especificado da rede (IP). Acima da camada de comunicação temos a camada de cooperação/colaboração. É implementada por máquinas virtuais que gerenciam as funções dos diferentes usuários e mantém um conjunto individual de regras de decisão que são específicas para uma função. A camada do topo é chamada de camada de aplicação. Esta contém ferramentas de controle da sessão, ferramentas de apresentação de dados, ferramentas de comunicação e interfaces de manipulação. Todas estas ferramentas estão disponíveis para um usuário na camada de aplicação.

**Figure 5.11:** Arquitetura COCA.
$\resizebox*{14cm}{6cm}{\includegraphics{fig/fig5_11.ps}}$

5.5.3 DistView

DistView (PRAKASH, 1994) é um toolkit que pode ser usado para desenvolver aplicações cooperativas para uso sobre redes de comunicação de área (WAN). É usado a abordagem replicada, onde objetos compartilhados têm cópias locais disponíveis sobre todas as aplicações participantes, que são atualizadas, apenas, quando mudanças tenham ocorrido. A estrutura do ambiente DistView é apresentada na figura 5.12.

**Figure 5.12:** Estrutura DistView.
$\resizebox*{13cm}{8cm}{\includegraphics{fig/fig5_12.ps}}$

6. Sistema de Telemanufatura: WebOxicorte

Este capítulo descreve a implementação de uma interface (GUI - Graphical User Interface) para teleoperação de uma Máquina de Oxi-corte Industrial da White Martins (AutoCut 2.5L) com Comando Numérico Computadorizado da MCS Engenharia (MCS-520) e de um ambiente integrado CAD/CAM para programação da máquina de oxi-corte, utilizando os Protocolos Internet (TCP/IP) via Web (http://weboxicorte.graco.unb.br) em um contexto de TeleManufatura, desenvolvida pelo doutorando et al. , na Universidade de Brasília.

Este sistema é apresentado como referência, para se ter uma idéia das funcionalidades, normalmente, presentes em sistemas de TeleManufatura. Deve ser tomado como referência por se tratar de um pequeno sistema integrado para modelagem baseado em features de forma (2D), geração do programa NC e fabricação da peça remotamente, através da teleoperação da máquina de Oxi-corte CNC.

As GUIs disponibilizam ao usuário remoto funções para o controle da máquina, bem como, um ambiente CAD/CAM para geração do código G baseado no padrão RS 274. O sistema baseia-se na arquitetura cliente-servidor, utilizando-se de um ¨browser¨ como cliente e um computador pessoal com sistema operacional Linux como servidor. A GUI é baseada na linguagem de programação Java e HTML e tem como servidores programas desenvolvidos na linguagem C para controle da máquina.

A comunicação entre o servidor e a máquina é realizada através do protocolo de comunicação DNC (Comando Numérico Distribuído) do próprio CNC. A GUI para teleoperação consiste em uma página HTML contendo applets Java (para o controle da máquina) e imagens capturadas por uma Webcam. Desta forma o usuário, através de um ¨CNC virtual¨ é capaz de enviar e executar programas, assim como as operações básicas da máquina. A segunda GUI para programação NC é orientada a máquina da White Martins, onde, o Projeto é baseado em Features. As features são elementos geométricos (linhas e arcos de circunferência) que são adicionados durante o processo de modelagem 2D, para definir o perfil da peça a ser cortada.

A interface desenvolvida mostrou-se bastante versátil, permitindo a programação e a teleoperação da máquina de qualquer lugar provido de computador e Internet.

6.1 Introdução

A globalização tem afetado diretamente as empresas, os consumidores e as economias dos países. Componentes e produtos variados e de boa qualidade, fabricados em diferentes países, têm sido disponibilizados a pessoas em qualquer parte do mundo, muitas vezes a preços iguais ou inferiores aos produtos nacionais. A Internet tem contribuído significativamente para a globalização, pois ela permite uma comunicação mais rápida entre pessoas e também empresas. Uma prova disto é a quantidade de recursos que têm sido gastos no comércio eletrônico. Analistas estimam que em 1999 o business to costumer (B2C) girou em torno de US$ 17 bilhões, e o business to business (B2B) em US$ 68 bilhões (POMBO, 1999). Além da venda de itens como carros, jóias e livros através da Internet, esta tecnologia tem sido utilizada com sucesso em outras atividades importantes, como a manutenção remota de equipamentos (ROCKWELL, 2002) e a cirurgia do cérebro efetuada por um robô comandado remotamente por um cirurgião localizado a centenas de quilômetros de distância (SCIENTIFIC AMERICAN, 2000).

Tendo em vista a importância e popularidade da Internet, é apresentado um sistema para a teleoperação de uma máquina de oxi-corte CNC, visando a aplicação e domínio de ferramentas relacionadas à Internet, bem como a disponibilização das funções de controle para qualquer usuário que queira manipular remotamente a máquina. Neste capítulo é feita uma descrição da Interface Gráfica do Usuário (GUI), através da qual efetua-se a entrada dos dados referentes à peça (produto) a ser fabricada. Descreve-se também outros módulos utilizados que permitem a teleoperação desta máquina.

Como outras vantagens do desenvolvimento deste sistema, pode-se citar: (i) o usuário não necessita adquirir a máquina para fabricar a peça desejada; (ii) o sistema pode ser utilizado como uma plataforma educativa sobre assuntos como Internet, Telemanufatura, Teleoperação, Comando Numérico e Oxi-corte.

6.2 Ambiente CAD/CAM

A GUI consistiu no desenvolvimento de um applet utilizando a linguagem de programação JAVA para a integração CAD/CAM do processo de oxi-corte baseado na tecnologia de Projeto by Feature, utilizando a modelagem por features de forma. No caso são utilizadas, basicamente, duas features de forma para permitir a modelagem da peça 2D a ser fabricada pelo processo de oxi-corte NC (Comando Numérico): linhas e arcos.

O Java applet permite a modelagem de uma peça utilizando coordenadas cartesianas e a geração do código G para o processo de oxi-corte. O applet também permite a inserção de dados referentes ao planejamento do processo, sendo estes: tempo de pré-aquecimento, velocidade de corte e tamanho da chapa bruta. Desta forma o Projeto by Features contempla as visões de projeto e de manufatura durante o ciclo de desenvolvimento do produto.

6.2.1 Implementação da GUI

A implementação da interface CAD foi feita de forma parametrizada (projeto paramétrico) u-sando a linguagem Java através da função canvas que cria uma área retangular de coordenadas cartesianas, permitindo o desenho de formas geométricas (features: linhas e arcos), utilizando-se da API padrão AWT, que permite a criação de controle da GUI.

O modelo da peça é representado em termos de features de projeto. As features de manufatura são obtidas através da conversão ou mapeamento de features de projeto para o domínio da ma-nufatura, sendo o mapeamento feito através da técnica um-para-um, ou seja, a feature resultante do mapeamento é idêntica à feature mapeada (SWAN e MANTYLÄ, 1995).

Um dos problemas encontrados no canvas foi que o ponto (0,0) fica localizado no canto superior esquerdo do retângulo ao invés do canto inferior esquerdo. Implementou-se na GUI quatro comandos de máquina para o corte:

Avanço Rápido associado ao código G00;
Corte linear associado ao código G01 (interpolação linear);
Corte circular no sentido horário associado ao código G02 (Interpolação circular no sentido horário);
Corte circular no sentido anti-horário associado ao código G03 (Interpolação circular no sentido anti-horário).

Além destes comandos associados ao código G são incluídas algumas funções miscelâneas (Funções M) e ciclos fixo para controlar o tempo de pré-aquecimento (Ciclo Fixo 83) e ligar o controle de altura automático da tocha (M42).

Para cada função G utilizou-se uma cor diferente, de forma que seja possível identificar, visualmente, os diferentes passos que foram feitos na modelagem da peça. Para a implementação da feature linha, interpolação linear, utilizou-se uma função do Java denominada drawline que tem a função de desenhar uma reta no canvas. Para isso deve-se passar quatro parâmetros (xo,yo, x1,y1) que são as ordenadas e abcissas do ponto inicial e do ponto final. Estes parâmetros devem ser números inteiros.

Para a implementação das features de arco de circunferência, interpolação circular, utilizou-se a função drawarc que desenha um arco na área delimitada no canvas. O arco é desenhado dentro do retângulo definido, passando-se à função seis parâmetros:

Abscissa do canto superior do retângulo (x);
Ordenada do canto superior do retângulo (y);
Largura do retângulo;
Altura do retângulo;
ângulo inicial do arco;
ângulo que o arco percorre.

A figura 6.1 apresenta a GUI desenvolvida. O programa gerado é apresentado em um frame ao lado do perfil da peça, executado durante a modelagem. Como um Applet, por questão de segurança, não permite que seja feita a gravação do programa NC gerado na forma de arquivo no computador local, é necessário realizar uma operação de Cut/Paste e salvar o arquivo localmente em formato ASCII (texto puro, sem formatação). Outra opção poderia ser o envio do programa NC gerado no cliente para ser armazenado no servidor. Entretanto, esta opção causaria dependência do applet, em relação a sua conexão através do mecanismo de socket, ao servidor web e a uma base de dados para armazenamento dos programas, sem que isso realmente fosse necessário. Assim, esta funcionalidade não foi implementada no sistema.

**Figure 6.1:** GUI do ambiente CAD/CAPP/CAM do sistema WebOxiCorte.
$\resizebox*{14cm}{10cm}{\includegraphics{fig/fig6_1.ps}}$

6.3 Protocolo de comunicação DNC para comandos MCS

Quando a máquina de oxi-corte opera em modo DNC (Comando Numérico Distribuído), ficam acessíveis à estação remota (host) praticamente todos os comandos relativos à operação local do CNC, bem como informações de status indispensáveis ao controle das operações da máquina (MCS, 1999) e (MARTINS, 1999). A figura 6.2 apresenta o sistema DNC da MCS. A conexão do computador (host) ao CNC é feita através da interface serial RS-232.

**Figure:** DNC via Interface Serial: Estação Remota Simplificada.
$\resizebox*{14cm}{6cm}{\includegraphics{fig/fig6_2.eps}}$

Para que os comandos sejam entendidos pelo CNC, o periférico/host deve enviar as mensagens no seguinte formato/protocolo: @ C1 C2 C3 Argumentos !

Onde:

@ - caracter de início de mensagem;
C1, C2, C3 - identificação da mensagem;
Argumentos - dados complementares;
! - caracter de final de mensagem.

6.3.1 A Biblioteca MCS para Teleoperação

A MCS (1999) desenvolveu um conjunto de códigos para que as mensagens passadas para o CNC possam ser acompanhadas ou não de argumentos apresentados na Tabela 6.1.

**Table:** Códigos e respectivos argumentos
$\begin{table}\par\par {\centering\resizebox*{15cm}{7cm}{\includegraphics{fig/tab6_1.ps}}\par } \end{table}$

O comando e envio de teclas permite a operação remota do CNC, da mesma forma que a operação local pelo teclado. Além disso, a MCS (1999) disponibilizou as teclas para funções especiais. Existe a possibilidade de bloqueio de operação local (via teclado) do CNC, bem como do potenciômetro de override de avanço (que assume 100%). Pode-se solicitar o status do comando sobre: modo de operação corrente e status de execução de funções auxiliares (M/S/T). Para o modo de operação corrente, tem-se a identificação da informação de status no argumento da mensagem:

0i - modo inicial (aguardando inicialização)
1m - modo manual
2a - modo manual/automático
3s - modo de execução passo-a-passo
4c - modo de execução contínua
5p - programação
6x - comunicação externa
7r - busca de referência

Para status de execução de funções auxiliares (M/S/T):

0m - aguardando função M
1s - aguardando função S
2t - aguardando função T

Pensando numa possível emergência externa, a MCS disponibilizou uma função que bloqueia todas as funções de controle de saídas analógicas e liberação de movimentos. Desta forma o comando só é liberado após este erro quando o circuito de emergência externa for rearmado e houver uma ordem de reconhecimento de erro via tecla CE. Além do comando específico para emergência externa, o mesmo pode ser feito passando-se um código específico. Em caso de ocorrência de algum tipo de erro, existem códigos de erro associados. Alguns exemplos de condição de erro detectada pelo CNC podem ser:

Código de erro = 00 - erro de operação (erro não grave)
Código de erro = 24 - grave erro de posicionamento X
Código de erro = 42 - grave erro de check sum eprom

Alguns erros são exclusivos do DNC e não afetam a operação normal do CNC, embora sejam informados ao host. Esses erros são:

D0 - fim de caracteres inesperado
D1 - fim de sentença inesperado
D2 - sentença inválida
D3 - sentença muito longa
D4 - buffer de comandos lotado

O caracter "@" interrompe qualquer mensagem em curso, colocando o comando no estado de início de recepção de mensagens, ou seja, aguardando o caracter de início de mensagem "@". O caracter "!" é enviado apenas para garantir uma interpretação correta da interrupção da mensagem. Maiores detalhes podem ser obtidos em MCS (1999) e SOUSA (2000).

6.4 Arquitetura do Sistema de Teleoperação WebOxiCorte

O sistema de Teleoperação da Máquina Oxi-Corte, denominado WebOxiCorte, é baseado em uma arquitetura Cliente-Servidor (ÁLVARES e TOURINO, 2000) sendo constituído por dois módulos (SOUSA, 2000):

O Servidor, representado pelos programas localizados na Estação de Trabalho (computador pessoal com Sistema Operacional Linux), conectado à Máquina de Oxi-corte via interface RS-232C;
O Cliente, representado por um Applet Java localizado no browser do cliente.

A figura 6.3 apresenta a arquitetura do sistema WebOxiCorte.

**Figure:** Arquitetura de Teloperação do Sistema WebOxiCorte.
$\resizebox*{14cm}{5cm}{\includegraphics{fig/fig6_3.ps}}$

A figura 6.4 apresenta a arquitetura detalhada do sistema onde são apresentados os principais módulos do sistema de teleoperação via Internet (TCP/IP).

6.5 Servidores do Sistema de Teleoperação WebOxiCorte

O servidor de Teleoperação WebOxiCorte (figura 6.4) é constituído pelo servidor de vídeo e servidores de teleoperação da máquina que disponibilizam serviços de comando, execução de programas, download e upload de programas, tratamento de erros e demais funções associadas ao protocolo DNC da MCS (1999). O servidor de vídeo é responsável pela captura de vídeo e sua distribuição através do protocolo TCP/IP (Internet). Os demais servidores, associados aos serviços de teleoperação, propriamente dito, trabalham de modo bidirecional, recebendo comandos através da Internet e enviando dados de status da máquina.

**Figure:** Arquitetura detalhada: módulos do sistema WebOxiCorte.
$\resizebox*{15cm}{8cm}{\includegraphics{fig/fig6_4n.ps}}$

A conexão Internet é implementada através de canais de comunicação denominados de sockets (ARNETT, 1994) entre os módulos WebOxiCorte e módulo Usuário/Cliente. Usualmente este tipo de conexão é programado usando as chamadas BSD Library (comandos como socket, bind e accept). Neste trabalho, o servidor inetd foi usado para estabelecer a conexão a fim de facilitar o desenvolvimento dos servidores (ARNETT, 1994). A figura 6.5 apresenta a utilização do servidor inetd como gerenciador de conexões. Esta mesma abordagem é utilizada por serviços de telnet, ftp e finger, entre outros, em ambiente Unix (TOURINO, 2000). O servidor inetd ao receber uma conexão via TCP/IP cria uma cópia dele mesmo, através do comando fork, e executa o programa servidor, normalmente escrito em C ou perl, através do comando exec (figura 6.5). A utilização do inetd é vantajosa em relação a programação convencional utilizando diretamente os canais de comunicação (sockets) pois reduz a carga sobre o sistema operacional e facilita o desenvolvimento de programas que realizam a comunicação via Internet.

**Figure 6.5:** Servidor inetd.
$\resizebox*{10cm}{8cm}{\includegraphics{fig/fig6_5.ps}}$

6.5.1 Servidor de Vídeo

O servidor de vídeo é responsável pela captura de vídeo e o envio de dados via Internet. As imagens são captadas por uma WebCam, enviadas via TCP/IP e animadas. Foi utilizado o mecanismo de animação de vídeo do Netscape denominado Server push que dispensa a utilização de plug-ins (ÁLVARES et al. , 1999). Através deste mecanismo faz -se o envio contínuo de dados do servidor WebCam para o browser (Netscape), mantendo a conexão entre os dois aberta, e o próprio browser faz a animação em função da quantidade de frames enviados por segundo (WEINMON, 1997). O servidor webcam foi implementado de forma distribuída em uma segunda estação de trabalho (Solaris, Sparc20) utilizando a placa de captura de imagens SunVideo (SUN, 1994).

6.5.2 Servidor WebOxiCorte

Este servidor aceita conexões via TCP/IP através do programa/servidor inetd (daemon) configurado para aceitar conexões através da Porta 8088 (SOUSA, 2000). Uma vez estabelecida a conexão o servidor aguarda por comandos enviados pelo cliente (browser) executando-os caso a sintaxe esteja correta. A figura 6.6 apresenta os comandos aceitos pelo servidor WebOxiCorte. Alguns exemplos de comandos aceitos pelo servidor são (SOUSA, 2000):

bloqcnc: bloqueia a operação local do CNC, bem como o potenciômetro de avanço;
manual: seleciona o modo de funcionamento manual;
program: seleciona o modo de programação;
execcon: seleciona o modo de execução contínua;
start: inicializa o processo de Oxi-corte;
bye: finaliza a conexão entre o servidor e o cliente.

Figure 6.6: Comandos aceitos pelo servidor WebOxiCorte.
$\resizebox*{15cm}{6cm}{\includegraphics{fig/fig6_6n.ps}}$

6.5.3 Servidor de Posicionamento da Tocha de Oxi-corte (Controle)

Este servidor é responsável pelos comandos de movimentação da tocha de oxi-corte. Este servidor foi denominado de Posicionamento da Tocha (Controle) e aceita conexões via TCP/IP através do programa inetd pela porta 8089. Alguns comandos aceitos pelo servidor são:

left: movimento incremental de 50 mm para esquerda;
front: movimento incremental de 50 mm para frente;
down: movimento incremental de 50 mm para baixo;
bye: finaliza a conexão entre o servidor e o cliente.

6.5.4 Servidor de Seleção de Programas

Este servidor é chamado de EnvP, sendo configurado no inetd pela porta 8091. Sua finalidade é enviar programas para a máquina, colocando a máquina em modo de comunicação externa e enviando para a máquina o programa NC (comando numérico) desejado.

6.6 GUI Para Teleoperação

A Interface Gráfica com o Usuário (GUI - Graphical User Interface) é baseada na linguagem de programação Java, criada pela SUN MICROSYSTEMS (1999). A GUI, front-end do usuário consiste em dois applets, ou seja, dois programas carregados pelo browser: Na figura 6.7(a) é apresentado o Applet de Controle do CNC, e na figura 6.7(b) o Applet de Posicionamento da Tocha . A animação da recepção das imagens em formato jpeg (ÁLVARES et al. , 2000) é realizado pelo próprio browser, no caso o Netscape. Durante a operação do sistema WebOxiCorte o usuário visualiza a animação gerada. Caso seja necessário pode-se realizar um zoom da imagem pressionando o botão esquerdo do mouse sobre a animação.

**Figure:** Applets do sistema de teleoperação.
$\resizebox*{9cm}{10cm}{\includegraphics{fig/fig6_7.ps}}$

6.7 Resultados e Discussão

A GUI implementada para a teleoperação da máquina de Oxi-Corte CNC é apresentada na figura 6.8. O sistema pode ser acessado através do site http://weboxicorte.graco.unb.br, sendo que somente usuários cadastrados (login & password) podem utilizar o sistema. Os testes de integração do sistema consistiram na geração do programa NC utilizando a GUI de modelagem baseada em features, o download do programa em Código G gerado no passo anterior para a máquina CNC, seguido da execução do programa, a fim de realizar o corte da peça idealizada; o qual foi executado com sucesso.

Devido as limitações de recursos da máquina, que poderão ser sanados com um update de eprom, não foi possível implementar um sistema de status de memória da mesma. Outra limitação da máquina diz respeito a regulagem da chame do processo de oxi-corte que só pode ser realizada através de operação manual. Outra restrição em sistemas de teloperação via Internet refere-se a largura de banda e aos atrasos inerentes ao próprio protocolo TCP/IP (ÁLVARES et al. , 2000 e 1999). Para resolver este problema é necessário dotar o sistema de teleoperação no servidor, junto à máquina de Oxi-corte, de mecanismos que possibilitem a tomada de decisão em situações críticas sem depender do lado do cliente, no caso o usuário/operador.

Assim é necessário dotar o sistema de alguma inteligência para resolver conflitos que poderão ocorrer durante o processo de teleoperação. Os comandos transmitidos para o servidor são transferidos de forma rápida, por solicitarem uma pequena largura de banda. Por outro lado, para a realimentação em vídeo é necessário uma largura de banda da ordem de 16 kbytes/s em função da quantidade de frames utilizada na animação A GUI baseada em Java possibilita a obtenção de ótimo resultado visual, bem como independência de plataforma. Atualmente Java é a melhor solução para desenvolvimento de front-end para aplicações em telemanufatura e em particular em sistema de teleoperação.

**Figure:** Interface Gráfica com o Usuário: Java.
$\resizebox*{16cm}{13cm}{\includegraphics{fig/fig6_8.ps}}$

6.8 Conclusões

O capítulo descreve um sistema de Telemanufatura apresentando o desenvolvimento do sistema WebOxiCorte voltado para modelagem by features via Web, consistindo de um ambiente integrado de CAD/CAPP/CAM e de um sistema de teleoperação da máquina de oxi-corte CNC utilizada.

O sistema apresentou bons resultados no que concernem as funções diretamente relacionadas ao controle da máquina de oxi-corte através do seu protocolo de comunicação (DNC), por requerer a transmissão de mensagens com poucos bytes de tamanho para implementar estas funções. Entretanto, a realimentação através de vídeo exige maior largura de banda para aplicações em tempo real. O sistema comprovou sua operacionalidade, conectando o cliente ao servidor WWW e este ao processo de oxi-corte, permitindo a modelagem da peça, geração do Código G e o envio e recebimento de informações. É necessário levar em conta os aspectos referentes à segurança. Uma resposta da máquina CNC ao servidor pode ser degradada em função de atrasos de comunicação entre o servidor e o cliente. Assim, os aspectos de tempo real têm grande importância de acordo com o nível de segurança exigido. A tecnologia de TeleManufatura e em especial de Teleoperação via Internet encontra-se em estágio embrionário de desenvolvimento, tendo sua aplicabilidade ainda reduzida devido à baixa largura de banda disponível para transmissão de dados.

A interface desenvolvida foi testada mostrando-se adequada para aplicação de teleoperação da máquina de oxi-corte. A evolução da Internet, em especial com o Projeto Internet II, que disponibilizará uma maior largura de banda para transmissão de dados certamente motivará novos desenvolvimentos na área. Muitas empresas estão investindo no desenvolvimento de soluções em sistemas de teleoperação via Internet para aplicações prediais e residênciais, denominados de casas e prédios inteligentes. Existem algumas aplicações comerciais disponibilizadas para a área de Telemanufatura, entretanto a maior parte dos sistemas disponíveis são ainda de origem acadêmica.

7. Ferramentas Computacionais Para CAPP

Num sistema CAPP generativo, a lógica de decisão do sistema é o coração do software e direciona o fluxo do programa (FERREIRA, 1996). A lógica de decisão determina como um processo é selecionado. A decisão mais importante da lógica de decisão é combinar as capacidades dos processos com as especificações de projeto. Capacidades de processo podem ser descritas como regras de produção do tipo ``IF...THEN...''. Tais regras podem ser armazenadas sob a forma de sentenças em um simples programa ou em kernel de sistema especialista como o CLIPS e FUZZYCLIPS (REZENDE, 1996).

Existem vários métodos para descrever a estrutura de decisão no planejamento do processo. Os métodos de representação do conhecimento relacionam-se diretamente à lógica de decisão nestes sistemas. Os seguintes métodos de lógica de decisão são utilizados no planejamento do processo: tabelas de decisão e técnicas baseadas em inteligência artificial destacando-se os sistemas especialistas, lógica difusa, redes neurais, sistemas multi-agentes e algoritmos genéticos (WANG e LI, 1991).

É dado um destaque especial aos sistemas de gerenciamento de bases de dados relacional. Uma base de dados relacional é a maneira mais adequada de compartilhar dados para as diversas atividades a serem desenvolvidas para integração CAD/CAPP/CAM. Durante a modelagem by features, no cliente, é necessário o armazenamento das instâncias de classes de features definidas no processo de modelagem da peça. Estas informações devem ser armazenadas em uma Base de Dados no servidor. Com estas informações disponíveis, o sistema de CAPP poderá utilizar diversos métodos para resolução dos problemas referentes ao planejamento de processo. Os diversos módulos do CAPP podem trabalhar utilizando uma arquitetura multi-agente em que cada atividade a ser executada pelos módulos do CAPP seria considerada um agente.

Neste capítulo são apresentados uma pequena revisão sobre sistemas de gerenciamento de Base de Dados com enfoque em uma aplicação desenvolvida pelo doutorando et al. , utilizando os sistemas de gerenciamento de base de dados relacional Msql e Mysql e a abordagem de CAPP Variante. A seguir são apresentados algumas técnicas utilizadas na tomada de decisão de um CAPP generativo, e finalmente uma introdução sobre Sistemas Multi-Agentes e a arquitetura de desenvolvimento de agentes denominada KQML. Este capítulo é baseado nos trabalhos de ÁLVARES et al. (2002), ÁLVARES (2001), ALVINO (2001) e MANET (2002).

7.1 Modelos de Base de Dados

Segundo ALVINO (2001) os modelos de base de dados são coleções de ferramentas conceituais para a descrição de dados, relacionamentos, semântica e restrições. Existem modelos lógicos e físicos. Os modelos físicos são usados para descrever os dados no Nível Físico, eles não serão revistos pois estão muito fora do escopo deste trabalho. Os modelos lógicos são empregados nos níveis conceituais e de visão, sendo atualmente uma grande área de pesquisa e desenvolvimento (CUNHA, 2000). Existem basicamente dois grandes grupos de modelos lógicos: Modelos Lógicos Baseados em Registros e Modelos Lógicos Baseados em Objetos.

7.1.1 Modelos Lógicos Baseados em Registros

Os Modelos Lógicos Baseados em Registros são assim denominados porque a base de dados é estruturada em registros de vários tipos, cada um dos quais define um número fixo de campos ou atributos, com tamanhos ou comprimentos também fixos. Os três modelos lógicos mais difundidos são (DANTE, 1991), (CUNHA, 2000) e (NETO, FURLAN e HIGA, 1988):

7.1.1.1 Modelo Relacional

São os modelos mais usados atualmente. Eles representam uma coleção de dados interrelacionados em forma de tabelas ou relações bi-dimensionais. As linhas das tabelas possuem os dados armazenados, também chamados de registros ou domínios. As colunas são campos ou atributos que especificam a denominação e o tipo destes dados. As tabelas estão relacionadas entre si numa correspondência unívoca, através de uma coluna ou combinação de colunas denominadas de chave primária, nas quais a qualquer momento, nenhum par de linhas da tabela contém o mesmo valor. Cinco operações fundamentais baseadas na álgebra relacional são responsáveis pela manipulação da base de dados (transações): seleção, união, projeção, produto, e diferença. Em adição, pode-se definir combinações em termos das operações de produto e seleção. Assim, dados complexos podem ser modelados com base em simples tabelas.

7.1.1.2 Modelo Hierárquico

Abordagem dominante na década de 60, são representados por estruturas em árvore cujos elementos, chamados de nós, estão dispostos de maneira hierárquica através de ligações únicas. O topo da estrutura, comumente chamado de raiz, é o objeto modelado através da combinação dos vários nós. Esta estrutura é rápida e fácil mas poucos elementos no mundo podem ser modelados de maneira puramente hierárquica, em adição, a implementação hierárquica usualmente cria redundâncias e inconsistências.

7.1.1.3 Modelo em Rede

Desenvolvidos na década de 70, são mais genéricos, pois cada elemento pode ser ligado a vários outros elementos de maneira direta, sendo portando menos restritivos que a estrutura em árvore. A desvantagem está em sua complexidade tanto a nível da estrutura de dados quanto aos algoritmos associados.

7.1.2 Modelos Lógicos Baseados em Objetos

A proposta dos Modelos Lógicos Baseados em Objetos é relativamente mais recentes que os baseados em registros. Ela surgiu com a necessidade de se construir base de dados com melhores capacidades de descrição de aspectos semânticos das informações armazenadas. Os dois principais componentes deste grupo são (DANTE, 1991) e (CUNHA, 2000):

7.1.2.1 Modelo Entidade-Relacionamento

Este modelo se baseia na percepção do mundo como uma coleção de entidades e relacionamentos. Uma entidade é um objeto existente, físico ou abstrato, que pode ser descrito por uma série de atributos associados. O relacionamento é a representação da associação existente entre várias entidades, ao qual também podem estar associados atributos descritivos, de modo que várias regras para controles de integridade podem ser automaticamente estabelecidos.

7.1.2.2 Relacionamento Modelo Orientado a Objeto

O processo atual de desenvolvimento das técnicas de modelagem de informação apontam para a intensificação do uso de Modelos Orientado a Objeto. Estes modelos são baseados em uma coleção de objetos com atributos ou variáveis de instância manipuladas através de métodos internos. Eles incorporam os conceitos de herança, abstração, polimorfismo e encapsulamento da técnica programação orientada a objeto. Os objetos se relacionam uns com os outros trocando mensagens através de seus métodos. Aqueles que contêm os mesmos tipos de variáveis de instância e métodos são agrupados em classes, as quais podem ser vistas como o tipo de definição do objeto ou um tipo de dado abstrato. É possível organizar o modelo em hierarquias de classes com vários níveis de abstração e combinar objetos para definir outros mais complexos. A existência de métodos e atributos internos permite o encapsulamento de comportamentos complexos com semânticas detalhadamente definidas, que não são facilmente representados através de simples relações.

7.1.3 Sistema Gerenciador do Base de Dados

O gerenciador do base de dados é um módulo do DBMS (Sistema de Gerenciamento de Base de Dados) que disponibiliza uma interface entre os dados de baixo nível e os aplicativos e consultas submetidas à base de dados. Seu objetivo fundamental é facilitar e simplificar o acesso aos dados. Este módulo é basicamente responsável por (ZAIANE e KOPERSKI, 1998):

Interação com o gerenciador de arquivo, armazenando os dados no disco através do sistema de arquivos usualmente disponibilizado pelo sistema operacional. O gerenciador da base de dados deve traduzir as declarações DML (Linguagem de Manipulação de Dados) em comandos de baixo nível do sistema de arquivos.
Integridade, garantido que as atualizações na base de dados não violam a consistência.
Segurança, assegurando que os usuários tenham acesso somente aos dados permitidos.
Cópias de segurança e recuperação, detectando falhas devido à quedas de energia, danos no disco de memória, erros de software, etc.
Controle concorrente (para os grandes sistemas), preservando a consistência dos dados quando estão sendo acessados editados por múltiplos usuários.

7.2 CAPP Variante Baseado na Web (http://WebCAPP.graco.unb.br)

Segundo WANG e WALKER (1989) a informação de manufatura pode ser dividida em duas grandes áreas:

Conhecimento de manufatura: conhecimento declarativo;
Regras de manufatura: conhecimento procedural.

O conhecimento do planejamento do processo pode ser classificado de maneira geral em:

Conhecimento dos componentes/peças;
Conhecimento de máquinas;
Conhecimento de ferramentas;
Conhecimento de sistemas de fixação;
Conhecimento de materiais.

Este conhecimento pode ser armazenado em base de dados e acessado pelas várias atividades de manufatura incluindo o planejamento do processo. Normalmente o modelo de base de dados relacional é utilizado para armazenar e disponibilizar este conhecimento de manufatura para a empresa. Logo o desenvolvimento de sistemas CAPP utilizando ambientes de softwares baseados em Sistemas de Gerenciamento de Base de Dados Relacional (DBMS) é uma abordagem muito utilizada para compartilhamento do conhecimento da manufatura nas diversas atividades necessárias ao planejamento do processo.

Esta seção descreve uma implementação de um CAPP Variantetypeset@protect @@footnote SF@gobble@opt Planejamento de Processo Auxiliado por Computador segundo o método Variante. em ambiente Web denominado de WebCAPP. Para tal implementação, seguiu-se os conceitos de Tecnologia de Grupo, que regeu a classificação das peças. O sistema utilizado para classificação das peças foi o OPTIZ.

Na estruturação em ambiente Web, utilizou-se o MySQL (DBMS), PHP, plataforma Linux e o servidor Web Apache (open source). Conseguiu-se obter, como resultado, um ambiente Web de fácil utilização, capaz de atuar como auxílio ao projetista, poupando-o do trabalho de cálculos e, em alguns casos, até mesmo de pesquisa. Com o auxílio do computador, o trabalho de desenvolvimento dos planos de processo torna-se muito mais rápido, tendo em vista a existência de uma base de dados e a facilidade de não lidar com papéis (exceto na impressão do plano). Possui, também, tratamentos de erro, que impedem o projetistatypeset@protect @@footnote SF@gobble@opt Também denominado nesta seção de processista. de inserir dados errados, poupando tempo com revisões e reparos de projeto. Destaque maior ao fato da implementação ser feita para a Web, podendo o projetista/processista fazer consultas a projetos e inserir novos projetos de qualquer lugar que possua um computador conectado à Internet. Os dados são alimentados na base de dados do servidor.

7.2.1 Introdução

O sistema de Planejamento de Processo Variante concebido tem por objetivo prover padronização e facilidades de produção e manutenção no ciclo de desenvolvimento de produto, em particular, nas atividades associadas ao planejamento de processo em um contexto de Tecnologia de Grupo.

O sistema é constituído de um servidor, no qual está funcionando os aplicativos PHP4 (linguagem de programação para Web, que atua da forma server-side script ), MySQL (como um sistema de gerenciamento de base de dados relacional), servidor WEB APACHE e o sistema operacional Linux, ferramentas bastante difundidas, de distribuição open source e de fácil acesso à documentação. O sistema pode ser acessado através da URL http://WebCAPP.graco.unb.br.

O PHP garante a interatividade, leveza e rapidez para o HTML do ambiente, enquanto o MySQL tem o papel de armazenar as informações já adicionadas e as que ainda serão inseridas. O servidor tem acesso à Internet para que possa disponibilizar os serviços dos programas, podendo também oferecer os serviços em uma Intranet de uma empresa de manufatura. Tal servidor ainda poderia ser dividido em um servidor de aplicativos e um servidor de base de dados, caso necessário.

O sistema é baseado na arquitetura cliente/servidor. Nota-se que nenhum dos softwares utilizados necessita de licença para utilização, o que não gera custo algum com a obtenção e manutenção dos mesmos. O funcionamento do sistema é baseado em CAPP Variante (Planejamento de Processo Auxiliado por Computador), ou seja, o novo projeto é desenvolvido a partir do projeto padrão da família à qual irá pertencer (GROOVER, 1987) e (HALEVI e WEILL, 1995). Neste projeto padrão são feitas as modificações necessárias para este se adequar ao novo projeto, tarefa muito facilitada pela presença da base de dados relacional (WANG e WALKER, 1989).

Em grande parte dos campos o projetista apenas seleciona o item desejado em uma lista existente na base, em outros, é auxiliado por um controle de erros nos campos de entrada. Tal controle evita erros, junto com a necessidade de várias revisões, correções e atrasos decorrentes dos mesmos. Evita, também, a necessidade de utilização de papel, tanto para o projeto, como em fontes de consulta sobre operações, procedimentos, projetos anteriorestypeset@protect @@footnote SF@gobble@opt Constam na base de dados e são recuperados por procedimentos de busca e por um "Ajuda", que é acionado por um menu. .

Assim o procedimento para arquivar e recuperar os projetos são facilitados e com menor custo. O sistema tem seus projetos divididos de acordo com famílias de peças, baseadas em Tecnologia de Grupo, sendo feitas divisões em famílias de acordo com as semelhanças geométricas entre as peças.

Pode-se dizer que a Tecnologia de Grupo (GT) é "a percepção de que muitos problemas são similares, e que problemas similares, uma solução única pode ser encontrada para um conjunto de problemas, poupando-se assim tempo e esforço" (ÁLVARES et al, 1991). Como se observa da definição de GT, peças classificadas e agrupadas em famílias produzem uma base de dados conveniente para rápida solução de problemas e fácil de ser gerenciada.

7.2.2 Descrição do Sistema

7.2.2.1 Controle de Acesso

Assim que um usuário entra no site onde se localiza o sistema (http://WebCAPP.graco.unb.br), são pedidos a ele um login e uma senha. A tela de login pode ser vista na figura 7.1. Estes serão conferidos pelo servidor para que, em caso de sucesso, o usuário possa ter acesso ao sistema, denominado de e-CAPP. Estes usuários serão cadastrados no sistema de acordo com quatro categorias: administrador, projetista, supervisor e usuário.

O administrador é o responsável pela manutenção do sistema, tendo acesso às tabelas da base de dados, ao servidor e ao sistema de cadastro de usuários e todas às partes do sistema. O projetista tem acesso ao sistema WEB, mas não ao servidor, cadastro de usuários e tabelas. Pode criar e alterar projetos. O supervisor tem todos os privilégios do projetista e mais a permissão de exclusão de projetos, famílias e operações. O usuário comum tem apenas o privilégio de leitura e pesquisa, não podendo entrar na tela de edição e alteração de projetos e, muito menos, no de exclusão. Estas definições ficam alocadas numa tabela de cadastro na base de dados. Ficam criptografados por um algoritmo de criptografia de único sentido, ou seja, não há algoritmo de voltatypeset@protect @@footnote SF@gobble@opt Cada vez que alguém inserisse a senha, seria criptografada e comparada com a existente na base de dados, que fora guardada no momento do cadastro. . O administrador não tem acesso à senha de nenhum usuário, pois estariam criptografadas.

**Figure 7.1:** Tela inicial (login).
$\resizebox*{14cm}{10cm}{\includegraphics{fig/fig7_1.ps}}$

7.2.2.2 Codificação

A codificação dos projetos, famílias e operações foram baseadas no sistema Optiz (FERREIRA, 1996) e (GROOVER, 1987). Foi escolhido por ser base de inúmeros outros sistemas, ser de fácil compreensão e adequado a diversas aplicações. A concepção básica do sistema está definida em dois campos de código. Um código de forma, composto por cinco dígitos e uma parte suplementar, com outros quatro dígitos. Outro sistema de codificação estudado foi o KK-3 (ÁLVARES et al, 1991). Desenvolvido no Japão, apresenta 21 dígitos, os quais permitem completa descrição das peças. Devido a sua grande extensão, preferiu-se utilizar o Optiz, por ser mais compacto e simples de implementar.

7.2.2.3 Campos das Tabelas

As tabelas implementadas na base de dados foram baseadas em exemplos contidos em toda bibliografia mencionada e, logicamente, visam comportar os dados dos formulários e páginas do sistema. Foram concebidas com intenção de ser bem genéricas e amplas, para que pudessem ser utilizadas para projetos específicostypeset@protect @@footnote SF@gobble@opt Garantindo a portabilidade das tabelas e do sistema como um todo para vários tipos de projetos e detalhamentos. .

7.2.3 Menu Projeto

Ao colocar-se o cursor sobre o botão Projeto, aparecerá um menu com os seguintes tópicos: Pesquisar, Listar, Incluir, Alterar, Excluir. Ao clicar-se em qualquer uma das opções, será aberta a tela selecionada.

7.2.3.1 Pesquisar

A tela pesquisar é uma entrada para o código ou para o nome do projeto sobre o qual se quer obter informações. A partir deste código, ou nome, será feita uma busca na base de dados resultando em uma tela onde são apresentados os projetos iguais ou semelhantes ao da buscatypeset@protect @@footnote SF@gobble@opt Por exemplo, se for digitado apenas um número do código ou apenas uma letra serão retornados todos os projetos que possuírem este número ou letra. .

7.2.3.2 Listar

Na tela Listar, tem-se uma lista de todos os projetos existentes na base de dados, em ordem crescente de código. Esta lista é paginada de acordo com o código, visando acelerar a busca e uma apresentação visual menos poluída.

7.2.3.3 Incluir

Na tela Incluir, figura 7.2, há uma tela dividida em duas: no lado esquerdo existe a entrada dos dados do projeto; no direito, há uma tela de auxílio ao projetista, com um menu contendo opções para pesquisa ou listagem sobre projetos (pré-marcada), famílias ou operaçõestypeset@protect @@footnote SF@gobble@opt A opção escolhida irá orientar o funcionamento do resto desta página interna. . Ainda na tela de auxílio, existe outro menu para a escolha entre Listar (botão) e um campo entrada de consulta, que aparece como padrão, ou seja, sem um botão para escolha da opção.

**Figure:** Tela de inclusão de projetos.
$\resizebox*{14cm}{8cm}{\includegraphics{fig/fig_7_2n.ps}}$

Na tela da esquerda, de elaboração do projeto, existe um campo para entrada da família à qual irá pertencer a nova peça. Depois de escolhida a família, por código ou nome (podendo ser auxiliado pela tela da direita), essa tela da esquerda é substituída por uma composta pelos dados da peça padrão da família, para que possa ser editada, seguindo no padrão de elaboração do CAPP variante.

Nesta nova tela existe a possibilidade da composição manual (padrão) ou automática do número da nova peça: caso seja escolhido o modo automático, será aberta uma tela para que sejam colocados detalhes que formarão o tal código, como ser rotacional ou não, diâmetro, tolerâncias, etc.

Há, também, campos para entrada de detalhes e observações, onde existe um campo de texto livre para que sejam escritas as observações necessárias. Existe um campo para a anexação do arquivo que contém o projeto gráfico, feito em qualquer aplicativo de desenho.

A figura 7.3 apresenta uma visão geral do projeto, e se estiver todo correto, será confirmado e armazenado na base de dados. Cada projeto armazenado leva junto de si, automaticamente e obrigatoriamente, o nome do seu projetista. Na escolha listar, da tela auxiliar, são listados itens de acordo com a escolha citada, para que o projetista possa sanar suas dúvidas ao mesmo tempo que elabora um novo projeto. Esta escolha, listar, tem a mesma forma da listagem apresentada pelo botão listar (sub-menu do menu Projeto), apenas com menos detalhes. Necessitando-se de informações sobre um item da lista, pode-se clicar no mesmo e um link levará o usuário à sua página descritiva. Clicando-se no botão pesquisa, será feito o mesmo procedimento do botão pesquisa do menu principal.

Este modelo de divisão de tela será especialmente útil no momento de passar-se à escolha das operações que o projeto incluirá. Esta tela auxiliar pode parecer redundante, pois há os botões pesquisar e listar no menu Projeto, mas vale lembrar que o usuário comum não tem acesso às telas de inclusão e, portanto, à tela auxiliar mencionada.

**Figure 7.3:** Preview de Projeto.
$\resizebox*{14cm}{10cm}{\includegraphics{fig/fig7_3.ps}}$

7.2.3.4 Alterar

Na tela de alterar é aberta uma tela para a entrada do código ou do nome do projeto que se quer abrir para alterar. Este campo é de tipo de procura. A partir da identificação do projeto será feita uma busca na base de dados. Se encontrado, será aberto para alteração nos mesmos moldes do incluir (com a divisão de tela para principal e auxiliar e tudo mais), mas já com os campos preenchidos pelos seus valores (anteriores à alteração que está ocorrendo). A data de inclusão e todo e qualquer tipo de alteração são guardados em um histórico do projeto, junto com o nome de login de quem criou e quem alterou. Ninguém tem permissão de escrita neste arquivo (nem é possível excluí-lo), ele existe enquanto existir o projeto e pode ser copiado para backup.

7.2.3.5 Excluir

Na tela de excluir, tem-se o mesmo molde inicial da tela de alterar. A partir de um campo procura é encontrado o arquivo que se quer excluir. A diferença é que somente os supervisores de projeto têm permissão para excluir um projeto. A opção de excluir não é habilitada para os demais. Com a eliminação de um projeto, ficam gravados num histórico geral apenas a data de criação, eliminação, autor e o nome do supervisor que o eliminou, para fins de documentação.

7.2.4 Menu família

Este menu se comporta da mesma maneira que o Menu Projeto. Ao colocar-se o cursor sobre o seu botão, aparecerá um menu com os tópicos: Pesquisar, Listar, Incluir, Alterar, Excluir. Ao clicar-se em qualquer uma das opções, será aberta a tela selecionada.

7.2.4.1 Pesquisar

A tela pesquisar se comporta da mesma maneira que a pesquisar em projetos. Terá um campo para entrada de código ou nome de família e será retornado o(s) resultado(s).

7.2.4.2 Listar

A tela de listar funciona igual à tela listar de projetos (listando famílias, obviamente).

7.2.4.3 Incluir

A tela incluir traz a possibilidade de incluir famílias. Nela o supervisor especifica detalhadamente as características da nova família. Traz também o mecanismo apresentado (em incluir projetos) de divisão de tela pra pesquisa ou listagem (no modelo já mencionado), para que se possa fazer comparações entre características das famílias existentes e das que estão sendo criadas e justificar sua criação. Na criação da família é criado o projeto padrão da mesma, que servirá de base para a criação dos demais projetos desta família. Este projeto padrão, por ser especial e guia dos demais projetos da família, somente poderá ser criado por um supervisor. Então, têm-se uma visão geral da nova família ("preview") e, se estiver todo correto, será confirmado e armazenado na base. Cada família armazenada leva junto de si, automaticamente e obrigatoriamente, o nome do seu projetista.

7.2.4.4 Alterar

A tela de alteração de família traz as telas de características das famílias e as telas com os dados do projeto padrão, para ser editado. Somente podem ser alterados por supervisores, pois elas são a base vital do sistema industrial modelado em CAPP Variante. As famílias também têm um histórico de inclusão e alteração, assim como os projetos.

7.2.4.5 Excluir

A exclusão, igual a projetos, somente pode ser feita por supervisores. Também são guardadas as informações no histórico geral.

7.2.5 Menu operações

Existem as mesmas opções dos menus apresentados.

7.2.5.1 Pesquisar

A tela de pesquisar tem um campo para entrada de código ou nome de operação e será retornado o resultado.

7.2.5.2 Listar

A tela de listar funciona igual à tela listar de projetos (listando operações, obviamente).

7.2.5.3 Incluir

A tela de inclusão, figura 7.4, funciona da mesma maneira apresentada nas telas incluir. O responsável pela inclusão de operações entra com o preenchimento e detalhamento da operação, tal como precisão, fixação da peça, tipo de material da peça bruta, especificações de tamanho da peça bruta e da peça finalizada, tipo de material e geometria da ferramenta utilizada na operação, observações, etc. Ou seja, tudo que for necessário para a especificação completa de uma operação. Também há a divisão de tela para propiciar pesquisas para guiar corretamente a criação da nova operação, como foi citado nos outros processos de inclusão, e o "preview" antes de armazenar (anexando o nome do criador, data e hora).

**Figure:** Tela de inclusão de operações.
$\resizebox*{16cm}{10cm}{\includegraphics{fig/fig7_4.ps}}$

7.2.5.4 Alterar

A tela de alteração tem as mesmas características da de alteração de Projetos. Traz tudo o que foi colocado na especificação da operação para ser editado. Traz o diferencial de poder ser editadas por projetistas, e não somente por supervisores, devido às possíveis mudanças em especificações de operação. Igualmente a Projetos, tudo fica guardado em um histórico.

7.2.5.5 Excluir

A tela de exclusão também é igual a Projetos, com o mesmo requisito para exclusão para operações: ser supervisor.

7.2.6 Menu Ajuda

Este menu, ao ser acessado, traz as opções: Tópicos de Ajuda, Atualização e Sobre o e-capp. Ao escolher a primeira opção, abrir-se-á uma nova janela onde constam os tópicos do programa listados pra que o usuário escolha sobre o que quer saber. Também há a opção de pesquisa de tópicos; a atualização é feita da internet, quando disponível e serve para atualizar tanto o Ajuda como o programa um todo.

7.2.7 Menu Info de Usuário

Este menu pode ser clicado a qualquer momento para que seja apresentada a tela com informações do usuário, como login, nome, etc. são dados apenas de leitura para identificação. Caso algum dado esteja errado, há a necessidade de contato com o administrador. Nessa tela há a opção de mudança de senha, logout.

7.2.8 Menu Contato

Abre-se um menu onde há dois botões: Supervisor e Administrador. O botão supervisor abre uma tela com um editor de texto livre, onde o usuário poderá escrever uma mensagem que será enviada para o e-mail do supervisor do projeto (ou da área). Ao clicar-se no botão administrador, acontece a mesma coisa, mas o e-mail irá para o administrador do sistema.

7.2.9 Conclusão

Apresentou-se os detalhes de implementação de um sistema baseado na Web para gerenciamento de projetos industriais baseado em CAPP Variante. A mesma abordagem será utilizada no desenvolvido da base de dados para o trabalho de doutoramento utilizando as mesmas ferramentas computacionais. Outras ferramentas para gerenciamento de base de dados foram utilizadas, em especial o Msql, uma base de dados SQL que implementa um subset da linguagem SQL padronizada. Este sistemas é mais simples de usar, entretanto não dispoem da mesma robustez e dimensão do Mysql. A título ilustrativo pode-se acessar mais duas aplicações desenvolvidas para planejamento de processos baseadas na Web e que estão disponíveis na URL http://usinagem.graco.unb.br. O MySQL é a base de dados open-source mais utilizada no mundo Unix, possuindo conectividade total através de APIs para as linguagens de programação Java, C e C++, o que facilita em muito sua integração aos módulos do sistema integrado CAD/CAPP/CAM a ser desenvolvido.

Analisando o sistema desenvolvido pode-se citar os muitos benefícios que sua utilização traz, tais como: redução no tempo de planejamento (aumento na produtividade), agilidade nas revisões (facilidade em buscar histórico), padronização de processos (todos irão utilizar um único modelo), criação de uma única base (garantindo integridade das informações), aumento da qualidade dos processos (utilização de informações visuais, gráficos, etc.).

É um sistema que possui muitas funções que parecem complexas, mas revelam-se extremamente simples para o usuário final. Facilitam extremamente o ciclo de desenvolvimento de produto, desde o processo de criação de projetos, famílias e operações, de gerenciamento e de composição de histórico de projeto.

O sistema permite o acesso remoto, não necessitando que o projetista esteja fisicamente no local da indústria para que se possa criar, corrigir ou alterar algum projeto, economizando tempo e, em casos extremos, até a própria alocação do funcionário no ambiente industrial.

Os menus padronizados e auto-explicativos, facilitam muito a utilização do sistema, que traz uma curva de aprendizagem extremamente altatypeset@protect @@footnote SF@gobble@opt Baseado em testes realizados pelos criadores do programa com pessoas com e sem conhecimentos do ambiente de desenvolvimentos de projetos industriais. . Sendo assim, a qualidade dos planos de processo e de operações são mais consistentes, pois dependem menos do conhecimento do processista/projetista.

O sistema pode ser acessado pelo endereço http://WebCAPP.graco.unb.br.

7.3 Tabelas de Decisão

Tabelas de decisão podem ser facilmente implementadas num computador. Entretanto, quando sistemas de CAPP as usam é necessário um programa de pré-processamento para implementar a tabela e controlar a operação da tabela. Tal software é chamado de linguagem de tabela de decisão. Este software consiste de uma tabela de decisão e um programa externo.

A tabela de decisão é representada no seu formato original, podendo trabalhar com uma tabela de decisão a partir da representação através de árvore de decisão e vice-versa. A figura 7.5 apresenta uma representação através de árvore de decisão e tabela de decisão.

**Figure:** Representação através de árvore de decisão e tabela de decisão para o mesmo problema.
$\resizebox*{16cm}{18cm}{\includegraphics{fig/figura7.2.ps}}$

O programa externo é utilizado para controlar a tabela de decisão. Chamando este exemplo de DCTABLE, uma sub-rotina (TAB(N)) avalia a tabela N. Durante ou após a análise da tabela, um TAB(N $_{1}$ ) pode ser adicionado à tabela N, que significa que várias tabelas podem ser conectadas. Para a consulta à tabela para seleção de um processo ou operação de usinagem pode-se utilizar como dados de entrada a forma, diâmetro, tolerância de posição e tolerância dimensional.

Uma outra forma de implementar um processo de lógica de decisão baseado na abordagem de tabela de decisão é utilizar a tecnologia de base de dados relacionais. Existem diversos sistema de gerenciamento de bases de dados relacional gratuitos e que podem ser usados para esta finalidade como o MSQL e o MySQL (ftp://custom.lab.unb.br/pub/database), tanto para plataforma Unix como Windows, como apresentado na seção anterior.

7.4 Inteligência Artificial

Ferramentas emergentes de Inteligência Artificial (AI) como redes neurais, lógica difusa, algoritmos genéticos, sistemas especialistas, etc, oferecem novas oportunidades e abordagens para resólver complexos problemas associados a elaboração automática de planos de processo (DÉPINCÉ, AMARA e HASCOËT, 1999). A maioria dos métodos utilizados na pesquisas de CAPP são baseados em lógica difusa ou um mix de métodos usando redes neurais, lógica difusa e sistemas especialistas. Algumas aplicações de algoritmos genéticos podem ser achadas. Atualmente as técnica de AI são usadas em funções específicas como seleção de ferramentas de corte, seqüenciamento das operações, reconhecimento de padrões, etc.

O uso de técnicas de AI em planejamento do processo tem destacado a necessidade de se ter a ferramenta certa aplicada no domínio do problema. Algumas técnicas como algoritmos genéticos ou lógica difusa podem tratar com planos de processos contendo alternativas gerando planos de processo não lineares. Os próximo desenvolvimento de sistema de CAPP é a integração de técnicas de AI dentro do campo de inteligência artificial distribuído, como em um arquitetura computacional baseada em Agentes (DÉPINCÉ, AMARA e HASCOËT, 1999). Neste caso as atividades são distribuídas através de múltiplos resolvedores de problemas especializados, ou seja o Agente.

HASHMI et al. (1998) desenvolveu uma aplicação para seleção das condições de usinagem utilizando-se da abordagem baseada em lógica difusa. No modelo fuzzy desenvolvido dados de materiais (dureza) são os dados de entrada e a velocidade de corte é a variável de saída. Um conjunto fuzzy para a variável fuzzy de entrada (Dureza) e para a variável fuzzy de saída (Velocidade) são utilizados, consistindo de dados de três diferentes profundidades de corte, quatro tipos de ferramentas e dois tipos de materiais com durezas distintas e as faixas de velocidade de corte recomendadas para cada material.

À variável fuzzy Dureza é associado ao seguinte conjunto fuzzy: muito mole, mole, médio, médio superior, duro e muito duro.

A variável fuzzy Velocidade é associado ao conjunto fuzzy: muito baixa, baixa, média baixa, média alta, alta e muito alta.

A regras no total de seis são estabelecidas, como: ``Se dureza do material é muito mole, então a velocidade é muito alta''.

Um forma triangular foi empregada para descrever o conjunto fuzzy. HASHMI et al. (1998) conclui o estudo indicando que existe uma boa correlação entre os dados utilizados de velocidade de corte recomendados pelo Machining Data Handbook e os valores de velocidade previstos pelo modelo em fuzzy logic.

Desde 1995, uma nova abordagem tem despontado no planejamento do processo: inteligência artificial distribuída (DAI). O uso de sistemas distribuídos tem mostrado que a inteligência distribuída melhora a eficiência do processo de decisão. Em sistemas distribuídos, também chamados de sistemas cooperativos, o problema original é decomposto em sub-problemas e cada sub-sistema especialista é responsável por uma tarefa específica. Em um único sistema, diferentes fontes de conhecimento coexistem e DAI permite o gerenciamento evitando os conflitos devido às várias formas de representação de conhecimento utilizadas. No final as soluções parciais criadas pelos sub-sistemas são colocadas juntas, de forma ordenada, para obter uma solução global. As características de um sistema cooperativo são:

tem boa capacidade de adaptação;
é modular;
é flexível;
é rápido devido ao processamento paralelo dos sub-sistemas;
permite que múltiplas abordagens heterogêneas trabalhem juntas;
pode colecionar conhecimento.

Diferentes aplicações baseadas em sistemas cooperativos podem ser achados na literatura sob variados nomes: sistemas multi-agentes (MAS), sistemas baseados em quadonegro (black-board), resolvedores de problemas cooperativos e distribuídos, entre outros.

Outra vantagem de técnicas de DAI é a possibilidade de integrar o usuário na malha de decisão: de maneira a controlar e disparar os subsistemas especialistas por meio de três maneiras: orientado ao usuário, orientado pelo cenário e disparo automatizado.

7.4.1 Abordagem através de sistemas multi-agentes (MAS)

Em DÉPINCÉ et al. (1999) é apresentado uma arquitetura para CAPP generativo baseada na representação multi-agentes. MAS distribui as atividades de planejamento do processo para múltiplos agentes especializados e coordena-os de maneira a obter a solução global. O uso de MAS tem mostrado que a inteligência distribuída melhora a eficiência do processo de decisão, sendo que cada agente tem tem seu próprio conhecimento e é responsável por uma tarefa específica. Um agente é uma entidade que pode atuar em um ambiente, comunicar-se com outros agentes e cujo o comportamento é resultado de suas observações, conhecimento e interação com outros agentes. Um agente pode ser usado para o modelo de dados (máquinas, ferramentas, dispositivos, etc), como um supervisor, funções matemáticas ou um humano.

A arquitetura proposta é composta por três módulos:

Modulo supervisor: permite a troca de informações entre os agentes e contêm as informações sobre o planejamento do processo e critérios usados durante o processo de otimização de um plano de processos.
Interface humana: permite que o usuário interaja com o sistema. Mostra os estágios de progresso do planejamento do processo em execução. O usuário pode questionar e revisar as informações geradas pelos agentes e compartilhadas com o módulo supervisor.
Modulo de agentes: representa o conjunto de agentes, onde cada agente esta associado com uma aplicação que executa uma tarefa específica da elaboração de um plano de processo. Suas atividades são programadas pelo módulo supervisor ou pelo usuário do sistema. Os agentes são associados à:

seleção dos processos de usinagem tendo como entrada as features de projeto disponíveis em uma base de dados (biblioteca de features); e as restrições são associadas as dimensões, tolerâncias, material da peça, entre outras.
seleção de máquinas-ferramenta tendo como entrada os processos de usinagem; e as restrições são a geometria da máquina, potência da máquina, capacidade da máquina, dimensões da peça, entre outros.
seleção da ferramenta de corte tendo como entrada as máquinas-ferramenta; e as restrições são o tipo de material do par peça/ferramenta, dimensões e geometria das ferramentas, vida da ferramenta, entre outras.
condições de corte tendo como entrada os parâmetros das ferramentas e material; e as restrições são os critérios utilizados como vida de ferramenta, econômicos, potência da máquina, entre outros.
trajetória da ferramenta tendo como entrada o modelo do produto baseado em features; e as restrições baseada nas próprias features e eixos das ferramentas para evitar colisões.

7.4.2 Sistemas especialistas

O planejamento dos processos de fabricação tem uma característica bastante peculiar: não existe um algoritmo predefinido para a geração dos planos de processo. Assim, se faz necessária a utilização de uma metodologia de programação especialmente voltada para a solução de problemas desta natureza. A tecnologia de sistemas especialistas se apresenta como uma alternativa bastante atrativa.

A utilização de sistemas especialistas de forma comercial é bastante recente (teve seu começo na década de 80), mas, de acordo com WATERMAN (1986), pesquisas são desenvolvidas desde a década de 60. Os sistemas especialistas constituem um ramo importante da inteligência artificial. Nos tópicos que seguem apresenta-se uma introdução à teoria de sistemas especialistas.

7.4.2.1 O que são sistemas especialistas

De acordo com a definição apresentada em GIARRATANO e RILEY (1994) sistemas especialistas são programas de computador que se utilizam de conhecimento e procedimentos de inferência para resolver problemas bastante complexos que necessitam, para a sua solução, de um conhecimento bastante específico.

Neste sentido, pode-se dizer que sistemas especialistas são softwares que procuram imitar a forma de raciocínio de um especialista no assunto, para a solução de um determinado problema.

Pelo fato dos sistemas especialistas se utilizarem de uma base de conhecimento para a solução de problemas, os termos sistemas baseados no conhecimento e sistemas especialistas baseados no conhecimento são muitas vezes utilizados como sinônimos de sistemas especialistas, embora não restrinjam o conhecimento utilizado ao obtido de um especialista no assunto. Assim, o termo sistema especialista é utilizado, atualmente, para se referir aos sistemas baseados em conhecimento, mesmo que este tenha sido obtido a partir de livros e revistas que lidam com o assunto em questão.

Como apresentado em WATERMAN (1986), os sistemas especialistas são constituídos por duas partes distintas, quais sejam:

uma base de conhecimento;
um motor de inferência.

A base de conhecimento, por sua vez, é dividida em duas partes:

dinâmica: é a base de dados (fatos) sobre a qual o sistema trabalha;
estática: é o conhecimento que o sistema tem a respeito das relações entre os fatos;

O motor de inferência também é dividido em duas partes básicas, quais sejam:

interpretador: promove a ligação das partes estática e dinâmica da base de conhecimento;
controlador: rege o funcionamento do interpretador, no sentido de controlar a ordem em que este estabelece as ligações da base de conhecimento.

7.4.2.2 Formas de representar o conhecimento

Diferentes formas podem ser utilizadas para representar uma base de conhecimento. A seguir, apresenta-se a forma mais comum de representar as partes estática e dinâmica de uma base de conhecimento:

conhecimento dinâmico: é geralmente representado por fatos do tipo: A peça tem um furo.
conhecimento estático: a forma mais difundida de se representar o conhecimento estático, em um sistema especialista, é através de regras do tipo IF THEN. Uma possível regra seria:

7.4.2.2.1 $\Rightarrow$ Se

7.4.2.2.1.1 ``A peça tem um furo''

7.4.2.2.2 $\Rightarrow$ Então

7.4.2.2.2.1 ``Deve haver uma operação de furação''.

O novo fato ``Deve haver uma operação de furação'' é gerado, pela regra acima, quando o fato ``A peça tem um furo'' estiver presente na base de fatos. Aos fatos que servem de base para o disparo de uma dada regra dá-se o nome de premissa da regra, aos que são gerados quando a regra é executada dá-se o nome de conclusão da regra.

Uma forma mais recente e bastante eficiente, apresentada por GIARRATANO e RILEY (1994), de se representar o conhecimento é a utilização de classes para modelar um sistema. Neste tipo de representação, os fatos são substituídos pelos atributos dos objetos de cada classe. As regras (conhecimento dinâmico) passam então a atuar sobre os atributos dos objetos. O novo modelo seria assim representado:

7.4.2.2.3 Classe: Furo

Diâmetro:
Profundidade:
Operações:

Um possível objeto pertencente à classe furo teria os atributos:

Diâmetro: 10 mm
Profundidade: 50 mm
Operações: vazio.

Como exemplo de uma regra que atuaria sobre este objeto, tem-se:

$\Rightarrow$ Se

existe um objeto da classe furo com:

Diâmetro = D

Profundidade = P

$\Rightarrow$ Então

associe ao atributo Operações deste objeto uma operação de Furar com Diâmetro = D e Profundidade = P.

7.4.2.2.4 O objeto passaria a ter então, os seguintes valores:

Diâmetro: 10 mm
Profundidade: 50 mm
Operações: Furar, Diâmetro = 10 mm, Profundidade = 50 mm.

7.4.2.3 Como funciona um sistema especialista

O funcionamento de um sistema especialista depende da forma como é utilizado. Pode-se utilizar um sistema especialista como um sistema simulador ou como um sistema que analisa a veracidade de hipóteses.

Quando utilizado como um simulador tem-se o que se chama de encadeamento para frente (forward chaining). Quando utilizado para analisar a veracidade de hipóteses tem-se o que se chama de encadeamento para trás (backward chaining).

7.4.2.3.1 Um sistema especialista realizando encadeamento para frente

O encadeamento para frente é adequado para determinar quais são as conseqüências de um dado fato ocorrido em um dado sistema.

Seu funcionamento pode ser descrito com base nas relações existentes entre os elementos que o constituem. O interpretador fica continuamente monitorando a base de fatos e a base de regras com o objetivo de construir uma lista (agenda) das regras que têm suas premissas satisfeitas pelos fatos já existentes. Uma regra que seja colocada no topo da agenda será a primeira a ser executada. A ordem em que as regras são colocadas na agenda e a sua execução são ditadas pela estratégia adotada pelo controlador.

Dentre as estratégias comumente utilizadas por um controlador pode-se citar: execução em largura e em profundidade.

Suponhamos que duas regras R1 e R2 tenham suas premissas satisfeitas por um fato A, presente na base de fatos. Estas regras são então colocadas na agenda. A execução da regra R1 leva à criação do fato B, que satisfaz à regras R3 e R4. Estas regras (R3 e R4) são agora colocadas na agenda. Se R3 e R4 são colocadas acima de R2, então tem-se uma execução em profundidade. Se R3 e R4 são colocadas depois de R2, então tem-se uma execução em largura.

7.4.2.3.2 Um sistema especialista realizando encadeamento para trás

O encadeamento para trás é adequado para determinar quais são as causas que levaram a um dado fato, em um dado sistema, ou simplesmente para verificar se uma determinada hipótese se sustenta, com base nos fatos já conhecidos.

Neste caso as relações entre os elementos que constituem o sistema especialista são diferentes daquelas presentes no encadeamento para frente. O interpretador recebe um fato (uma hipótese que deve ser provada) e verifica se este já existe na base de fatos. Se sim, então a hipótese é imediatamente provada. Se não, então o interpretador verifica na base de regras quais as regras que têm como conclusão aquele fato. Os fatos que estão nas premissas dessas regras passam então, a ser hipóteses intermediárias que devem ser provadas. O processo se encerra quando um fato presente na base de fatos dá suporte ao raciocínio desenvolvido, ou quando não há mais caminhos para tentar provar a hipótese.

Por exemplo, deseja-se verificar se a hipótese H0 pode ser provada com base nos fatos já existentes (fig. 7.6). De acordo com a base de regras, se um dos fatos H1, H2 ou H3 for verdade então H0 será provada. Procura-se então provar pelo menos uma das hipóteses intermediárias H1, H2 ou H3.

Para que H1 seja provada é necessário que o fato A exista, o que, neste caso não acontece. Então este caminho não prova a hipótese inicial (H0).

Para que H2 seja provada é necessário que as duas hipóteses intermediárias (H4 e H5) sejam simultaneamente provadas. Para que H4 seja provada é necessário que exista o fato B, o que realmente acontece, e portanto H4 é verdade. Mas ainda resta provar H5, que depende da existência dos fatos C e D. Embora exista o fato D, o fato C não está presente e portanto H5 não pode ser provada. Assim H2 também não pode ser provada e novamente tem-se um caminho que não prova a hipótese inicial (H0).

Resta então tentar provar H3. Para que H3 seja provada é necessário que a nova hipótese intermediária H6 seja provada. Para que H6 seja provada é necessário que existam simultaneamente dois fatos: D e E. Os fatos D e E estão presentes na base de fatos e conseqüentemente H6 é verdade. Sendo H6 uma verdade, H3 também o é, e segue-se que a hipótese inicial (H0) é verdadeira.

**Figure:** Sistema especialista realizando encadeamento para trás para provar uma hipótese (H0).
$\resizebox*{10cm}{10cm}{\includegraphics{fig/figura7.3.ps}}$

7.4.2.4 Campo de aplicação de sistemas especialistas

Sistemas especialistas são indicados para resolver problemas que não tenham solução algorítmica, quando se consegue expressar o conhecimento sobre o sistema através de regras. Sendo assim, os sistemas especialistas se diferem dos sistemas convencionais em um ponto básico: o controle sobre o fluxo de execução. Os sistemas convencionais apresentam uma programação procedural, onde a seqüência de execução é um aspecto importante que deve ser previamente definido. Já nos sistemas especialistas não há uma preocupação, por parte do construtor do sistema, com a seqüência de execução, pois esta é indiretamente definida através das regras e dos fatos presentes no sistema.

Os sistemas especialistas são dependentes de uma base de conhecimento criada a partir das regras. A criação de bases de conhecimento para um domínio amplo hoje ainda não é uma realidade, devido às dificuldades encontradas em se aglomerar e manipular diferentes áreas de conhecimento. O caminho mais utilizado, atualmente, é a construção de bases de conhecimento para um domínio bastante restrito.

Desta forma, o campo de aplicação dos sistemas especialistas passa a ser o dos sistemas com domínios reduzidos sobre os quais se pode expressar o conhecimento na forma de regras, quando um algoritmo não é adequado ou simplesmente não existe para a solução do problema.

7.4.2.5 Vantagens da utilização de sistemas especialistas

Os sistemas especialistas apresentam uma série de características positivas, dentre as quais pode-se citar:

disponibilidade: uma vez construído, o sistema estará disponível em qualquer computador que seja adequado à sua execução;
custo reduzido: o custo de desenvolvimento quando dividido pelo total de usuários pode ser bastante atrativo;
permanência: ao contrário de especialistas humanos, um sistema especialista não morre e portanto o seu conhecimento é permanente;
regularidade: o funcionamento de um sistema especialista não será afetado pelo cansaço nem por problemas emocionais. Assim, numa situação de emergência, onde várias horas de trabalho sejam necessárias e decisões importantes estejam envolvidas, a utilização de um sistema especialista pode ser bastante interessante;
descrição da linha de raciocínio: a conclusão a que um sistema especialista chega pode ser explicada através da linha de raciocínio desenvolvida, o que aumenta a confiabilidade da decisão tomada.

Apesar de tantas características positivas, os sistemas especialistas são incapazes de absorver o senso comum, pois este não pode ser descrito em termos de regras. Desta forma, a utilização de um sistema especialista é bastante vantajosa quando se pensa no seu uso em conjunto com um especialista no assunto. O sistema especialista trabalha então, no sentido de fazer sugestões que podem ser ou não aceitas por um humano.

7.4.2.6 Representação do conhecimento

O conhecimento em ES deve ser representado num computador numa forma implementável. A representação do conhecimento é uma combinação de estruturas de dados e rotinas interpretativas. Esquemas de representação são classificados em declarativos e procedurais (WANG e LI, 1991).

7.4.2.6.1 Conhecimento Declarativo

Cálculo Predicativo: a descrição do mundo é dada neste esquema em termos de sentenças lógicas. Por exemplo, o fato de que ``todos os furos são cegos'' é representado por: $\nabla$ X (furo_cego (X) $\Rightarrow$ furo (X)).
Redes Semânticas: foram desenvolvidas como um modelo psicológico explícito para a memória associativa humana, descrevendo o mundo em termos de objetos (nós) e relações (arestas rotuladas). O conhecimento é uma coleção de objetos e associações são representadas como um grafo rotulado direcionado.
Frames: é uma estrutura de dados utilizada para representar uma situação convencional. Atrelada a cada frame existem vários tipos de informação: como usar a frame, o que deve-se esperar que ocorrerá depois, o que fazer se estas expectativas forem confirmadas, etc.

7.4.2.6.2 Conhecimento Procedural

Regras de Produção: foram desenvolvidas para modelagem do conhecimento humano, elas têm se tornado cada vez mais populares em grandes programas. A idéia básica destes sistemas é que a base de dados consiste de regras, na forma de pares condição-açãotypeset@protect @@footnote SF@gobble@opt IF <antecedente> THEN <conseqüente>, ou
WHEN <premissa> BEGIN <ação>. . É a forma de representação conhecimento utilizada em ES, como descrito anteriormente.

7.4.3 Sistemas Especialistas em Ambiente Web

Ferramentas de SE como CLIPS, FUZZYCLIPS podem ser encontradas em: ftp://omega.enm.unb.br/pub/doutorado/ disco2/www.ghg.net/clips. A mesma ferramenta foi portada para Java sendo denominada Jess , ftp://omega.enm.unb.br/pub/doutorado/ disco2/herzberg.ca.sandia.gov/jess/sourcedist.

Em http://herzberg.ca.sandia.gov/jess/demo.html pode-se executar um applet java de um sistema especialista denominado ``Sticks Game''.

Outra aplicação utilizando FuzzyClips e Jess usando a abordagem java applet pode ser acessada na URL http://ai.iit.nrc.ca/IR_public/fuzzy/fuzzyShower.html, onde um applet controla a temperatura d'água de um chuveiro utilizando regras de produção associado à lógica fuzzy.

Pode-se utilizar Jess, no lado do servidor, através de Servlets. Existem outras APIs desenvolvidas para Jess que podem ser acrescentadas ao sistema aumentando a sua funcionalidade. Maiores informações estão disponíveis em http://herzberg.ca.sandia.gov/jess/.

7.5 Multi-agentes

7.5.1 Agentes de Software

Agentes são metáforas computacionais para um tipo de componente de software que em seu funcionamento pretende imitar o comportamento de seres humanos no tocante a diversas ca-racterísticas, particularmente no que se refere a um comportamento independente e inteligente. Apesar dessa idéia geral, diversas definições de agentes podem ser encontradas na literatura. WOOLDRIDGE e JENNINGS (Wooldrige, 1995) apresentam duas propostas de definição de agentes, no que chamam de noção forte e noção fraca, dependendo do grau de "realismo" com que se pretende entender a metáfora de agente.

7.5.1.1 Uma noção fraca para agentes.

Segundo WOOLDRIDGE e JENNINGS (Wooldridge, 1995), uma noção fraca do termo agente é aquela que o utiliza para denotar qualquer hardware ou sistema de computação baseado em software, que apresente as seguintes propriedades:

autonomia: os agentes operam sem a intervenção direta dos humanos ou outros agentes, além de ter algum tipo de controle de suas ações e estados internos;
habilidade social: os agentes interagem com outros agentes (e possivelmente com humanos) através de algum tipo de linguagem de comunicação de agentes (ACL);
reatividade: os agentes percebem seu ambiente, o qual pode ser o mundo real, um usuário via uma interface gráfica de usuário (GUI), uma coleção de outros agentes, a INTERNET, ou talvez a combinação de alguns destes ou de todos respondendo de forma oportuna às mudanças que ocorrem neste ambiente;
pró-atividade (pro-activeness): os agentes não simplesmente reagem em resposta ao ambiente, mas têm a capacidade de exibir condutas baseadas em metas, tomando a iniciativa em relação a suas próprias ações.

7.5.1.2 Uma noção forte para agentes

Para alguns pesquisadores, particularmente aqueles que trabalham na área da Inteligência Artificial, o termo agente deve ter um significado mais específico que o adotado pela noção fraca. Em sentido geral, estes pesquisadores descrevem um agente como um sistema de computação que, além de apresentar as propriedades identificadas na noção fraca, deve ser definido ou implementado utilizando-se conceitos que usualmente são aplicáveis aos seres humanos. Por exemplo, é bastante comum na Inteligência Artificial caracterizar os agentes usando noções aplicáveis à mente humana, tais como conhecimentos, crenças, intenções e obrigações.

Em algumas ocasiões, outros atributos são discutidos no contexto de agentes. Como exemplo, temos:

mobilidade: é a habilidade de um agente para se transportar entre máquinas participantes de uma rede de computadores;
veracidade: é a suposição que um agente não comunicará informações falsas de maneira intencional;
benevolência: é a suposição de que os agentes não têm objetivos contraditórios, e que todo agente tentará sempre responder ao que lhe é perguntado;
racionalidade: é a suposição de que o agente sempre agirá para alcançar suas metas, e nunca agirá contra seus objetivos, pelo menos na medida em que suas crenças o permitam.

Outros pesquisadores da área, tem desenvolvido definições interessantes para o termo "agente", muitas delas até conflitantes. Dentre outras podemos citar as seguintes:

Russel e Norvig: "Um agente é qualquer coisa que possa perceber um ambiente por meio de sensores e atuar no mesmo por meio de atuadores" (RUSSEL, 1995).
Barbara Hayes e Roth - Stanford: "Agentes inteligentes realizam continuamente três funções: percepção das condições dinâmicas de um ambiente, ação de modo a afetar condições do ambiente e raciocínio para interpretar percepções, realizar inferências e determinar ações" (FRANKLIN, 1996).
Pattie Maes - MIT Media Lab: "Agentes autônomos são sistemas computacionais que habitam um ambiente complexo e dinâmico, sensoreiam e atuam autonomamente neste ambiente, realizando desta maneira uma série de metas e tarefas para as quais foram projetados" (FRANKLIN, 1996).
IBM's Intelligent Agent Strategy: "Agentes inteligentes são entidades de software que realizam um conjunto de operações em nome de um usuário ou outro programa com certo grau de independência ou autonomia, e desta maneira empregam algum conhecimento ou representação das metas e/ou desejos do usuário" (FRANKLIN, 1996).
Stan Franklin e Art Graesser: "Um agente autônomo é um sistema que é parte de um ambiente, estando situado dentro dele, e sente e age sobre este ambiente, no tempo, de acordo com seus próprios propósitos, de modo a alterar o que sentirá no futuro" (FRANKLIN, 1996).

Destas definições, a definição ``4'' (IBM) é a que melhor se ajusta ao trabalho de doutorado. O conjunto de operações está associado as atividades a serem executadas pelo planejamento de processo; o usuário é o cliente remoto; o conhecimento está associado à regras de produção e/ou lógica fuzzy, por exemplo, modelando a tomada de decisão do processista.

7.5.2 Arquitetura de agentes

Um tópico importante relacionado à tecnologia de agentes diz respeito às diferentes arquiteturas que podem ser idealizadas para a implementação de agentes. Entende-se por uma arquitetura de agentes como o conjunto de especificações e técnicas utilizadas para a definição funcional dos agentes. Nesta seção, descreveremos alguns dos conceitos relacionados a arquiteturas de agentes. Primeiramente daremos duas definições extraídas do trabalho de WOOLDRIDGE e JENNINGS (WOOLDRIDGE, 1995).

Maes define uma arquitetura de agentes como: "Uma metodologia particular para a construção de agentes. Especifica como os agentes podem ser decompostos na construção de um conjunto de módulos (componentes) e como estes módulos podem interagir entre si. O conjunto total de módulos e suas interações deve especificar como os dados dos sensores e o estado interno do agente serão utilizados para determinar as ações realizadas pelo agente... e seu futuro estado interno. Uma arquitetura envolve técnicas e algoritmos que suportem esta metodologia."

Kaelbling considera uma arquitetura de agentes como: "Uma coleção específica de módulos de software (ou hardware), tipicamente designados por caixas com setas que indicam os dados e o fluxo de controle entre os módulos.

7.5.2.1 Enfoques clássico: Arquiteturas deliberativas

Pode-se definir um agente deliberativo ou arquitetura deliberativa de agente, como um agente que contenha uma representação explícita de um modelo simbólico do mundo. Neste, as decisões (por exemplo, as ações a serem executadas) são determinadas através de um raciocínio lógico (ou pelo menos pseudo-lógico), baseado em padrões de "matching" e manipulação simbólica. A idéia de agentes deliberativos baseados puramente em um raciocínio lógico é extremamente tentadora. Para fazer com que o agente esteja de acordo com alguma teoria de agentes, poderíamos ingenuamente supor que é suficiente dar-lhe uma representação lógica desta teoria e fazer com que o agente realize alguma prova de teorema. Se tratarmos de construir um agente por esta via, teríamos pelo menos dois problemas importantes a serem resolvidos:

Problema de tradução (the transduction problem): como traduzir o mundo real em uma descrição simbólica exata e adequada, que por sua vez, possa ser útil.
Problema de representação e/ou raciocínio (the representation/reasoning problem): como armazenar estruturas lógicas que correspondam a uma representação simbólica de processos e entidades complexas do mundo e como fazer com que os agentes realizem algum raciocínio sobre estas estruturas, obtendo resultados que possam ser úteis.

Apesar do imenso volume de trabalhos que estes problemas tem gerado, muitos pesquisadores aceitam a hipótese de estarmos ainda longe de vermos estes problemas resolvidos, lembrando que a lógica de primeira ordem não é nem sequer decidível e extensões modais a ela (incluindo re-presentações de crenças, desejos, tempo e outras) tendem a ser altamente não-decidíveis. Talvez o mais problemático para a Inteligência Artificial Simbólica é que muitos dos algoritmos de interesse para a manipulação simbólica são intratáveis (parece difícil construir algoritmos úteis de mani-pulação simbólica que tenham a garantia de terminar em um limite de tempo fixo aceitável e com resultados úteis). Um exemplo da abordagem clássica são os agentes planejadores.

7.5.2.2 Agentes Planejadores

Desde o início dos anos 70, os adeptos da abordagem "planning" dentro da Inteligência Artificial estiveram estreitamente preocupados com o design de agentes artificiais. De fato, parece razoável dizer que a maioria das inovações no design de agentes vem desta comunidade. Determinar planos é essencialmente uma tarefa de programação automática: verificar se uma ação (ou conjunto de ações), quando executada(s), vai resultar na obtenção de algum objetivo desejado. Dentro da comunidade da Inteligência Artificial Simbólica, existe a predisposição em aceitar que qualquer agente artificial deve possuir algum tipo de sistema de planejamento como componente central. Talvez o mais conhecido sistema planejador seja o STRIPS.

Este sistema assume uma descrição simbólica do mundo, do objetivo desejado, e um conjunto de ações, caracterizadas por suas pré-condições e pós-condições associadas. O STRIPS tenta encontrar uma seqüência de ações que possa levar ao sucesso de alguma meta, usando uma análise simples de verificação de sucesso (simple means-ends analysis). Esta análise envolve essencialmente um matching das pós-condições das ações com o objetivo desejado. O algoritmo de planejamento STRIPS era muito simples e teve sua ineficiência comprovada para problemas com complexidade moderada. Outras técnicas foram desenvolvidas para melhorar este algoritmo, tais como os planejadores não lineares e os planejadores hierárquicos. Porém em meados dos anos 80, alguns resultados teóricos mostravam que essas técnicas de refinamento poderiam não ser úteis em qualquer sistema de tempo restrito. Apesar destas dificuldades, várias tentativas têm sido realizadas para construir agentes nos quais o componente primário é um algoritmo planejador. Os resultados obtidos nesta área tiveram uma profunda influência sobre as pesquisas posteriores feitas sobre os algoritmos planejadores. Talvez mais do que qualquer outra coisa, os fracassos obtidos tenham levado alguns dos pesquisadores a questionarem, em sua totalidade, o paradigma da Inteligência Artificial Simbólica, e por conseguinte conduzido-os a trabalhar com enfoques alternativos que serão apresentados a seguir.

7.5.2.3 Enfoques alternativos: Arquiteturas reativas

A rejeição e o questionamento da viabilidade do paradigma da Inteligência Artificial Simbólica conduziu ao que geralmente é conhecido como sendo as arquiteturas reativas. Estas não incluem nenhum tipo de modelo simbólico central do mundo e não utilizam raciocínio simbólico complexo.

7.5.2.4 Linguagens de Comportamento

WOLDRIDGE e JENNINGS (WOOLDRIDGE, 1995) consideram Rodney Brooks, pesquisador do MIT, como um dos principais críticos da noção de agência da Inteligência Artificial Simbólica, motivado pelas deficiências dos enfoques da Inteligência Artificial para cons-truir mecanismos de controle para robôs móveis autônomos. BROOKS (1986) resumiu uma arquitetura alternativa para cons-truir agentes, chamada de arquitetura da suposição (subsumption architecture). Ele propôs em trabalhos posteriores (BROOKS, 1990, 1991a e 1991b) três teses chaves:

Comportamento inteligente pode ser gerado sem as representações explícitas do tipo que a Inteligência Artificial propõe;
Comportamento inteligente pode ser gerado sem um raciocínio abstrato e explícito do tipo que a Inteligência Artificial propõe;
Inteligência é uma propriedade emergente de certos sistemas complexos;

Brooks também identificou duas idéias básicas que tiveram influência em suas pesquisas:

situatedness e embodiment: inteligência "real" está localizada no mundo e não em sistemas incorpóreos tais como provadores de teoremas ou sistemas especialistas.
Inteligência e emergência: comportamento "inteligente" surge como resultado de uma intera-ção de um agente com seu ambiente. Também, a inteligência está no olho do observador e não é uma propriedade isolada nem inata.

Outros trabalhos foram desenvolvidos para explorar alternativas para o paradigma da Inteligência Artificial planejadora. Entre eles podemos citar os seguintes:

Sistema PENGI: Jogo de computador desenvolvido por Agre & Chapman. Agre tinha observado que a maioria das atividades diárias são uma "rotina", ou seja, envolvem somente pequenas adaptações sobre atividades que já são conhecidas. Novas tarefas, uma vez aprendidas, podem ser incorporadas como novas rotinas, passando a incorporar o conjunto de atividades conhecidas. Agre propôs que uma arquitetura de agente eficiente pode ser baseada nos "argumentos de funcionamento". Em resumo, a idéia é que a maioria das decisões são rotinas, as quais podem ser codificadas em uma estrutura de baixo nível (tais como um circuito digital), que somente necessitará ser atualizada periodicamente, por exemplo para resolver novos tipos de problemas (AGRE, 1987).
Arquitetura de Rede de Agente: Pattie Maes desenvolveu uma arquitetura de agentes na qual um agente é definido como um conjunto de módulos que competem entre si (MAES, 1991). Estes módulos tem uma pequena semelhança com a arquitetura de suposição de Brooks. Cada módulo é especificado pelo projetista, em termos de suas pré e pós-condições e um nível de ativação, o qual oferece um valor real que indica a relevância de um módulo em uma situação particular. Quanto maior for o nível de ativação de um módulo, mais provável é a sua influência na conduta do agente. Uma vez especificado, o conjunto de módulos que competem são compilados dentro de uma rede de ativação distribuída (spreading activation network), onde os módulos são conectados uns aos outros segundo suas pré e pós-condições. Quando um agente está executando alguma tarefa, diferentes módulos podem ser mais ativos que outros, em determinadas situações, o que permite que estes possam ser executados. O resultado dessa execução pode ser um comando para uma unidade atuadora ou um incremento no nível de ativação de outro módulo conectado a eletypeset@protect @@footnote SF@gobble@opt Nossa definição para redes de agentes não encontra qualquer relação com a rede de agentes de Pattie Maes. .

7.5.2.5 Arquiteturas Híbridas

Muitos pesquisadores sugeriram que nem um enfoque completamente deliberativo, nem um completamente reativo é apropriado para a construção de agentes. Discute-se então, o caso dos sistemas híbridos, abordagem que associa ambos enfoques.

Um enfoque óbvio é construir um agente com dois (ou mais) sub-sistemas, um deles deliberativo (que contenha um modelo simbólico do mundo, desenvolva planos e tome decisões) e outro reativo (que seja capaz de reagir aos eventos que ocorrem no ambiente sem envolver raciocínios complexos).

Com freqüência o componente reativo é colocado com algum tipo de precedência sobre o componente deliberativo. Desta forma, ele pode oferecer uma resposta rápida a eventos importantes do ambiente. Este tipo de estrutura leva naturalmente à idéia de uma arquitetura em camadas. Nesta arquitetura, os sub-sistemas de controle de agentes são organizados dentro de uma hierarquia, na qual as camadas mais altas lidam com as informações em níveis crescentes de abstração. Assim, por exemplo, as camadas mais baixas poderiam mapear diretamente os dados dos sensores para as saídas dos atuadores sem nenhum tratamento prévio, enquanto as camadas superiores fazem o tratamento das tarefas de longo prazo. O principal problema nesta arquitetura é que o tipo de estrutura de controle deverá ser embutida nos sub-sistemas de agentes para manipular as interações entre as diferentes camadas.

Dois bons exemplos desta arquitetura são as máquinas de Touring desenvolvidas por Ferguson e descritas por WOOLDRIDGE e JENNINGS (WOOLDRIDGE. 1995) e InteRRaP, figura 7.7, (BRENNER, 1998). Outro exemplo das arquiteturas híbridas é o Procedural Reasoning System (PRS).

**Figure:** Arquitetura híbrida InteRRaP.
$\resizebox*{16cm}{10cm}{\includegraphics{fig/fig7_5.ps}}$

7.5.3 Tipologia de Agentes

Existem diferentes critérios para a classificação de agentes. Por exemplo, os agentes podem ser classificados por sua mobilidade, ou seja, sua habilidade em mover-se por diferentes nós de uma rede. Segundo este conceito os agentes podem ser classificados como agentes estáticos ou agentes móveis. Outra possível classificação pode ser feita segundo sua arquitetura. Assim, eles poderiam ser classificados como deliberativos ou reativos (também conhecidos na literatura como reflexivos).

Os agentes também podem ser classificados segundo os diferentes atributos que possam idealmente exibir. Neste sentido, HYACINTH NWANA (NWANA, 1996a, 1996b e1998), em seus trabalhos, descreve uma classificação prática dos agentes (baseado em alguns casos no que são os agentes, e outros no papel que eles executam), resultando na seguinte classificação:

Agentes cooperativos/''colaborativos'' (Collaborative Agents): agentes geralmente estáticos, grandes e de "grânulo grosso", sobre os quais há ênfase na autonomia e cooperação com ou-tros agentes para executar tarefas em prol de seus proprietários, em ambientes multi-agente abertos ou de tempo limitado. Eles podem ter aprendizado, mas este atributo não é geralmente de maior importância em sua operação. Para coordenar suas atividades, eles podem realizar algum tipo de negociação para alcançar acordos mutuamente aceitáveis (NWANA, 1996c).
Agentes de interface (Interface Agents): suportam e fornecem uma ajuda pró-ativa, geralmente para um usuário utilizando um programa de aplicação complexo. Este tipo de agente enfatiza sua autonomia e capacidade de aprendizado para executar as tarefas em nome de seus proprietários. Uma metáfora usada para definir os agentes de interface, é que são assistentes pessoais os quais estão colaborando com o usuário no mesmo ambiente de trabalho. Sua cooperação com outros agentes, se existe, é tipicamente limitada para responder às consultas (MAES ,1994; LASHKARI., 1994 e KODA, 1996).
Agentes móveis (Mobile Agents): processos de software com capacidade de movimentar-se através das redes de longo alcance (WANs, Wide Area Networks), como é o caso da WWW (World Wide Web), interagindo com hosts externos, executando tarefas em nome de seus proprietários e retornando a sua origem com o resultado das tarefas executadas. Estas tarefas ou obrigações podem ser as mais diversas possíveis, desde fazer uma reserva de vôo até manipular uma rede de telecomunicações.
Agentes de informação (Information Agents): administradores de informação WWW pró-ativos, dinâmicos, adaptativos e cooperativos que executam o papel de administradores, manipuladores ou coletores de informação de qualquer recurso distribuído (PETRIE, 1996)
Agentes reativos ou reflexivos (Reactive Agents): agentes que não possuem internamente modelos simbólicos de seus ambientes, embora respondam de maneira "estímulo-resposta" ao estado atual do ambiente no qual são colocados.
Agentes híbridos (Hybrid Agents): agentes cuja constituição é uma combinação de duas ou mais filosofias.
Sistemas de agentes heterogêneos (Heterogeneous Agent Systems): algum software baseado em agentes que combine dois ou mais agentes das categorias descritas acima.

No trabalho de doutoramento, devido a sua natureza, os agentes podem ser classificados como do tipo Cooperativo/''Colaborativo'', onde as atividades de planejamento do processo demandam uma autonomia na tomada de decisão e cooperação com outros agentes.

Outra classificação dos agentes que pode ser colocada é a seguinte:

Agentes Reativos ou Reflexivos: apresentam um processo único de percepção-ação (reflexo). A ação é uma função direta das entradas dos sensores. Esta função pode ser qualquer conjunto de regras condição-ação (fuzzy ou binária), uma rede neural ou uma função matemática (figura 7.8).

Figure 7.8: Exemplo de um agente reativo ou reflexivo.
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig7_6.ps}}$
Agentes Comportamentais: apresentam processos independentes de percepção e ação. Neste caso, a percepção é um processo independente, controlado pelo módulo de percepção. Contém um conjunto pré-definido de comportamentos, que são selecionados dependendo da percepção. O cumprimento de suas tarefas depende de uma especificação adequada do conjunto de comportamentos disponíveis (figura 7.9).

Figure 7.9: Exemplo de um agente comportamental.
$\resizebox*{14cm}{6cm}{\includegraphics{fig/fig7_7.ps}}$
Agentes Planejadores: apresentam processos independentes de percepção e ação, possuem internamente uma representação simbólica do mundo (modelo do mundo, que pode ser conhecido "a priori" ou pode ser aprendido por meio da interação com o ambiente, através dos mecanismos de percepção). A ação não é gerada diretamente pela percepção, devido à existência de um mecanismo de geração de comportamentos, capaz de elaborar predições (usando o modelo do mundo) de como o mundo se comportará diante de possíveis ações tomadas pelo agente, além de um mecanismo de geração de planos (conjunto de ações a serem tomadas pelo agente) que permitirão ao agente escolher o plano que melhor satisfizer os objetivos do sistema e executá-lo efetivamente (figura 7.10).

Figure 7.10: Exemplo de um agente planejador.
$\resizebox*{14cm}{7cm}{\includegraphics{fig/figura_7.8.ps.eps}}$
Agentes Emocionais: muito parecido com os agentes planejadores, só acrescido de um sistema de valores (emoções - por exemplo: medo, desejo, dor, alegria) que permitirá avaliar internamente se os objetivos do agente estão sendo cumpridos. Também podem ser utilizadas de modo a influir no planejamento de futuras ações, além de que podem ser atribuídas a estados atuais ou a previsões de estados futuros (figura 7.11).

Figure 7.11: Exemplo de um agente emocional.
$\resizebox*{14cm}{7cm}{\includegraphics{fig/figura_7.9.ps.eps}}$
Agentes Comunicativos: possuem um canal de comunicação direta. Somente há sentido em se falar deste tipo de agentes em sistemas multi-agentes. Precisam de uma linguagem de comunicação de agente (ACL, Agent Comunication Language) para a colaboração ou cooperação entre agentes (figura 7.12).

Figure 7.12: Exemplo de um agente comunicativo.
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig7_10.ps}}$
Agentes Semióticos: parecidos com os agentes comunicativos, mas não precisam de canais de comunicação direta, visto que o próprio ambiente é o canal de comunicação que será usado por eles para a colaboração ou cooperação entre si. Este tipo de agente precisa de mecanismos de percepção e ação muito mais sofisticados que nos casos anteriores, pois eles terão que interpretar e gerar signos para o ambiente (figura 7.13).

Figure: Exemplo de um agente semiótico.
$\resizebox*{14cm}{7cm}{\includegraphics{fig/fig7_11.ps}}$

7.5.4 Linguagens de agentes

Com o desenvolvimento da tecnologia de agentes, uma grande variedade de ferramentas de software encontram-se disponíveis para o design e construção de sistemas baseados em agentes. O número emergente de protótipos de linguagens de agentes é um sinal de que a tecnologia de agentes está sendo amplamente utilizada e que muitas aplicações baseadas em agentes estão sendo desenvolvidas.

WOOLDRIDGE e JENNINGS (WOOLDRIDGE, 1995) escreveram a respeito: "por uma linguagem de agente, entendemos um sistema que nos permita programar hardware ou software de sistemas de computação em termos de alguns dos conceitos desenvolvidos pelos teóricos de agentes. Como mínimo, esperamos que tal linguagem inclua alguma estrutura correspondente a um agente"

Como a questão "O que é um agente?" é muito polêmica e não existe um consenso (e possivelmente nunca exista) com respeito a esta questão, alguns pesquisadores consideram uma linguagem como linguagem de agentes e outros podem não considerá-la da mesma maneira O que é certo, é que elas prestam-se em diferentes graus para diferentes tipos de definições e aplicações de agentes.

A tabela 7.1 apresenta algumas linguagens para o desenvolvimento de diferentes aplicações baseadas em agentes. Nesta tabela não são apresentadas linguagens apropriadas para o desenvolvimento de sistemas multi-agentes cooperativos/''colaborativos'', visto que em geral, os agentes cooperativos/''colaborativos'' são muito mais complexos que os agentes de interface, de informação ou móveis. Além de linguagens, eles precisam de arquiteturas ou plataformas para sua construção. Como alternativa eles podem ser construídos completamente usando alguma linguagem de terceira geração, como é o caso do C++, Java, Smalltalk ou Prolog.

**Table:** Algumas linguagens de desenvolvimento de diferentes aplicações baseadas em agentes (NWANA, 1996d).
$\begin{table}\par\par {\centering\resizebox*{16cm}{9cm}{\includegraphics{fig/tab7_1.ps}}\par } \end{table}$

Até agora temos utilizado a terminologia "linguagem de agentes" para referenciar a linguagem utilizada na criação dos agentes. É importante destacar que existe um outro enfoque para esta terminologia, onde utiliza-se "linguagem de agentes" para referenciar a linguagem que dois ou mais agentes utilizam para comunicar-se entre si, quando interagindo em um ambiente comum. Esta terminologia é usual dentro do contexto de sistemas multi-agentes, sendo que as "linguagens de agentes" são utilizadas para o intercâmbio de conhecimento a ser compartilhado entre os agentes que cooperam/colaboram em sistemas deste tipo. Dois tipos de linguagens de agentes são destacados na literatura (NWANA, 1996d): as chamadas Linguagem de Comunicação de Agentes (ACL ) e as chamadas Linguagens de Conteúdo (CL ).

As ACL são utilizadas para deixar explícito o ato comunicativo relacionado à mensagem, ou seja, destaca-se o ato comunicativo pretendido pelo agente quando de sua comunicação com seu interlocutor. Alguns exemplos desta linguagem são o KQML (Knowledge Query and Manipulation Language) e o FIPA-ACL (Foundation for Intelligent Physical Agents - Agents Comunication Language).

As CL, por sua vez, são utilizadas para expressar o conhecimento que se deseja compartilhar com o destinatário da mensagem. Exemplos de linguagens deste tipo são o KIF (Knowledge Interchange Format), FIPA-CLL (FIPA Content Language Library), FIPA-SL (FIPA Semantic Language), FIPA-RDF (FIPA Resource Description Framework), FIPA-CCL (FIPA Constraint Choice Language) e o FIPA-KIF (FIPA Knowledge Interchange Format).

7.5.5 Objetos e Agentes

A engenharia de software baseada em agente é com freqüência comparada à programação orientada a objetos, em que os agentes, assim como os objetos, compartilham algumas propriedades tais como: encapsulamento, herança (com certa freqüência) e fornecem uma interface baseada em mensagens para suas estruturas de dados internas e seus métodos (ou algoritmos). Embora exista uma distinção importante: na programação orientada a objetos, o significado de uma mensagem pode ser diferente de um objeto para outro (princípio do polimorfismo). Na engenharia de software baseada em agentes, os agentes utilizam uma linguagem comum, que tem uma semântica independente dos agentes, ou seja, os agentes devem ter uma linguagem de comunicação (ACL) comum de modo que todos possam se entender.

Outra diferença entre objetos e agentes é que um objeto tem uma postura passiva diante do mundo. Ou seja, um objeto é uma entidade do mundo que somente recebe mensagens, efetuando um comportamento em resposta a elas. Por outro lado, um agente tem uma postura ativa, ou seja, é uma entidade do mundo que possui um ciclo de vida e que durante esse ciclo de vida estará adquirindo continuamente informações do mundo, através da busca ativa por mensagens que se encontrem no ambiente em que está inserido.

As semelhanças que tem os objetos e os agentes, possibilitam que algumas linguagens orientadas a objetos, tais como, Smalltalk, C++ ou Java se prestem para a construção de sistemas de agentes.

7.5.6 O Desenvolvimento de Sistemas de Agentes (ou Multi-Agentes)

Agentes podem ser integrados a sistemas de software na forma de componentes especialmente desenvolvidos para operar de maneira pró-ativa e contínua. Desta forma, pode-se adotar as mesmas metodologias de projeto de software utilizadas, por exemplo, em sistemas orientados a objetos, com apenas pequenas modificações. Essas modificações ocorrem principalmente na fase de design, durante a atribuição de funcionalidades (responsabilidades) aos componentes de software. Nesse instante, ao invés de se projetar um componente na forma de um autômato (ou seja, um grupo de objetos trocando mensagens entre si, o que seria natural na metodologia orientada a objetos), utiliza-se a metáfora de um agente. Nesse caso, o design do componente-agente passará por etapas de definição das responsabilidades do agente (sua motivação - geratriz do comportamento pró-ativo), e ciclo de vida. A atribuição de uma motivação a um agente não é uma tarefa trivial, sendo atualmente fonte de inspiração para toda uma área de pesquisas dentro do tema "sistemas inteligentes".

Uma possível metodologia para o design de um agente, que poderia metaforicamente estar associada ao design da "mente" do agente vem sendo pesquisada no DCA-FEEC-UNICAMP, sendo chamada de "Síntese Semiótica" (GUDWIN, 2001). Essa abordagem modela todo o funcionamento dos agentes como um processo de processamento de signos, desde os signos icônicos, mais voltados para os dados sensoriais e criações de modelos representacionais para esses dados, até signos indiciais, que nos remetem a outros signos e símbolos, que podem ter sua semântica atribuída por meio de aprendizado. A semiótica é a disciplina que estuda os diferentes tipos de signos e seu possível processamento. Assim, utilizando a síntese semiótica, cria-se uma metodologia de design para agentes, permitindo sua integração a um projeto de software.

7.6 Qual Modelo de Tomada de Decisão Utilizar ?

A utilização de uma arquitetura baseada em sistemas multi-agentes (MAS) é sem dúvida a mais atrativa atualmente, principalmente devido a evolução dos sistemas computacionais em especial de Unix para computadores pessoais e a utilização de redes de comunicação baseadas no protocolo TCP/IP em uma arquitetura cliente/servidor.

Desta forma pode-se utilizar diversos tipos de agentes trabalhando cooperativamente e de forma distribuída na resolução dos diversos problemas associados ao planejamento do processo. Por exemplo, pode-se utilizar um sistema de gerenciamento de base de dados relacional (MySQL® ou SQL®) para compartilhar as informações dos recursos disponíveis de manufatura (máquinas, ferramentas, informações de materiais, dispositivos de fixação, etc) e ter os agentes como os resolvedores das atividades de planejamento do processo. Os agentes podem ser implementados utilizando diversas abordagens na sua lógica de decisão: sistemas especialistas baseado em regras de produção, lógica difusa, redes neurais, tabelas de decisão, entre outros.

Pode-se utilizar a linguagem de comunicação de agentes KQML ou FIPA-ACL como linguagem que os agentes usam para se comunicar. Por exemplo, o sistema Cybercut utiliza o KQML como linguagem de comunicação. A figura 7.14 apresenta a arquitetura de agentes utilizada pelo sistema Cybercut, que pode ser tomada como referência para o trabalho de doutorado.

Cybercut foi concebido em um ambiente em rede de agentes de softwares inter-operáveis denominado de Manufacturing Agent Community (MAC). A figura 7.14 apresenta a arquitetura MAC que pode ser estratificada em três partes. No nível superior reside um grupo de Agentes de Projeto, o quais atuam como ferramentas CAD e também permite aos usuários que se conectem aos níveis inferiores. O nível intermediário consiste de Agentes de Planejamento. Este grupo de agentes interpreta as definições de projeto, modelagem geométrica, realizada pelo usuário, e determina como fabricar a peça usando o Agente de fabricação selecionado, o qual reside no nível inferior. É utilizado uma interface transparente entre o projeto, planejamento e fabricação.

A partir deste fluxo de informações entre os três níveis da arquitetura é necessário realizar o encapsulamento destas informações, sendo adotado o Knowledge Query and Manipulation Language (KQML) como padrão de linguagem de mensagens entre os agentes. KQML contém informações sobre quais agentes enviam mensagem, onde eles estão, como interpretar a mensagem recebida pelo destinatário. As mensagens são trocadas usando conexões sockets diretas entre os agentes.

**Figure 7.14:** Cybercut: Arquitetura Multi-Agente basead no KQML.
$\resizebox*{14cm}{8cm}{\includegraphics{fig/figura_7.12.eps}}$

Foi utilizado a ferramenta computacional JATLite (Java Agent Template Lite). JATLite é um pacote de programas escritos em Java que permite aos usuários a criação de agentes de softwares que comunica-se de forma robusta na Internet. Esta ferramenta pode ser obtida gratuitamente na URL http://java.stanford.edu/index.html. JATLite oferece uma infra-estrutura básica na qual agentes registrados com um Agent Message Router (AMR) usam um nome e um password, conectando-se e desconectando-se da Internet, mandando e recebendo mensagens, transferindo arquivos com FTP, e geralmente trocando informações com outros agentes através dos vários computadores onde eles estão sendo executados. A figura 7.15 apresenta o sistema JATLite. Este ferramenta foi utilizado na implementação do CyberCut. O protocolo de mensagem compartilhado utilizado é o KQML. JATLite permite o desenvolvimento de uma infra-estrutura para Typed-Message Agents, definido nos termos de uma comunidade de agentes. Maiores informações sobre KQML e sistemas desenvolvidos utilizando-se a arquitetura de agentes podem ser encontradas na URL http://www.cs.umbc.edu/kqml. Uma abordagem interessante utilizando o kernel de sistema especialista JESS (Clips portado para Java), KQML e JATLite é descrito na URL http://cdr.stanford.edu/ petrie/jat/CooplS99-paper.pdf. JESS foi empacotado junto com JATLite para produzir agentes inteligentes baseados em Java e regras.

**Figure 7.15:** JATLite: Roteador de Mensagem de Agente.
$\resizebox*{13.7cm}{9cm}{\includegraphics{fig/fig_7.13.ps}}$

8. Implantação de Infra-Estrutura no Grima

Com o intuito de viabilizar o desenvolvimento das atividades definidas no plano de doutorado foi necessário implantar uma infra-estrutura computacional mínima no laboratório do Grima através da instalação e configuração de uma estação de trabalho baseado no sistema operacional Linux para arquitetura 386. Desta forma foi feita a instalação de uma distribuição Linux em um computador Pentium III e configurado uma série de serviços (ftp, http, ssh, mysql, tomcat servelets, xdm, lpd) para trabalharem em uma arquitetura cliente/servidor e que serão utilizados no desenvolvimento da tese. Isto foi realizado durante na disciplina de estudo dirigido cursada no terceiro período de 2001.

Foi feita uma especificação de computadores para serem utilizados como estações de trabalho utilizando o sistema operacional Linux e que formarão um cluster de máquinas para trabalharem com processamento paralelo, compartilhando o uso de processadores e memória, utilizando a arquitetura MOSIX cluster (ftp://custom.lab.unb.br/pub/cluster/mosix). Esta atividade ainda não foi implementada, pois aguardasse a chegada dos computadores recentemente adquiridos.

Foi instalado uma série de aplicações voltadas para desenvolvimento de sistemas e que poderão ser utilizadas no desenvolvimento do trabalho de doutoramento nas estações de trabalho Linux, como:

Clips: kernel para construção de sistemas especialista baseado em regras de produção;
FuzzyClips: kernel para construção de sistemas especialista baseado em regras de produção e lógica difusa;
Jess: Clips portado para Java;
Sistemas CAD 2D: vários sistemas CAD desenvolvidos em C e Java;
Sistemas CAM: vários sistemas CAM desenvolvidos em C e Java;
ACIS: kernel para modelagem de sólidos (B-rep e CSG);
JBuilder Foundation: desenvolvimento de sistema em Java;
MySQL: sistema de gerenciamento de base de dados relacional utilizando a linguagem SQL;
Gnu C++: compilador C++ da Gnu;
Tex, Latex e Lyx: editores de texto de alto nível;
Staroffice e WordPerfect: editores de texto compatíveis com Windows;
Citrix, VNC e Xwin: protocolos e servidores para integração de plataformas Unix e Windows;
Centenas de aplicações de suporte de desenvolvimento para o mundo Unix.
Tom Cat.

Estão sendo desenvolvidas atividades de suporte na introdução da cultura Unix no laboratório do Grima ajudando os estagiários na utilização dos sistemas instalados, esclarecendo dúvidas, enfim treinando-os na resolução de problemas relacionados ao uso e administração de sistema Unix e da rede de computadores do Grima baseado no protocolo TCP/IP (Internet/Intranet).

Muitas das atividades desenvolvidas nos computadores do Grima são executadas utilizando-se de conexão remota através de aplicações de login remoto como o protocolo telnet (user interface to the TELNET protocol) e o ssh (OpenSSH SSH client - remote login program). Estas aplicações permitem emular um console virtual e ``logar'' remotamente nas máquinas realizando o trabalho a distância.

Também é utilizado o sistema XDM (X Display Manager with support for XDMCP, host chooser) para conexão remota utilizando janela/display gráfico a fim de executar programas que necessitem de um servidor gráfico X (X - a portable, network-transparent window system). Através do xdm utiliza-se remotamente, em Florianópolis, aplicações CAD/CAM (SmartCam e AutoCad) disponíveis no Laboratório do Graco em Brasília. Foi também instalado um servidor METAFRAME XP (Citrix) para plataforma Windows Advanced Server 2000, disponibilizado seu acessso através da Web por meio da URL http://laplace.lmp.ufsc.br e através de clientes ICA para Windows e Unix.

A utilização do ambiente Unix é sem dúvida um grande facilitador para trabalhos cooperativos e a distância pois permite uma utilização transparente dos recursos de rede TCP/IP em uma arquitetura cliente/servidor, nativa em plataforma Unix, desde a sua concepção, ou seja, são na-turalmente orientados para aplicações em rede. Outra grande vantagem é a utilização de software open source e normalmente gratuitos. Todos os softwares instalados nos servidores e que serão utilizados nas atividades de doutoramento são open source ou gratuitos.

Está sendo construído um sistema de pan-tilt para posicionamento de uma câmera de vídeo seme-lhante ao sistema RobWebCam desenvolvido na UnB/Graco (http://graco.unb.br/robwebcam). Este sistema será utilizado como Webcam, para captura de vídeo e imagem do processo de usinagem remoto. Esta atividade está sendo desenvolvida por estagiários do Grima.

Com relação ao torno CNC da Romi, disponível no laboratório de usinagem, que poderá ser utilizado no trabalho de implementação do sistema de teleoperação foi constatado alguns problemas associados a versão do CNC utilizada na máquina. Este CNC não tem implementado um protocolo de comunicação DNC, apresenta apenas funções associadas a download e upload de arquivos de NC em formato ASCII. Após consulta ao fabricante do conjunto máquina-ferramenta/CNC, Indústrias Romi, foi obtida a seguinte posição:

CNC Mach 9 fabricado pela Romi

Para o comando Mach 9 somente é possível fazer download e upload de programas de usinagem via RS232 .

8.0.0.1 CNC's Mach 6 fabricado pela Romi e GE-Fanuc 18i-TA

Para os comandos Mach 6 e Fanuc 18i existe o protocolo DNC2 que é baseado no protocolo LSV2 usado por vários fabricantes de CNC na Europa. Este protocolo utiliza a interface RS232 para comunicação, podendo utilizar a interface RS422 para melhorar a velocidade de transmissão.

Este protocolo pode ser usado somente de um único PC para uma única máquina. Não pode ser usado de um único PC para várias máquinas.

Com o protocolo DNC2 é possível fazer:

Carga e Descarga de programas;
Deletar programa;
Ler diretórios de programas;
Mostrar mensagens para o operador na tela da máquina;
Ler e Escrever nas variáveis do PMC;
Selecionar programas;
Iniciar programas;
Resetar a máquina;
Verificar as mensagens de alarme .

Para isso é necessário incluir a placa DNC2 ao comando Mach 6 e a interface RS-232 (já disponível) ou RS-422 na máquina/comando da Romi. Para o PC é necessário instalar o software DNC2 (J530). Para as funções básica do DNC2, no CNC será necessário habilitar os opcionais de Software DNC2, Background Editing e I/O unit external control, e para as funções não básicas é necessário a habilitação de alguns outros opcionais de software, tais como: Read/Write of pitch error compensation, Read/Write of custom macro variables, Read of tool life management data e Read/Write of PMC data (este último somente para o Mach6). Para estes comandos não existe o protocolo PROFIBUS.

O DNC-2 não é opcional nas máquinas Romi e sim uma execução especial, um acessório. Assim sendo é necessário solicitar a instalação deste opcional na máquina disponível na UFSC, o que já se está tentando viabilizar através de projetos de pesquisa submetidos à agências de fomento. Esta é uma das prioridades em termos de compra de equipamentos para o trabalho de doutoramento. Na Universidade de Brasília, o Grupo de Automação e Controle (Graco) está adquirindo um Centro de Torneamento Galaxy 15M da Romi com comando GE-Fanuc 18i-TA. Outra opção é utilizar um torno CNC da SOCIESC de Joinville com os recursos de comunicação necessários para permitir a sua teleoperação.

9. Conclusões

Este estudo dirigido voltado para os aspectos de TeleManufatura foi de grande validade para o desenvolvimento do tema de doutoramento, pois foi possível estudar e consultar uma grande quantidade de referências sobre os aspectos de integração de CAD/CAPP/CAM e a teleoperação voltados para internet. O estudo teve como referência o sistema CyberCut da Universidade de Berkeley (http://cybercut.berkeley.edu), o sistema WebSpiff (http://www.webspiff.org), o sistema WebOxiCorte (http://weboxicorte.graco.unb.br) e outros sistemas desenvolvidos no mundo.

A disciplina permitiu que se adquirisse um profundo conhecimento dos aspectos de integração CAD/CAPP/CAM via Internet. Com a análise efetuada nos sistemas de TeleManufatura, Mode-lagem Cooperativa, Sistemas de Gerenciamento de Base de Dados Relacional, Sistemas Multi-Agentes, entre outros, apresentados como referência, foi possível conhecer as diversas arquiteturas, algoritmos, ferramentas computacionais e tecnologias da informação utilizados na implementação destes sistemas.

A primeira disciplina de estudo dirigido, cursada no terceiro período de 2001, tratou dos aspectos associados as atividades de Projeto e Planejamento de Processos Assistidos por computador. Nesta disciplina estudou-se as várias atividades a serem realizadas no planejamento do processo e os métodos, algoritmos e lógicas de decisão utilizados na resolução destes pro-blemas foram pesquisados e relacionados. A maioria destas abordagens são minuciosamente des-critas nas referências bibliográficas consultadas e disponibilizadas através do endereço: ftp://omega.enm.unb.br/pub/doutorado.

Estes dois estudos dirigidos servirão de base para a definição de uma metodologia e arquitetura a ser desenvolvida para tese de doutorado; e grande parte da pesquisa bibliográfica para o Exame de Qualificação já foi realizado. Todo o material em formato digital obtido na pesquisa bibliográfica está disponível na URL http://omega.enm.unb.br/pub.

Com o conhecimento adquirido em relação as diversas abordagens de metodologias e implementações realizadas no mundo para o desenvolvimento de sistemas integrados de Telemanufatura, ficou claro que a metodologia e sistema computacional a ser concebido, para integração CAD/CAPP/CAM orientado para fabricação de peças rotacionais utilizando o processo de torneamento, deve ser baseado em:

modelagem utilizando a tecnologia de Features no lado do cliente;
arquitetura baseadas em sistemas multi-agentes (MAS) associado a utilização de técnicas de representação do conhecimento como sistemas especialistas (JATLite com Clips, FuzzyClips ou Jess);
sistemas distribuídos e arquitetura cliente/servidor;
redes de computadores baseados no protocolo TCP/IP em conjunto com HTTP;
programação utilizando as linguagens de programação Java e C++;
utilização do sistema operacional Linux;
um adequado balanceamento entre a funcionalidade do cliente e a largura de banda disponível na Internet;
base de dados relacional para compartilhamento de informações (máquinas, ferramentas, dispositivos de fixação, bibliotecas de features, etc) sendo um candidado em potencial o MySQL;
projeto baseado em Features de projeto/forma (operações de torneamento) e usinagem (ope-rações de fresamento e furação);
modelagem de sólidos utilizando o kernel ACIS no lado do servidor.

Bibliography

1: AARIA - Autonomous Agents at Rock Island Arsenal , www.aaria.uc.edu.
2: Abdou, G.; Cheng, R. TVCAPP, Tolerance Verification in Computer-Aided Process Planning. International Journal of Production Research, v.31, n.2, p.393-411, 1993.
3: Adamczyk, Z. e Kociolek, K., 2001, "CAD/CAM Tecnological Environment creation as an interactive application on the Web", Journal of Materials Processing Technology, Vol. 109, pp. 222-228.
4: Agent Society Home Page http://www.agent.org/
5: Almeida, R., Almeida, F. and Carvalho, R., 1995, Sistema de Televigilância, ISR Project Report.
6: Ahn, S., Sequin C. e Wright. P., 1999, "Internet-Based Dessign an Manufacturing", Final Report 1988-99 for micro Project 98-136, TRW.
7: Alting, Leo; Zhang, Hong-Chao. Computer Aided Process Planning: the State-of-the-Art Survey. International Journal of Production Research, v.27, n.4, p.553-585, 1989.
8: Alting, Leo. Life-Cycle Design of Products: A New Opportunity for Manufacturing Enterprises. In: KUSIAK, Andrew. Concurrent Engineering: Automation, Tools and Techniques. New York : John Wiley & Sons, Inc, 1993. p.1-17.
9: Álvares, A. J., Tourino, S. R., Tele-Fuzzy Control of a Mobile Robo, 17TH INTERNATIONAL CONFERENCE ON CAD/CAM, ROBOTICS & FACTORIES OF THE FUTURE, 2001CARS&FOF 2001), Durban, Kwazulu-Natal, Africa do Sul, 07/2001.
10: Álvares, A. J. e Tourino, S. R., 2000, "Desenvolvimento de um Robô Móvel Autônomo Teleoperado Via Internet" , Cogresso Nacional de Engenharia Mecânica 2000, Natal , RN, 7-12 de Agôsto.
11: Álvares, A. J. e Paulinyi, S. C. A., 1999, "Telerobotics:Through-the-Internet Teleoperation of the ABB IRB 2000 Industrial Robot", Telemanipulator andTelepresence Technologies V - SPIE (The International Society for Optical Enginnering) - Telemanipulator and Telepresence Technologies VI, pp. 259-269, Boston, USA,
12: Álvares, A. J. e Romariz, L. J., 1999, "TeleRobótica: Metodologia Para o Desenvolvimento de Sistemas Robóticos Teleoperados Via Internet", XV Congresso Brasileiro de Engenharia Mecânica, Águas de Lindóia, S.P., 22-26 de Novembro.
13: Álvares, A. J. e Romariz, L. J., 1998, "Desenvolvimento de um Manipulador com Dois Graus de Liberdade Controlado Remotamente Via Internet", V Congresso de Engenharia Mecânica Norte e Nordeste, Fortaleza, 27-30 de Outubro, pp. 529-536.
14: Álvares, A. J et al., Apostila da Disciplina Sistemas Integrados de Manufatura, Universidade de Brasília, Graduação Engenharia Mecânica e Mecatrônica, 1992.
15: Anais do International IFIP Conference on Feature Modeling and Advanced Design-For-The-Life-Cycle Systems, Valenciennes, França, 12-14 de Junho, 2001.
16: Arnett, M.F., Dulaney, E. e Harper, E. 1994. "Inside TCP/IP". New Riders Publishing. Indianapolis. USA.
17: Arakaki, Reginaldo; Arakaki, Julio; Angerami, Paulo Mattos et al. Fundamentos de Programação C: Técnicas e Aplicações. 2. ed. Rio de Janeiro : Livros Técnicos e Científicos, 1990.
18: Baker, A. D.; Parunak, H.V.D. ; Erol, K. - Internet-Based Manufacturing: A Perspective from the AARIA Project. Working Paper, Enterprise Action Group, Inc., Cincinnati, Ohio, August 12, 199
19: Baker, A. D.; Parunak, H.V.D. ; Erol, K. - Agents and the Internet: Infrastructure for Mass Customization. IEEE Internet Computing, Vol. 3, No. 5, September-October 1999, pp. 62-69.9.
20: Banerjee, P.; Zetu, D. (2001). Virtual manufacturing. John Wiley & Sons, Inc, New York. 320p.
21: Bastos, Ricardo M.; Oliveira, José P. - A Conceptual Modeling Framework for Multi-agent Information System. ER2000 Conference, LNCS (Lectures Notes in Computer Science) vol. 1920, pp.295-308, 2000.
22: Bastos, Ricardo M. - Planejamento de Alocação de Recursos Baseados em Sistemas Multiagentes. Tese de Doutorado, CPGCC/UFRGS, Porto Alegre, 1998.
23: Batocchio, A.; Fioroni, M.M.; Georges, M.R.R.; Souza, A.C.; Rosa, A.B.; Franco, G.N. - Manufauta Ágil x Sistema Holônico de Manufatura. Anais do IV Simpósio Brasileiro de Automação Inteligente, São Paulo,08-10, setembro, 1999.
24: Bhatnagar A.S., Implementation of feature mapping and reasoning shell with application to group technology coding, MSc Thesis, Arizona State University, August 1988.
25: Boerma J.R., The design of fixtures for prismatic parts, PhD thesis, University of Twente, Enschede, 1990.
26: Boogert R., Tool management in computer aided process planning, PhD thesis, University of Twente, 1994.
27: Brenner, W.; Zarnekow, R.; Wittig, H. - Intelligent Software Agents: Foundations and Applications - Springer-Verlag Berlin Heidelberg New York - 1998.
28: Bronsvoort, Willem F.; Jansen, Frederik W. Multi-View Feature Modelling for Design and Assembly. In: SHAH, Jami J.; MÄNTYLÄ, Martti; NAU, Dana S. Advances in Feature Based Manufacturing. Amsterdam : ELSEVIER, 1994. p.107-128.
29: Brooks, R.A. - Elephants don´t play chess - Maes, P. (eds.): Designing Autonomous Agents - The MIT Press - Cambridge - MA - pp. 3-15 - 1990.
30: Brooks, R.A. - Intelligence without reason - Proceedings of the Twelfth International Joint Conference on Artificial Intelligence - Sydney - Australia - pp. 569-595 - 1991.
31: Brooks, R.A. - Intelligence without representation - Artificial Intelligence - No. 47 - pp. 139-159 - 1991.
32: Brown, S. M. e Wright, P. K., 1998, "A Progress Report on the Manufacturing Analysis Service, an Internet-Based Reference Tool", Journal of Manufacturing Systems, Vol. 17, No. 5, pp.389-401.
33: Brückner, S, Wyns, J, Peeters, P, Kollingbaum, M. - Designing Agents for the Manufacturing Process Control. In Proceedings of Artificial Intelligence and Manufacturing Research Planning Workshop - State of the Art & State of the Practice, AAAI Press, Albuquerque, New Mexico, pp. 40-46, 1998.
34: Burdea,G. & Coiffet,P. - Virtual RealityTechnology, John Wiley & Sons, New York, NY, 1994.
35: Bussmann S. - An Agent-Oriented Architecture for Holonic Manufacturing Control. In Proceedings of First International Workshop on IMS, Lausanne, Switzerland, pp. 1-12, 1998.
36: Butzke, A.U.; Ferreira, J.C.E. A Manufacturing Support System for Industrial Part Process Planning.
37: Buxton, W. Telepresence: integrating shared task and person spaces. Proceedings of Graphics Interface' 92, pp. 123-129, 1992.
38: Camarinha, L.M.; Afsarmanesh, H. Balanced Automation Systems: Architectures and Design Methods (BASYS-95). Vitória : CHAPMAN & HALL, 1995. p.159-170.
39: CAM-I's illustrated glossary of workpiece form features, R-80-PPP-02.1, 1981.
40: CAM-I report R-86-PPP-01, 1986.
41: Chang T.C., Anderson D.C., Mitchell O.R., QTC - An integrated design/manufacturing/inspection system for prismatic parts, Computers in Engineering Conference, CIE '88, 1988, 417 - 426.
42: Chang T-C., Expert process planning for manufacturing, Addison Wesley, Reading, 1990.
43: Chang, T.C., Wysk R.A. e Wang, H.P. Computer Aided Manufacturing, Prentice Hall International Series in Industrial and Systems Engineering, W.J. Fabrycky e J.H. Mize (eds.), 2ns Edition, 1998.
44: Cheah, R. S., Lee, B. S. e Lim, R. L., Design and implementation of an MMS environment on ISODE, Computer Communications, 20, 1997, 1354-1364.
45: Chen, Q.; Dayal, U. - Multi-agent Cooperative Transactions for E-commerce. LNCS (Lectures Notes in Computer Science) Cooperative Information System, vol. 1901, pp. 311-322, Springer-Verlag, Berlin, 2000.
46: Cho, H.; Derebail, A.; Hale, T. et al. A Formal Approach to Integrating Computer-Aided Process Planning and Shop Floor Control. ASME Journal of Engineering for Industry, v.116, p.108-116, 1994.
47: Comer, D. C., "Redes de Computadores e Internet", Bookman, 2a Edição, 1999.
48: Computational Semiotic Group http://www.dca.fee.unicamp.br/projects/semiotics/
49: Connectix, 1996, QuickCam Color - Guia do Usuário, California.
50: Corny J. Lim, "3D Modeling with ACIS", Saxe-Coburg Publications, 2a. Edição, 2001.
51: Crutchfield, S., and Rugh, W. , "Interactive Exercises and Demonstrations on the Web for Basic Signals, Systems, and Controls, " Proc. CDC , San Diego,Dec. 1997, pp. 3811-3815.
52: Cunha, R. R. M., Estudo e desenvolvimento de metodologias na troca de dados em CAD/CAM, Estudo dirigido, Departamento de Engenharia Mecânica, Universidade Federal de Santa Catarina, 2000.
53: Cutkosky M.R., Tenenbaum J.M., Muller D., Features in process based design, ASME Computers in Engineering (CIE) Conference, San Francisco, 1988, 557-562.
54: Cutkosky M.R., Tenenbaum J.M., Brown D.R., Working with multiple representations in a concurrent design system, Journal of Mechanical Design, Vol. 114, 1992, 515 - 524.
55: Cutkosky M.R., Engelmore R.S., Fikes R.E., Genesereth M.R., Gruber T.R., Mark W.S., Tenenbaum J.M., Weber J.C., PACT: An experiment in integrating concurrent engineering systems, IEEE Computer, vol. 26, no.1, 1993, 28-37, http://www-ksl.stanford.edu.knowledge-sharing.
56: Dante, C. J., Introdução à Sistemas de Banco de Dados, 4 $\ensuremath{º}$ Edição, Editora Campus, Rio de Janeiro - RJ, 1991
57: Dépincé, P., Amara H., Hascoët, J. Y., Human Integration in s distributed CAPP framework,Bibliography Anais do International IFIP Conference on Feature Modeling and Advanced Design-For-The-Life-Cycle Systems, Valenciennes, França, 12-14 de Junho, 2001.
58: Deere & Company, Part Features for Process Planning, Moline Illinois, 1986.
59: Dixon J.R., Cunningham J.J., Simmons M.K., Research in designing with features, in Intelligent CAD, I, eds. Yoshikawa H., Gossard D., Proc. IFIP TC 5/ WG 5.2 workshop on intelligent CAD, Elsevier, 1987, 137-148.
60: Eckel B., "Thinking in Java", Prentice-Hall, 2a. Edição, 2000.
61: Eckel G. & Hare C., 1995, "Building a Linux Internet Server", New Riders Publishing, Indianapolis.
62: Erve A.H. van 't, Computer Aided Process Planning for Part Manufacturing, an expert system approach, PhD thesis, University of Twente, 1988.
63: Ferreira, J.C.E.; Butzke, A.U.; Furlan N., F. A CAD by Features System Applied to an Industrial Reality. Journal of the Brazilian Society of Mechanical Sciences, v.17, n.2, p.209-218, 1995.
64: Ferreira J. C. E., Wysk, R. A., An Investigation of the Influence of Alternative Process Plans on Equipment Control, Journal of Manufacturing Systems, Vol.19/N.6, 2001, 393-406.
65: Fields D. K., Kolb M. A. e Bayern S., "Web Development with Java Server Pages", Manning, 2a. Edição, 2001.
66: Finger S., Dixon J.R., A review of research in engineering design, Part I: Descriptive, prescriptive and computer based models of design processes, Research in Engineering Design, Vol.1, 1989, 51-67.
67: Finger S., Dixon J.R., A review of research in engineering design, Part II: , Representations, analysis and design for the Lifecycle, Research in Engineering Design, Vol.1, 1989, 121-37.
68: Finger S., Safier S.A., Representing and recognizing features in mechanical designs, second international conference on Design Theory and Methodology DTM '90, Chicago, September 1990.
69: Fingar, Peter - A CEO's Guide to eCommerce Using Object-Oriented Intelliegent Agent Technology, http://home1.gte.net/pfingar/eba.htm , 1998
70: Fischer, K., "Agent-based design of holonic manufacturing systems," Robotics and Autonomous Systems, 27, pp. 3-13, 1999.
71: Fischer, K. - An Agent-Based Approach to Holonic Manufacturing Systems. In: L. M. Camarinha-Matos, H. Afsarmanesh, and V. Marik (eds.), Intelligent Systems for Manufacturing. Kluwer Academic Publishers, 1998.
72: Flake, S.; Ch. Geiger; G. Lehrenfeld, W. Mueller, V. Paelke - Agent-Based Modeling for Holonic Manufacturing Systems with Fuzzy Control, NAFIPS'99, 18th International Conference of the North American Fuzzy Information Processing Society, New York, USA, June, 10-12, 1999.
73: Franklin S., Graesser A. - Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents - Proceedings of the Third International Workshop on Agent Theories, Architectures, and Languages - Springer-Verlag, 1996.
74: GPHMS - Grupo de Pesquisa em Holonic Manufacturing Systems, http://www.fem.unicamp.br/defhp/gphms/index.htm
75: Gadh R., Flexible mappings as utilized within a flexible features-based design approach, proc. IFIP W.G. 5.3 Conf. on Feature modeling and recognition in advanced CAD/CAM systems, Valenciennes (F), Vol.1, 1994, 205-223.
76: Groover, M. Automation, Production System, and Computer Integrated Manufacturing, 1987, Prentice Hall.
77: Gudwin, R.R ; Gomide, F.A.C. - Object Networks : A Formal Model to develop Intelligent Systems - in W.Pedrycz and J.F.Peters, editors - Computational Intelligence in Software Engineering - World Scientific Pub Co, June 1998.
78: Gudwin, R.R.; Gomide, F.A.C. - Object Networks : A Computational Framework to Compute with Words - in L.A.Zadeh and J. Kacprzyk, editors - Computing with Words in Information/Intelligent Systems I - Series: Studies in Fuzziness and Soft Computing.VOL. 33 - Springer Verlag, Berlin/Heidelberg, 1999.
79: Gudwin, R. "Semiotic Synthesis and Semionic Networks" - SEE'01 - 2nd International Conference on Semiotics, Evolution and Energy - October 6-8, 2001, University of Toronto, Toronto, Canada.
80: Halevi, G. e Weill, R.D., "Principles of Process Planning: A Logical Approach", Chapman & Hall, 1995.
81: Halevi, G., "Restructuring the Manufacturing Process: Applying the Matrix Method", St. Lucie Press, 1999.
82: Hall, B. B. Beej's guite to network programming using internet sockets. Disponível na Internet via WWW. URL: http://www.eest.esuchico.edu/ beej/guide/net 1999.
83: Han, J. H. e Requicha, A. A. G., Modeler-independent Feature Recognition in a Distributed Environment. Computer-Aided Design, 30(6), 453-463, 1998.
84: Hannaford, B. Feeling is Believing: Hystory of Telerobotics Technology. The Robot in the Garden: Telerobotics and Telepistemology in the Age of the Internet. K. Goldberg, editor, MIT Press, 1999.
85: Hardwick, M., Spooner, D. L., Rando, T, e Morrir, K. C., Sharing Manufavturing Information in Virtual Enterprises, Communications of the ACM, 39(2), 46-54, 1996.
86: Hartley, J. R., "Concurrent Engineering - Shortning Lead Times, Raising Quality and Lowering Costs", Productivity Press (1992), Chaper 2.
87: Hashmi, K., Baradie, M. A., Ryan, M., Fuzzy Logic Based Intelligent Selection of Machining Parameters, Computers in Industry, 35, 1998, 571-574.
88: Hirzinger, G. et al, 1997, Teleoperating Space Robots - Impact for the Design of Industrial Robots, IEEE International Symposium on Industrial Electronics, Portugal, July 12-16, pp. 250-256.
89: Horstmann C. S. e Cornell G., "Core Java 2 - Volume 1 - Fundamentos", Makron Books, 2000.
90: Horstmann C. S. e Cornell G., "Core Java 2 - Volume 2 - Recursos Avançados", Makron Books, 2000
91: Houten F.J.A.M., Kals H.J.J., Round, a flexible technology based process and operations planning system for NC lathes, Proceedings of the 16th CIRP International Seminar on Manufacturing Systems, Tokyo, 1984.
92: Houten F.J.A.M. van, PART: a computer aided process planning system, PhD thesis, University of Twente, Enschede, 1991.
93: Houten F.J.A.M., Manufacturing Interfaces, Annals of the CIRP, Vol. 41, 1992.
94: Huang, Hefeng. A Generative Process Planning System for Turned Components. Manchester, 1988. Tese (Doutorado em Fabricação Mecânica-Planejamento de Processos). Manufacturing and Machine Tool Division, Mechanical Engineerin
95: HSM Software Inc. (2000). HMS-CAPP second generation. Manufacturing Management Information Systems. http://www.hmssoftware.com (10/06/2000). g Department, UMIST.
96: ISO TC184/WG3 N324 -T7, ISO 10303 - Part 224 Mechanical Product Definition for Process Planning Using Form Features, South Carolina, EUA, 1994.
97: Jennings, N.R. and Wooldridge, M.J. Applications of Intelligent Agents. Agent Technology: Foundations, Applications, and Markets. Jennings, N.R. and Wooldridge, M.J (Eds.), Springer, pp. 3-28, 1998.
98: Jennings, N.R. - Agent Theories, Architecture and Languages: a survey. LNAI (Lectures Notes in Artificial Intelligent), Intelligent Agents, Jennings N.R., Wooldridge M. (Eds.), vol. 890, Springer, pp. 1-39, 1994.
99: Jennings, N.R.; et al. - Using Intelligent Agents to Manage Business Process. In. Proceedings of Practical Applications of Intelligent Agents and Multi-agent Technology - PAAM'96, London, UK, 1996.
100: Jonker H.G., Interactive feature definition, MSc thesis, University of Twente, report no. SPA-93-23/PT465, Enschede, September, 1993.
101: Kals H.J.J., Houten F.J.A.M. van, Erve A.H. van't, Integrated Process Planning, Proceedings of the Seminar on the automated factory approaching the year 2000 (La Fabbrica Automatica colle Soglie del 2000, Resultati E prospettive della Ricerce), Pisa, 23-24 Octobre, 1989.
102: Kao, Y. C. e Lin, G. C., 1996, "CAD/CAM Collaboration and remote Machining", Computer Integrated Manufacturing Systems, Vol. 9, No. 3, pp. 149-160.
103: Knight, C.D., DeWeerth, S.P., "World Wide Web-Based Automatic Testing of Analog Circuits ". Proc. of 1996 Midwest Symposium on Circuits and Systems . IEEE press: Ames, IA., Aug. 1996, pp.295-298.
104: Kramer, G.A., A geometric constraint engine, AIJ, 1992, to be obtained via: ftp://ftp.daimi.aau.dk/pub/CLP.
105: Lashkari, Y.; Metral, M.; Maes, P. - Collaborative Interface Agents - Proceedings of the Twelfth National Conference on Artificial Intelligence - Vol. 1 - AAAI Press - Seattle - 1994.
106: Lee, J. Y., Han, S. B., Kim, H., Park, S. B., 1999, Network-centric Feature-based Modeling, Pacific Graphics 1999.
107: Lenderink A., Kals H.J.J., The integration of process planning and machine loading in small batch part manufacturing, Robotics & Comp. Int. Manuf., Vol. 10, no. 1/2, 1993, 89-98.
108: Lenderink A., The integration of process and production planning in small batch part manufacturing, PhD thesis, University of Twente, 1994.
109: Malek, L. A., Wolf, C. e Guyot, P. D., 1998, "Telemanufacturing: A Flexible Manufacturing Solution", Int. J. Production Economics, Vol. 56-57, pp. 1-12.
110: Manet, Desenvolvimento de um Sistema Inteligente de Produção com Gestão Remota Via Internet, Unicamp-USP-UFSC-UNESP-UnB, Projeto de Pesquisa submetido ao CNPq, 2002.
111: ``Manufacturing on the Internet: Use 21st Century Techniques to Speed Your Product Cycles", John Wiley & Sons, 2a. Edição, 1997.
112: Maraghy H.A., Evolution and future perspectives of CAPP, Annals of the CIRP, vol. 42, no.2, 1993, 1 - 13.
113: Martino, T. D., Falcidieno, B. e Hasinger, S., Design and Engineering Process Integration Through a Multiple View Intermediate Modeller in a Distributed Object-oriented System Environment, Computer-Aided Design, 30(6), 437-452, 1998.
114: Martins, W., 1999, "Manual Técnico da Máquina de Corte AUTOCUT 2.5 L MCS-520", White Martins.
115: MCS, 1999 "MCS Engenharia", disponível na internet via WWW URL: http://www.mcseng.com.br.
116: Melchiors, C., 1996, Sistemas Interpessoais de Videoconferência (MBone), http://www.penta. ufrgs.br/cristina/mbone/ti/indiceti.htm.
117: Metcalfe, V. Gierth, A. et al. Programming UNIX Sockets in C - Frequently Asked Questions. Disponível na Internet via WWW. URL: http://www.ibrado.com/sock-faq/ 1998.
118: Mills A., "Collaborative Engineering and the Internet: Linking Product Development Partners Via the Web", SME, 2001.
119: Monaco, F. J. e Gonzaga, A., 1999, "Toward Distributed Cooperative Telemanufacturing over the Internet", Proceedings of 15th International Conference on CAD/CAM, Robotics & Factories of the Future, 18-20 Aug, Águas de Lindóia, Brazil, Vol. 1, pp. MT7-17.
120: Monteiro F. et al, 1997, Teleoperating a Mobile Robot - A Solution Based on JAVA Language, IEEE International Symposium on Industrial Electronics, Portugal, July 12-16, pp. 263-267.
121: Multi-Agent Systems Home Page www.multiagent.com
122: Multi-Agent Research Group, http://www.cs.wustl.edu/mas/main.html
123: Multi-Agent Systems Laboratory http://mas.cs.umass.edu/index.shtml
124: Ndumu D.T.; Nwana H.S. - Research and Development Challenges for Agent-Based Systems - IEE Proceedings on Software Engineering - Vol. 144 - No. 1 - 1997.
125: Neto, A. F., Furlan, J. D. e Higa, W., Engenharia da Informação - Metodologia, Técnicas e Ferramentas, 2 $\ensuremath{º}$ Edição, Editora McGraw - Hill, São Paulo -SP, 1988.
126: Otsuka, J., 1996, Fatores Determinantes na Efetividade de Ferramentas de Comunicação Mediada por Computador no Ensino à Distância, http://penta.ufrgs.br:80/pesquisa/joice/joice_ti.html.
127: Peng, Q., Hall, F. R. e Lister, P. M., Application and evaluation of VR-based CAPP system, Journal og Materials Processing Technology, 107, 2000, 153-159.
128: Peters, S. F. Autonomy through interaction: the JPL telerobot interactive planning system. SPIE - Volume 1006 - Space Station Automation IV, pp 173-178, 1988.
129: Petrie, C.J. - Agent-Based Engineering , the WEB, and Intelligence - IEEE Expert Intelligent Systems & their Applications - Vol. 11 - No. 6 - 1996 - pp. 24-29.
130: Porto, A. J. V. & Palma, J. G. (2000). Manufatura Virtual in Fábrica do Futuro: Entenda hoje como sua indústria vai ser amanhã, Editoras Banas, dez .
131: Pradhan, S. S. e Huang, W. V., 1998, "Virtual Manufacturing Information System Using Java and JDBC", Computers Ind. Engng, Vol. 35,No. 1-2, pp. 255-258.
132: Pratt M.J., A hybrid feature based modelling system, Advanced geometric modelling for engineering applications, eds. Krause F.L., Jansen H., Elsevier Science Publishers, 1990, 189-210.
133: Rastogi, A.; Milgram, P.; Grodski, J. J. Telerobotic Control using Augmented Reality. Proceedings of the 4th IEEE International Workshop on Robot and Humam Communication (RO-MAN'95), 5-7 July, 1995, Tokyo.
134: Rawlings, M. et al. (1994). Using virtual reality for machine design. Electronic visualization laboratory. university of Illinois, Chicago, http://www.evl.vic.edu/research/template-res-project.php3?indi=102.html (20/12/2001).
135: Rezende, D. F., Planejamento de Processo de Fabricação Assistido por Computador Através de um Sistema Especialista Baseado na Tecnologia de Features: Um Modelo de Desenvolvimento Voltado Para a Realidade Industrial, Dissertação de Mestrado, UFSC, 1996.
136: Salomons, O.W. Computer Support in the Design of Mechanical Products. Twente, 1995. Tese (Doutorado em Projeto Mecânico-Ferramentas Computacionais de Suporte). University of Twente.
137: Salomons O.W., Houten F.J.A.M. van, Kals H.J.J., Review of research in feature-based design, Journal of Manufacturing Systems, Vol.12, no.2, 1993, 113-132.
138: Salomons O.W., Slooten F. van, Houten F.J.A.M. van, Observations from redesign and process planning practice, a study of human practice aimed at improving feature based CAD/CAPP, proceedings of the Twelfth International Conference on CAD/CAM, Computer Graphics and Computer Aided Technologies (MICAD'93), Vol. 1, Editions Hermes, Paris, 9-12 February, 1993, pp 115-129. (Also: internal report PT 452).
139: Salomons O.W., Kappert J.H., Slooten F. van, Houten F.J.A.M. van, Kals H.J.J., Computer support in the (re)design of mechanical products, a new approach in feature based design, focusing on the link with CAPP, IFIP Transactions B-11, Knowlegde Based Hybrid Systems, Mezger I., Bertek P. (eds.), Elsevier Science Publishers B.V. (North Holland), 1993, pp 91-103.
140: Schilling, K., Roth H. and Lieb, R., 1997, Teleoperations of Rovers - From Mars to Education, IEEE International Symposium on Industrial Electronics, Portugal, July 12-16, pp. 257-262.
141: Shah, J. J., Mäntylä, M., Parametric and Feature-Based CAD/CAM: Concepts, Techniques, and Applications, John Wiley & Songs Inc, New York, 1995.
142: Shah, J. J., Dedhia H., Pherwani V. e Solkhan S., Dynamic Intergacing of Apllications to Geometric Modeling Services Via Modelar Neutral Protocol, Computer-Aided Design, 29(12_, 811-824, 1997.
143: Shah J.J., Rogers M.T., Functional requirements and conceptual design of the feature-based modelling system, Computer Aided Engineering Journal, Febr. 1988, 9-15.
144: Shah J.J., Rogers M.T., Feature Based Modeling Shell: Design and Implementation, Computers in Engineering Conference (CIE), San Francisco, 1988, 255-261.
145: Shah J.J., Bhatnagar A.S., Group technology classification from feature-based geometric models, Manufacturing Review, Vol.2, No.3, September 1989, 204-213.
146: Shah J.J., An assessment of features technology, CAM-I report P-90-PM-02 , 1990.
147: Shah J.J., Philosophical development of form feature concept, CAM-I report P-90-PM-02 , 1990, 55-70.
148: Shah J.J., Mathew A., Experimental investigation of the STEP Form-Feature Information Model, Computer-Aided Design, vol.23, no.4, 1991, 282-296.
149: Shah, Jami J., Rogers, Marty T. and Urban, Susan D., Engineering data management: achieving integration through database technology, Computing and Control Engineering Journal, june 1993, pp. 119-126
150: Shah J.J., Rogers M.T., Assembly modeling as an extension of feature based design, Research in Engineering Design, Vol. 5, 1993, 218-237.
151: Shah, J.J. e Mäntÿla, M., "Advances in Feature Based Manufacturing", Elsevier, 1994.
152: Shah J.J., A heterogeneous, active database architecture for engineering data management, Int. J. Computer Integrated Manufacturing, Vol.7, No.5, 1994, 276-293.
153: Shen W. & Norrie D. H. (2001) "Agent-Based Systems for Intelligent Manufacturing: A State-of-the-Art Survey" (http://imsg.enme.ucalgary.ca/ ).
154: Sheridan, T. B. Supervisory Control of robot systems. IEEE Conference on Robotics and Automation, San Francisco, CA, 1986.
155: Sheridan, T. B. Telerobotics, Automation and Human Supervisory Control. MIT Press, 1992.
156: Smith, C. S., The Manufacturing Advisory Service: Web Based Process and Material Selection, Tese de Doutorado, Mechanical Engineering, University of California, Berkeley, 1999.
157: Smith, C. S., Wright, P. K., Cybercut: A World Wide Web Based Design to Fabrication Tool, 2000, http://cybercut.berkeley.edu.
158: Spatial Technology, ACIS Geometric modeler, Boulder, Colorado, 1994.
159: Steinel, H., ``Development by Remote Control: VW operates the test bench in Mexico from Wolfsburg'', Real Times, 2, 2001.
160: STEP, ISO TC184/SC4/WG5, Express language reference manual (ISO 10303, part 11), release draft, Spiby P. (ed.) , 1991.
161: STEP, ISO TC184/SC4/WG5, Express-I language reference manual (ISO/WD 10303-12), working project draft, Wilson P. (ed.), 1992.
162: STEP, ISO TC184/SC4/WG5, Industrial automation systems- product data representation and exchange, (ISO/WD 10303-part 48: Form features), 1992.
163: Souza, A. I., 2000, "Implementação de uma Interface de Teleoperação da Máquina AutoCut 2.5L MCS-520 Utilizando a Internet como Via de Controle", Projeto de Conclusão de Curso, GRACO - Grupo de Automação e Controle, UnB, Brasília.
164: Sun, 1999. "The Java Tutorial". Disponível na Internet via WWW. URL: http://java.sun.com/docs/books/ tutorial/index.html.
165: Sun, 1994, "Sun Video User's Guide".
166: Taylor, K. & Trevelyan, J., 1995, "A Telerobot on the World Wide Web", National Conference of the Australian Robot Association, Melbourne, July 5-7, http://telerobot.mech.uwa.edu.au.
167: Tönshoff, H.K., Aurich, J.C., Baum, Th. Configurable Feature-Based CAD/CAPP System. Proceedings of the IFIP International Conference on Feature Modeling and Recognition in Advanced CAD/CAM Systems. Valenciennes, France, p.757-769, 1994.
168: Tornincasa, S., Web3D Technology applications for distance training and learning: the Leonardo project WEBD, XII ADM International Conference - Grand Hotel - Rimini Italy - Sept. 5 5th th-7th th, 2001.
169: Tourino, S. G, 2000, "Guiagem de Robô Móvel XR4000 para Inspenção de Tubulações Industriais Soldadas Via Internet", Projeto de Conclusão de Curso, GRACO - Grupo de Automação e Controle, UnB, Brasília.
170: TMR Show Report. (1998). AUTOFACT97: Virtual manufacturing has become a reality. Lionheart Publishing, Atlanta. http://www.lionhrtpub.com/tmr/showreviews98/122697autofact.html (20/07/00).
171: Ullman D.G., Dietterich T.G., Stauffer L., A model of the mechanical design process based on empirical data, Artificial Intelligence for Engineering, Design, analysis and manufacturing, vol.2, 1988, 33 - 52.
172: Van't A.H., Generative Computer Aided Process Planning for Part Manufacturing - An Expert System Approach, PhD thesis, University of Twente, Enschede, 1985.
173: Vin L.J. de, Vries J. de, Streppel A.H., Kals H.J.J., PART-S, a CAPP system for small batch manufacturing of Sheet metal components, Manufacturing Systems, (proceedings of the CIRP Seminars), Vol. 22, No. 2, 1993, 133 - 141.
174: Wang, F. C. e Wright, P. K., Web-Based CAD Tools for a Networked Manufacturing Service. Proceedings of DET'98 ASME Design Engineering Technical Conference, Atlanta, Georgia, CIE-5517, 1998.
175: Wang M-T., An object-oriented feature-based CAD-CAPP-CAM integration framework, Advances in Design Automation, vol.1, ASME 1991, DE Vol.32-1, 109-116.
176: Wang, H.P. e Li, J.K., Computer-Aided Process Planning, Advances in Industrial Engineering, Vol. 13, Elsevier, 1991.
177: Weinman, W., 1997, "Manual de CGI", Makron Books, São Paulo. Wolf, H. & Froitzheim, K., 1997, WebVideo - A Tool for WWW Based Teleoperation,
178: Waterman, Donald A. A Guide to Expert Systems. 1. ed. Massachusetts : Addison-Wesley, 1986.
179: Wooldridge, M. and Jennings, N. - Intelligent Agents: Theory and Practice. Knowledge Engineering Review, 10(2), 115-152, 1995.
180: Wu, B. Object-Oriented systems analysis and definition of manufacturing operations. International Journal of Production Research, v.33, n.4, p.955-974, 1995.
181: Zaiane, O. R. e Koperski, K., CMPT 354 Database Systems and Structures, http://www.cs.sfu.ca/CC/354/zaiane/, 1998.
182: Zhai, S. Milgram, P., 1991, "A Telerobotic Virtual Control System", Proc. SPIE. Boston.

About this document ...

Estudo Dirigido: TeleManufatura Aplicada a Operações de Usinagem

This document was generated using the LaTeX2HTML translator Version 99.2beta8 (1.43)

The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir25951gV4l5/lyx_tmpbuf2595gNoCbN/capp.tex

The translation was initiated by Alberto Álvares on 2002-05-29

Footnotes

... Álvares ¹: Universidade Federal de Santa Catarina, Departamento de Engenharia Mecânica, Curso de Pós-Graduação em Engenharia Mecânica, Disciplina de Estudo Dirigido, Tema da Tese: Uma Metodologia para Integração CAD/CAPP/CAM Voltada para Manufatura Remota de Peças Rotacionais Simétricas Baseada na Internet (Web), Orientador: Prof. João Carlos Espíndola Ferreira.

Alberto Álvares 2002-05-29