introduçãojeansimao/siteanalytice/analytice-final/... · interoperabilidade entre as ferramentas...

1

Introdução

Nas últimas décadas temos assistido a uma intensificação da automação nas mais

diversas áreas de atividade. Máquinas a controle numérico, robôs e outros equipamentos

programáveis tornaram-se a princípio comuns e, mais recentemente, imprescindíveis na

indústria. A ascenção do capitalismo, a nova organização do trabalho, o consumismo e

diversos outros fenômenos que sucederam a segunda guerra mundial impulsionaram

alterações nas indústrias que se viram obrigadas a responder a um mercado crescentemente

competitivo e em constante mudança.

Os avanços tecnológicos trouxeram tanto soluções aos problemas já existentes como

sugeriram direções de pesquisa e inovação, como exemplificado pelo conceito de fábrica às

escuras, onde seria possível realizar todas as atividades de produção sem nenhuma

supervisão humana. As redes de computadores trouxeram o escritório virtual e com ele o

paperless office; a circulação de informação e documentos pode agora ser digital, eliminando

não apenas os documentos físicos como reduzindo os custos e a mão-de-obra envolvida em

sua manipulação. O setor de serviços também sofreu mudanças, exemplificadas pelos

equipamentos de auto-atendimento que abrangem desde máquinas para venda de

refrigerantes e abastecimento de combustível até caixas automáticos de banco.

A implementação de todas essas possibilidades de utilização de máquinas em nosso

quotidiano não acontece livre de um preço, representado por fatores como a menor oferta de

trabalho e suas sérias conseqüências sociais e as crescentes dificuldades técnicas a serem

superadas na busca contínua por eficiência e redução de custos. Na indústria de manufatura,

foco deste trabalho, como vantagens obtidas da automação podemos citar: aumento de

volume e eficiência de produção, melhora de qualidade dos produtos, maior capacidade de

adaptação da fábrica a novos requisitos de funcionamento e maior agilidade para

acompanhar variações e tendências do mercado. Em contrapartida, para obter todos esses

benefícios é preciso arcar com investimentos iniciais bastante elevados, assumir e

administrar riscos de natureza econômica e técnica e resolver toda uma gama de problemas

específicos de projeto e implementação do sistema produtivo utilizado.

O ciclo de vida de um Sistema Flexível de Manufatura se extende por um número de

etapas que começam pela especificação dos produtos a serem fabricados e terminam com a

2

operação da planta, já instalada. O projeto de FMS envolve um grande número de

informações de tipos diversos, como: dados sobre especificação de produtos e parâmetros de

funcionamento da fábrica; e durante o projeto há uma variedade de problemas a resolver,

como: codificação de programas NC para usinagem de peças e elaboração de algoritmos de

escalonamento e controle. Entre as ferramentas empregadas durante a solução de tais

problemas encontram-se métodos matemáticos ou analíticos em geral, bem como soluções

computacionais que incluem softwares conhecidos pelas siglas CAD, CAM, CAE, etc.

À variedade de tarefas e problemas a serem resolvidos durante o ciclo de vida de um

FMS acrescenta-se a dificuldade de comunicar informações entre todos os elementos que

participam das atividades de projeto, em particular os softwares utilizados. Os dados a

serem intercambiados incluem: modelos de representação de diversos aspectos do FMS tais

como arranjo físico de plantas, famílias de produtos e planos de processo; estatísticas e

estimativas de valores numéricos de desempenho e dados financeiros; formas de retratar

características como flexibilidade e robustez do sistema e diversas outras informações. O uso

intenso de informática em todos esses casos tem evidenciado a necessidade de

interoperabilidade entre as ferramentas computacionais e motivado a criação de padrões

para representação de dados. As pesquisas sobre engenharia concorrente também apontam

a necessidade de integração entre as ferramentas que dão suporte aos trabalhos de todos os

setores de empresa, de produção até engenharia e administração.

Infelizmente as iniciativas de padronização em torno de automação de manufatura e

intercâmbio de dados de projeto são muito recentes. Dessa maneira e exceto por soluções

proprietárias (i.e., fornecedores de sistemas automatizados), as ferramentas informatizadas

aplicadas ao cenário de engenharia de sistemas de produção, em particular FMS,

permanecem isoladas e com capacidades muito limitadas de comunicação. Analisando as

disponibilidades de mercado, encontram-se em geral soluções a problemas pontuais do

projeto e análise de FMS, sendo alguns exemplos softwares de: CAD/CAM; análise numérica

e estatística; pesquisa operacional e otimização; simulação. Estas últimas ferramentas são

muito utilizadas em FMS e estão também entre as mais caras; os simuladores mais

sofisticados têm preços que atingem a casa de dezenas de milhares de dólares.

Dentro desse contexto, desenvolveu-se no CPGEI um ambiente computacional para

apoio ao projeto e análise de FMS, denominado ANALYTICE. Tal ambiente era formado por

módulos de apoio a diferentes atividades de projeto, como: definição de planos de processo,

análise de custos, definição geométrica de peças, simulação com animação gráfica e análise

quantitativa de sistemas, especificação de equipamentos englobando: definição de

geometria, cinemática e modelo comportamental. O ambiente era executado em estações HP

com sistema operacional HPUX.

3

ANALYTICE demonstrou a possibilidade de criar um ambiente computacional de apoio

a engenharia de FMS, pela integração de soluções para as várias atividades de projeto e

análise. O módulo de simulação de FMS era, em certa medida, o componente central do

ambiente, utilizado para validar modelos de equipamentos, simular e avaliar soluções

alternativas enquanto se trabalhava o projeto do FMS nos demais módulos (p. ex., modificar

planos de processo).

Em virtude do grande número de módulos, de suas complexidades internas e de

integração, alguns deles - como os de auxílio ao projeto de arranjo físico e de simulação de

controle de qualidade - não chegaram a ser integrados em ANALYTICE. Na continuação dos

trabalhos, identificou-se a necessidade de utilizar outras plataformas de execução, como

microcomputadores PC, face a ampliação do uso dessa plataforma em relação às estações de

trabalho, o barateamento dos recursos de hardware e o grande aumento do poder de

processamento dos PCs. O interesse em portar ANALYTICE chocou-se com a complexidade e

volume de código da ferramenta e o esforço que seria necessário em realizar tal tarefa.

Atualmente, no CPGEI inicia-se uma nova fase do projeto ANALYTICE, que consiste na

implementação de uma nova ferramenta em microcomputadores PC. Embora o projeto atual

se apóie nos resultados das pesquisas anteriores, representadas por mais de uma dezena de

dissertações de mestrado, a nova arquitetura não guarda semelhanças com a anterior exceto

por características gerais como requisitos quanto a modelagem de FMS e requisitos

funcionais, como presença de recursos de monitoração. Aqui uma vez mais o simulador é a

peça central de toda ferramenta, em torno do qual deverão ser agregados futuros módulos

de definição de arranjo físico, controle e supervisão, entre outros. A importância do

simulador reside no fato de ser o módulo em que serão originados os dados que retratam a

operação do FMS, para análises posteriores. O simulador será, portanto, utilizado com

freqüência durante todo o ciclo de vida, para teste e validação de alternativas de projeto de

FMS.

Neste contexto o presente trabalho tem por objetivo o estudo e desenvolvimento de

um software de simulação de sistemas flexíveis de manufatura com animação gráfica. Para

realização do trabalho identificam-se três áreas principais de estudo:

1) requisitos da simulação em si: envolvem técnicas ou paradigmas de simulação,

especificação de funcionalidade necessária e desejada, algoritmos e estruturas de dados

fundamentais, pontos críticos como gargalos de desempenho;

2) organização do FMS: lógica definida para divisão em sub-sistemas, definição de

possibilidades de implementação de controle (p.ex., comunicação vertical, estrutura

hierárquica ou não) e os reflexos dessas características sobre o simulador; e

4

3) animação gráfica: técnicas de implementação, modelagem da geometria e

cinemática dos equipamentos, formatos de representação interna de tais dados, bem como

conseqüências da inclusão desse recurso na arquitetura da ferramenta de simulação.

O simulador foi desenvolvido em conjunto com o pesquisador Luís F. F. Rosinha que

concentrou seu trabalho na modelagem dos equipamentos de manufatura. Esta dissertação

tem o duplo objetivo de desenvolver a arquitetura de simulação de FMS e incluir o recurso

de animação gráfica no simulador.

O texto está dividido em duas partes; na primeira é apresentada a contextualização

do problema e revisão bibliográfica, nos capítulos 1 - 'Contexto e Objetivos do Trabalho' e 2

- 'Simulação e Animação Gráfica de FMS'; 3 - ‘Antecedentes: ANALYTICE’. Na segunda parte

do texto é descrito o desenvolvimento do trabalho, nos capítulos 4 - 'Requisitos da

Arquitetura'; 5 - 'Implementação da Simulação’; 6 - 'Implementação da Animação Gráfica e

Ambiente Físico’; e 7 - 'Conclusão'.

5

I Parte

Problemática e Revisão Bibliográfica

Contexto e Objetivos do Trabalho 7

1

Contexto e Objetivos do Trabalho

Ao longo deste século a agregação de tecnologia nas fábricas aliada a mudanças

administrativas determinou um aumento de eficiência na indústria. A partir da utilização

mais intensiva da automação iniciando por volta dos anos 60, abriram-se perspectivas para

criação de novos modelos de organização e operação das empresas. Tais modelos se

mostraram capazes de responder a importantes mudanças ocorridas nos mercados

consumidores. Assim, como alternativa às tradicionais linhas de transferência surgiram os

sistemas flexíveis de manufatura ou FMS – Flexible Manufacturing Systems.

Se por um lado um FMS é uma resposta a problemas complexos, como fabricar

simultaneamente produtos diferentes, ele próprio é um desafio do ponto de vista de projeto

e análise. Uma das principais dificuldades consiste em avaliar diferentes soluções de

implementação durante o projeto. Ao lado dos métodos puramente analíticos existe a

alternativa de empregar simulação computacional para obter e avaliar os muitos parâmetros

e variáveis de operação de um sistema desse tipo.

Neste capítulo apresentaremos uma visão geral sobre FMS, dando uma atenção mais

especial aos aspectos relacionados com projeto e avaliação. A simulação computacional será

apresentada dentro deste contexto como uma ferramenta de auxílio ao projeto.

1.1 Introdução

A automação fabril tem suas raízes na Revolução Industrial e na invenção da primeira

máquina de tear algodão, remontando ao século 18 na Inglaterra. Cerca de 30 anos depois -

por volta de 1770 - a máquina a vapor já estava em uso, chegando à América. Em meados

de 1800 uma fábrica de mosquetes criada pelo americano Eli Whitney demonstrou que a

capacidade de fabricar em escala era mais importante do que a qualidade. Isto decretou o

declínio da manufatura artesanal.

"Our Age of Anxiety is, in great part, the result of trying to do today's jobs with yesterday's tools." -Marshall McLuhan

8 Capítulo I

As primeiras linhas de montagem mecanizadas datam de 1913 [5]. Os produtos eram

movimentados por uma esteira mecânica, embora os postos de trabalho ao longo da linha

fossem operados manualmente. As linhas de usinagem surgiram por volta de 1924.

O primeiro protótipo de uma máquina a controle numérico foi demonstrado no MIT

[58] - Massachussets Institute of Technology - em 1952: um torno comandado por uma fita

perfurada. O mesmo princípio de funcionamento havia sido empregado no tear do francês

Jacqard, inventado no século anterior - em 1801. Computadores despertaram cedo o

interesse na área de automação, e a primeira linguagem de programação específica – APT,

Automatically Programmed Tooling – surgiu por volta de 1960. Na mesma época surgiram os

primeiros robôs industriais. A diferença marcante entre as máquinas programáveis e suas

antecessoras que não exibiam essa característica, é a possibilidade de empregá-las para

fabricar produtos diferentes ou facilmente modificar suas operações para acompanhar

mudanças de projeto nos produtos.

Com o tempo, a participação do microprocessador tornou-se mais importante,

evoluindo do controle de máquinas individuais para a integração de grupos de máquinas, e

daí até a coordenação de toda planta de produção [54]. O primeiro sistema flexível de

manufatura, o “System 24” da Molins Company, foi desenvolvido em 1968 [1, 6].

O chão-de-fábrica não foi o único lugar invadido pelas CPU’s. O microcomputador

revolucionou o escritório, fornecendo desde ferramentas básicas de trabalho, como CAD1, até

os meios para compartilhamento de informações e gerência de projeto. Estavam assim

criadas as condições para o surgimento do escritório virtual e do trabalho à distância.

O próximo passo de desenvolvimento seria a integração de todos os níveis da

empresa. Os setores de administração e de produção, anteriormente vistos como dois

universos distintos, passam a ser compreendidos como peças de um sistema único. Essa

integração traz diversas oportunidades de obter ganhos de eficiência em operações da

indústria, como [2]: redução de estoques, a produção just-in-time e a diminuição no ciclo de

vida de produtos. A manufatura integrada por computador, CIM, integra todas as funções de

engenharia normalmente referidas como CAD/CAM, a automação e informatização do chão-

de-fábrica e adiciona a tudo isso as funções de administração empresarial [5].

É claro que o cenário de CIM apresentado pode parecer algo otimista em excesso, já

que a indústria geralmente respeita duas premissas bastante simples que dizem que uma

fábrica: 1) deve funcionar e 2) não pode falhar. Soluções tecnologicamente avançadas não

são adotadas enquanto não se mostrarem absolutamente confiáveis. Entretanto, exemplos

de fábricas com integração e automação bastante sofisticadas se encontram na literatura já

1 Optou-se por não traduzir as siglas originais do inglês, por se tratarem de termos consagrados na

literatura internacional. Um glossário ao final do trabalho relaciona e explica as siglas e termos citados.


há dez anos, como a Allen-Bradley’s Milwaukee facility – uma fábrica totalmente

automatizada com estoque zero [2].

É difícil traçar um limite entre a influência da revolução industrial sobre a organização

do trabalho e do mercado, e a influência destes últimos sobre o desenvolvimento de novas

tecnologias em aplicações industriais. Durante a segunda guerra mundial, por exemplo,

fábricas que puderam se adaptar às exigências do momento (como produzir armas em lugar

de talheres) experimentaram grande prosperidade. Oportunismo e competitividade de

mercado são exemplos de fatores que demandaram avanços tecnológicos. Ao mesmo tempo,

a tecnologia que tornou disponível uma maior variedade de produtos a preços mais baixos

mudou hábitos de consumo. O fato é que as indústrias tiveram que se adaptar a um novo

cenário, onde [62, 65]:

• o tempo de vida de produtos no mercado é cada vez menor,

• a variedade de produtos é crescente, e

• o ambiente de negócios é altamente complexo.

Neste contexto, alternativas como as linhas rígidas de produção não se mostram

apropriadas. Mudar continuamente a estrutura das fábricas não seria factível, simplesmente

pelo custo proibitivo dessa solução. Surgiu assim o conceito de flexibilidade: incorporou-se nos

sistemas de produção a capacidade de adaptação a mudanças com o menor esforço possível.

As novas tecnologias que se desenvolveram permitiram a fabricação de produtos diferentes

utilizando a mesma unidade produtiva.

1.2 Tipologia dos sistemas de produção

Os sistemas de manufatura são tradicionalmente classificados observando-se

dois aspectos [6]: volume de produção e variedade de produtos.

A concepção de uma fábrica pode enfatizar cada uma dessas variáveis com diferente

intensidade. O resultado, em cada caso, é um sistema de produção que responde a

demandas de fabricação bem distintas e que, para isso, utiliza conjuntos completamente

diferentes de máquinas, robôs e programas de controle. A classificação ilustrada na Figura

1.1 a seguir é comum e bastante homogênea na literatura sobre FMS.

A Figura 1.1 está dividida em duas categorias, destacadas por uma linha diagonal: o

flow-shop e o job-shop. Um sistema se enquadra em uma dessas duas categorias

dependendo da variável que lhe seja predominante: volume de produção ou variedade de

produtos. A seguir discutimos as principais características [52] desses sistemas.

10 Capítulo I

Figura 1.1 – Tipologia dos sistemas de produção.

O flow-shop é uma organização baseada no fluxo do processo (i.e., operações) de

fabricação. Pode ser exemplificado pela tradicional linha de produção, onde o produto

percorre um trajeto ao longo do qual estão dispostas as máquinas de manufatura que

realizam as operações da seqüência de fabricação. O caso limite dessa organização é aquele

em que a seqüência de operações é fixa, não admitindo nenhuma variação. O flow-shop é

uma organização relativamente simples, que exibe como características:

• a possibilidade de alcançar elevados volumes de produção;

• provável baixa tolerância a falhas: a quebra de uma máquina pode interromper

todo o processo de fabricação;

• tempo curto para transporte de peças entre as máquinas;

• pequena capacidade de adaptação a mudanças: alterações nas especificações dos

produtos podem exigir modificações significativas no sistema.

O job-shop é quase a antítese do flow-shop. As máquinas são dispostas na fábrica

não mais de acordo com seqüências de operações a realizar, mas conforme as funções que

desempenham. Os diferentes produtos podem seguir diversos roteiros ao sofrerem

operações de fabricação. O fluxo de material é mais complexo, tornando indispensáveis

sistemas eficientes de armazenamento e transporte, além de um controle de processos

adequado. As características principais do job-shop comparativamente ao flow-shop são:

Linhas de Transferência

Linhas de Transferência

Flexíveis

Sistemas Flexíveis de Manufatura

Células Flexíveis

Máquinas Independentes

Número de Produtos

Job-Shop

Volu

me

de

Pro

duçã

o

Flow-Shop


• menor volume de produção;

• provável maior tolerância a falhas: máquinas quebradas podem ser substituídas

alterando os roteiros de produção;

• tempo de transporte de peças mais longo;

• maior capacidade de adaptação a mudanças: um produto diferente pode ser

fabricado, bastando que as máquinas disponíveis possam fabricá-lo e que um

roteiro adequado seja preparado.

As características de Sistemas Flexíveis de Manufatura os fazem ocupar uma

posição intermediária entre os dois anteriores. Ao mesmo tempo em que é desejável que tais

sistemas tenham a flexibilidade do job-shop, utilizando máquinas que trocam ferramentas e

roteiros de produção flexíveis e dinamicamente modificáveis, procura-se alcançar um nível

de eficiência tão próximo quanto possível de um flow-shop, em que a configuração do

sistema é otimizada para fabricar um determinado produto. Tomando por base o que foi dito

sobre flow-shop e job-shop, pode-se dizer que um FMS:

• é uma solução intermediária quanto a variedade de produtos e volume de

fabrico;

• exibe os problemas do job-shop: complexidade de controle e escalonamento, e

sistemas sofisticados para manuseio e transporte de materiais.

1.3 Sistemas Flexíveis de Manufatura

Caracterização geral

É tão difícil explicar o significado de “sistema flexível de manufatura” quanto o de

“manufatura integrada por computador”. Em ambas as expressões existe um número de

idéias e conceitos difíceis de retratar em poucas palavras. Na literatura encontramos várias

definições diferentes, como:

“Flexible manufacturing systems (FMS) consist of a set of numerically

controlled machining centers connected by an integrated material handling

system” [5]

“An FMS is a set of workstations, connected together by communication

links and material handling equipments, all operating under full computer

control.” [4]

“A Flexible Manufacturing System (FMS) may be defined as a system

dealing with high level distributed data processing and automated material

flow using computer controlled machines, assembly cells, industrial robots,

12 Capítulo I

inspecting machines and so on, together with computer integrated

materials handling and storage systems” [8]

As definições citadas variam de acordo com o problema sendo abordado por cada

texto em que ocorreram. Na primeira, o autor apresenta um método para minimizar tempo

de transporte de materiais; na segunda, trata-se de software de controle para FMS. Já o

autor da terceira definição dedica um capítulo de seu livro a questão de processamento

distribuído.

Se deixarmos de lado as definições para examinar apenas o termo FMS, pode-se

compreender seu significado e aplicação.

A palavra “sistema” retrata o fato de que um FMS é composto por elementos que

interagem (computadores e software, máquinas-ferramenta, pessoas, etc.) e que podem

ser agrupados hierarquicamente em subsistemas.

“Flexível” evoca uma idéia essencial em FMS: a capacidade de adaptação. Em

síntese, significa que o sistema é capaz de reconfigurar seus recursos obedecendo restrições

de desempenho [27].

“Manufatura”, do latim facture, “feito com as mãos”, aplica-se tanto a usinagem de

peças quanto a montagem de produtos compostos. Entretanto, é comum empregar o nome

FMS para referir-se unicamente a indústrias de usinagem, reservando a sigla FAS – Flexible

Assembly System – para as fábricas que produzem bens através da montagem de produtos

a partir de componentes elementares.

Um FMS pode ser descrito de duas maneiras [52]: como sendo composto por grupos

de componentes que desempenham uma dada função; ou como uma hierarquia de

subsistemas. No primeiro caso tem-se: máquinas-ferramenta; sistema de transporte e

manuseio de materiais; e sistema de controle. No segundo o FMS é visto através de uma

organização hierárquica [14]. Em um primeiro nível de decomposição o FMS é formado por

células de manufatura. Cada célula é formada por estações e cada estação em geral é

constituída por uma máquina-ferramenta e alguns mecanismos auxiliares, como por

exemplo: um torno, um braço robotizado e um buffer intermediário. Uma célula de

manufatura consiste [11] num conjunto de máquinas-ferramenta, capazes de fazer

determinadas operações de manufatura sobre determinados tipos de peças. Tais operações

podem envolver a fabricação completa ou quase completa de uma peça; ou ainda, serem

aplicadas em diferentes fases de fabricação de várias peças. O sistema de transporte e

manuseio de materiais conecta as células; o sistema automatizado de armazenagem é

utilizado por produtos em estados intermediários de fabricação, e em menor escala por

matéria-prima e produtos acabados.


Na operação de um FMS existe uma série de objetivos a serem atingidos, tais como

[2, 6, 8, 20, 57]:

• minimizar o tempo ocioso de equipamentos de manufatura;

• recuperar os efeitos de quebras de equipamentos através de planos de

contingência;

• garantir cumprimento de prazos de fabricação;

É responsabilidade do software de controle do FMS administrar as atividades de

equipamentos de manufatura e operários de forma a atingir tais objetivos. O controle de um

FMS tem por natureza uma característica distribuída: os próprios equipamentos de

manufatura contam normalmente com um microprocessador interno (CLP, CNC) que lhes

permite realizar algumas tarefas sem intervenção externa (stand-alone), em geral por meio

da execução de programas NC.

Justificativas de implementação

A implementação de um FMS é um projeto de risco [55, 56] havendo dois aspectos

importantes a considerar: financeiro e técnico. Do lado financeiro, os componentes de um FMS

(equipamentos, softwares e recursos humanos) são em geral bastante especializados e caros.

O capital para implementação é elevado, tornando necessário um estudo cuidadoso de

viabilidade e retorno de investimento. Já com relação aos riscos técnicos, é importante garantir

a precisão dos dados estabelecidos na especificação e calculados no projeto do sistema, que

determinam a obtenção ou não dos objetivos esperados.

Os altos custos e os riscos associados com o projeto e a implementação trazem a tona

uma questão relevante: por que não adotar uma alternativa mais simples ou econômica? De

fato, nem sempre um FMS será a melhor solução [6]. De uma forma geral, a tecnologia FMS se

aplica quando automação e flexibilidade são exigidos do sistema de manufatura.

Algumas das vantagens esperadas de um FMS em relação a outros sistemas

produtivos são [6, 8]:

• adaptabilidade: um produto pode sofrer várias modificações e continuar sendo

fabricado na mesma indústria;

• robustez: utlizando recursos redundantes e um controle preparado para enfrentar

falhas, aumenta-se a confiabilidade de operação e diminui-se o custo potencial de

uma parada;

• economia de operação: o escalonamento de produção pode otimizar a alocação

de recursos e reduzir tempo de processamento, atendendo a diversas

combinações ou seqüências de pedidos de fabricação;

• estoque-zero: significa em essência diminuir capital imobilizado, fabricando-se

exclusivamente sob demanda.

14 Capítulo I

1.4 Ciclo de vida de FMS

Existem algumas diferentes metodologias para descrever e modelar um FMS da

especificação inicial de produtos até a implementação e operação, variando de modelos

simples até aqueles incorporando engenharia concorrente [62, 66]. A seguir é apresentada a

descrição encontrada em [12] em que todo esse processo é decomposto hierarquicamente

em níveis. A metodologia ou formalismo utilizado é o SADT – Structured Analysis and Design

Technique [13].

1.4.1 Nível 0 - Ciclo de Vida

O nível zero corresponde à descrição mais geral sobre o ciclo de vida de um FMS. Está

dividido em quatro etapas: especificação, projeto, implementação e operação. A figura a

seguir apresenta essas etapas.

Figura 1.2 – Ciclo de vida de FMS; nível 0 em diagrama SADT.

Especificação do sistema: a especificação é baseada em tipos e características dos

produtos e os respectivos volumes de produção previstos. Estudos sobre mercado,

tendências de consumo, custo de implementação e outros fatores correlatos fazem parte da

especificação. Analisa-se a viabilidade de implantação e conveniência de utilizar um FMS,

face a outras alternativas de sistemas de produção.

Projeto: a partir das conclusões obtidas na etapa anterior e também dados como

restrições de tempo e de capital, inicia-se o projeto em si: seleção de equipamentos,

definição de arranjo físico do chão-de-fábrica, especificação da lógica de controle e

escalonamento, etc.

Especificar

necessidades e objetivos

Projetar

Implementar

Operar

tecnologia disponível

recursos: instalações, equipamentos, etc.

insumos e ordens de serviço

especificação

projeto

FMS implementado


Do projeto podem resultar dados que levem a um retorno à etapa de especificação

para que sejam feitos ajustes e modificações. Por exemplo, adequar volumes de produção a

números que possam ser atingidos com os equipamentos que se pretende (ou que se pode)

adquirir.

Implantação: é a realização física do projeto – a construção da fábrica ou linha de

produção. Como nas demais etapas, durante a implantação podem ser detectadas situações

que exijam retornar a etapas anteriores do ciclo de vida. A redução desse tipo de ocorrência

na implementação é muito desejável pelos custos envolvidos nesses "retrocessos". Existem

determinadas tarefas que não admitem tais correções, como a aquisição das máquina-

ferramentas; daí conclui-se a importância e grau de criticidade do projeto de um FMS.

Operação: uma vez implementado e em funcionamento, um FMS requer basicamente

o tratamento de duas questões: o controle, que trata da operação ou funcionamento em si;

e a gestão que trata questões mais estratégicas como planejamento dsa produção, análise

de lucratividade, eficiência, projetos a longo prazo, etc.

1.4.2 Nível 1 - Projeto de FMS

Na etapa de projeto ocorrem as definições para o FMS. O projeto define os

componentes e estruturação do sistema de produção. É a fase mais longa do ciclo de vida

[29, 52]. Nessa etapa se faz uso mais intenso de modelos e abstrações que nas demais, na

busca de soluções a problemas como distinguir famílias de peças, elaborar planos de

montagem de produtos e elaborar arranjo físico de equipamentos.

Durante o projeto devem ser levados em conta fatores de risco como [33]: custo total

do FMS; cronograma de execução; capacidade de atender alterações em volumes de

produção; e variabilidade de produtos fabricáveis.

Devido a importância do projeto para nosso estudo, vamos aprofundar sua descrição.

O projeto pode ser dividido nas três etapas apresentadas na Figura 1.3 a seguir.

Figura 1.3 – Etapa de projeto do ciclo de vida de FMS.

Projetar produtos e definir famílias


Desenvolver conjunto de

soluções

Escolha de uma solução

famílias de produtos; planos de produção

especificação

e disponibilidades tecnológicas

especificação

conjunto de soluções factíveis

16 Capítulo I

Projeto de produtos e famílias: envolve o projeto detalhado dos produtos:

especificação de toda geometria, dimensões e tolerâncias de peças e determinação de

operações de manufatura; são usados softwares como CAD e CAPP. Os dados gerados

determinam a escolha das máquinas que serão necessárias.

Desenvolvimento de soluções: é a etapa mais complexa, onde são geradas

alternativas de planta de produção. Existe um número razoável de informações que devem

ser simultaneamente consideradas. Para ilustrar as dimensões do problema vamos tomar

apenas duas dessas informações:

• possíveis seqüências de operações de manufatura para fabricar um produto;

• possíveis combinações de máquinas-ferramenta que podem realizar cada uma

dessas seqüências de operações.

A explosão combinatória que resulta da combinação desses dados é da ordem de

[16]: N! * MN , onde

N = número de operações e

M = número de máquinas.

O desenvolvimento de soluções deve combinar essas possibilidades com um conjunto

de restrições já definido em fases anteriores, que inclui: volume de produção esperado;

capacidade do sistema de resistir a falhas (p. ex. utilizando redundância); qualidade

desejada (tolerâncias de fabricação); capacidade para expansões e adaptações do sistema.

1.4.2 Nível 2 - Desenvolvimento de soluções

Dentro do projeto de FMS, a etapa de desenvolvimento de soluções concentra a maior

diversidade de problemas específicos de FMS. A etapa de subdivide em:

Seleção de máquinas e geração de planos de processo: com base nos dados

sobre geometria e tolerâncias das peças e operações de manufatura necessárias, são

selecionadas as máquinas-ferramenta. Nos planos de processo são descritas as operações de

manufatura a realizar em cada produto e as possíveis seqüências aplicáveis.

A identificação de grupos e número de máquinas necessárias corresponde à

aplicação de Tecnologia de Grupo. Tal denominação engloba um conjunto de técnicas que

compreende [10]: tratamento da complexidade inerente ao projeto de FMS; estruturação

dos problemas, como é ilustrado pela definição de células para fabrico de famílias de

produtos; e satisfação das exigências e requisitos estabelecidos nos objetivos do sistema.

Entre os objetivos a atingir estão: identificação de coicidências nos planos de

processo, que permite identificar grupos de máquinas e fluxos de produtos na planta; e


balanceamento de carga de trabalho dos equipamentos, permitindo determinar o número de

equipamentos necessários.

No projeto de estações e o projeto de células os grupos de máquinas são

organizados em estações de trabalho (exemplo típico: uma máquina ferramenta com uma

estação de carga e descarga de peças) e em células flexíveis. No projeto de estações e

células aparece o problema de definição do arranjo físico.

O projeto da planta de certa maneira repete o projeto de células. Neste caso o

arranjo físico deve levar em conta as próprias células, ocorrências de eventuais máquinas e

operários isolados e a integração do sistema de transporte e manuseio de material, bem

como de um sistema de armazenamento.

O desenvolvimento de soluções é apresentado na próxima figura.

Figura 1.4 – Etapa de desenvolvimento de soluções do ciclo de vida

de FMS.

1.5 Problemas ligados ao projeto de FMS

Durante a etapa de desenvolvimento de soluções surgem problemas clássicos em

FMS, resumidamente descritos nos tópicos a seguir.

Selecionar máquinas e

gerar planos de processo

Identificar grupos e quantidade de

máquinas

Projetar estações de

trabalho

Projetar células

Projetar planta


especificação

especificação

especificação

especificação

planos de processo e tipos de máquinas

lista de equipamentos

conjunto de estações

conjunto de células

18 Capítulo I

Arranjo físico [3]: a distribuição física dos equipamentos no chão-de-fábrica

(machine layout / plant layout) afeta a organização do sistema de transporte de materiais.

Por exemplo, um fluxo intenso de materiais entre duas máquinas pode ser tratado

posicionando-as lado a lado ou utilizando um mecanismo de transporte exclusivo, como

esteira ou robô. Entre as variáveis que devem ser consideradas no projeto do arranjo físico,

estão:

• dimensões físicas de cada máquina;

• área de operação circundando a máquina (por exemplo a extensão de alcance de

um braço robotizado);

• exigências específicas, como alimentação de água ou ar, isolamento acústico ou

necessidade de refrigeração;

• fluxos de materiais, ferramentas ou produtos entre as máquinas.

Controle de Qualidade [48]: o projeto do controle de qualidade depende não só da

especificação de tolerâncias geométricas mas também de variáveis como capital disponível

para investimento e volumes esperados de produção. Em cada caso existem diferentes

estratégias e tecnologias aplicáveis. Para exemplificar, o controle de qualidade pode ocorrer

das seguintes formas:

• teste: peças especialmente desenhadas são fabricadas para verificar a precisão

de determinadas operações de manufatura; ou produtos acabados são colocados

em funcionamento para analisar seu comportamento em relação às

especificações de fabricação;

• inspeção: os produtos passam por inspeção manual ou automática e suas

dimensões são comparadas com as especificações de projeto.

A inspeção pode ocorrer fora ou dentro da linha de produção. No primeiro caso, corre-

se o risco de demorar para detectar uma falha enquanto mais peças defeituosas são

produzidas. No segundo, é possível realizar ações corretivas on-the-fly (sem interrupção do

funcionamento); entretanto, a tecnologia envolvida é mais cara.

Escalonamento [7, 72]: o escalonamento trata do sequenciamento das operações de

manufatura dos produtos, e deve satisfazer restrições tais como:

• cargas máxima e mínima de máquinas: limites devem ser considerados, tanto

para atender a picos de demanda como para aumentar a vida útil dos

equipamentos;

• tamanho de buffers intermediários: pontos onde, por exemplo, o regime de saída

de uma máquina pode ser temporariamente maior que o regime de entrada da

máquina seguinte;

• restrições temporais: minimizar tempos de transporte;


• volumes de produção: o escalonamento deve atender a regimes de fabricação

determinados de antemão;

Controle da Planta [15, 60]: o controle do FMS é responsável pela coordenação de

operação dos equipamentos com o propósito de cumprir os objetivos de produção. O controle

pode ser tratado em níveis, desde as operações de máquinas individuais até a operação de

toda a planta de produção. Algumas das funções do controle são o escalonamento, já

discutido, e a recuperação de falhas. As implementações de controle variam de puramente

reativas, podendo ser representadas por máquinas de estados, até aquelas que empregam

decisão baseada em técnicas de inteligência artificial.

Os programas NC de controle de máquinas representam o nível mais básico de

controle e podem ser gerado por ferramentas de CAD/CAM a partir do projeto geométrico

das peças ou produtos a serem fabricados. Não é incomum que tais programas sejam

gerados “manualmente” a partir de tais especificações. Para os níveis superiores, célula,

estação e planta, não existem muitas referências sobre a geração automática de programas

de controle [28]. Algumas técnicas utilizadas na implementação do controle para esses

níveis incluem as Redes de Petri, o simbolismo gráfico GRAFCET e a codificação de

algoritmos em linguagens de programação.

1.6 Medidas de desempenho de FMS

O estudo de um projeto de FMS leva ao mapeamento para uma representação, por

exemplo, matemática. Esta representação é utilizada para derivar medidas que caracterizam

o funcionamento do sistema. A variedade de modelos utilizados oferece diferentes níveis de

detalhe, dificuldades de modelagem e de análise. Na literatura encontram-se abordagens

variando de programação linear até sistemas de equações diferenciais. Alguns dos modelos

são:

• redes de Petri [18, 22, 23, 24, 25];

• redes de filas [53];

• cadeias de Markov [17, 20];

• simulação [19, 20, 21, 26].

Em todos os casos, os dados mais relevantes que se está pesquisando são os

mesmos, como: medidas relacionadas com tempo e volume de produção. As diferenças mais

marcantes entre cada modelo, de modo geral, ficam por conta da complexidade de

representação; das hipóteses e simplificações realizadas, com conseqüente perda de

informação; e da forma como o modelo é tratado, na busca por informações sobre o sistema

real.

20 Capítulo I

A seguir serão apresentados os parâmetros mais significativos sobre a operação de

um FMS, utilizados durante o projeto para orientar sua concepção.

Taxa de produção: na forma mais simples pode ser computado como o número de

peças sendo produzidas por unidade de tempo. É uma medida dita instantânea, retratanto o

FMS num momento preciso de tempo, em operação contínua, sem falhas ou outros eventos

inesperados. A medida pode ser refinada se a fórmula computar dados como:

• probabilidade de uma máquina quebrar;

• tempos gastos com reparação de máquina avariada, tempo ocioso antes de

iniciado o processo de reparo e tempo gasto para dar nova partida ao sistema.

Se houverem máquinas redundantes, podem ser considerados:

• tempo gasto para reconfigurar o sistema; e

• taxa de produção da nova configuração.

Tempo e trabalho em processamento: A soma de matéria-prima estocada e

produtos acabados corresponde a ativo imobilizado, que segundo o conceito de just-in-time,

deve ser tornado o menor possível. As seguintes medidas estão relacionadas com essa

premissa [14]:

• trabalho em processamento: número de peças sendo processadas em um

determinado instante de tempo;

• tempo total de manufatura (manufacturing lead time): intervalo compreendido

entre a entrada de matéria-prima e a saída do produto acabado;

• tempo em processamento: razão entre o lead time e a somatória dos tempos

utilizados efetivamente em operações de transformação do produto (usinagem,

soldagem, etc.);

• índice de utilização: relaciona a taxa de produção a um dado instante com a

capacidade máxima do sistema; ou o tempo ocupado em relação ao tempo total

considerado. O índice pode ser calculado para toda a planta de produção ou para

subsistemas como células, estações ou equipamentos individuais.

Confiabilidade: a medida mais simples é o MTBF (mean time between failures),

tempo médio entre falhas, e representa o comportamento médio em relação a um histórico

de operação. Outra medida é o MTTR (mean time to repair), tempo médio para reparo. Um

terceiro valor pode ser calculado a partir dos dois primeiros: a disponibilidade,

representando a porcentagem do tempo em que a linha de produção estará operacional.

As três medidas apresentadas são bastante simplificadas, pois encaram a linha de

produção como uma entidade monolítica. Isto é um pouco incorreto, uma vez que a falha de

um equipamento de manufatura nem sempre representa uma falha completa do sistema.

Um dos requisitos de projeto de FMS é que o mesmo possa suportar tais ocorrências


mantendo um determinado nível de operação. Para retratar essa capacidade, são

necessárias medidas (fórmulas) mais sofisticadas de confiabilidade.

Flexibilidade: diz respeito a capacidade do sistema de efetuar ajustes para se adaptar

a mudanças internas ou do ambiente externo [9]. Alguns tipos de flexibilidade são [6, 9, 52]:

Tabela 1 - Tipos de flexibilidade em FMS.

Tipo de flexibilidade

Descrição

Máquina uma mesma máquina pode realizar diferentes operações de manufatura

Roteamento diferentes roteiros podem ser empregados para fabricar um mesmo produto

Processo um produto pode ser fabricado seguindo diferentes planos de processo

Produto especificações dos produtos podem ser alteradas sem implicar alteração do projeto do FMS

Volume os produtos podem ser fabricados em quantidades diferentes, atendendo diversas ordens de serviço

Existem alguns trabalhos específicos em torno de medidas de flexibilidade, mas ainda

não há consenso sobre como quantificar essa característica. Alguns dados que podem ser

utilizados são [6]:

• esforço despendido na mudança do sistema entre dois estados; ou

• a queda de desempenho do sistema devido a mudança; ou

• uma medida física de diferença entre dois estados sucessivos; ou

• a combinação de todos os fatores anteriores.

1.7 Análise de FMS

O projetista de um FMS deve atender a um extenso conjunto de requisitos, conforme

discutido nas seções anteriores. Uma vez que não existe um algoritmo para sintetizar

automaticamente o FMS a partir dos dados de entrada, restrições e objetivos a serem

atingidos, atualmente não há outra saída além de evoluir o projeto através de ciclos de

refinamentos sucessivos. O elevado número de possibilidades de projeto obriga à avaliação

de alternativas, quando é preciso verificar entre algumas opções de implementação qual é a

melhor. Além disso, para cada alternativa escolhida para resolver um problema específico

deve-se conhecer quais as implicações no projeto de toda a planta. Por exemplo, a aplicação

de um algoritmo de tecnologia de grupo para definir células de manufatura pode não

garantir que a flexibilidade de volume de produção seja mantida. A mesma situação se

coloca quando se realizam alterações sobre um FMS já existente.

22 Capítulo I

Como os fatores que influenciam o projeto de um FMS são de naturezas bastante

diferentes, as pesquisas relativas a otimização são em geral pontuais, ou seja, examinam o

problema sob ângulos bem específicos [1]:

“... the papers that have been written ... FMS design optimization do not

consider a general framework for design problems, but rather address each

design issue in a separate manner.” (grifo nosso)

Há dois tipos de técnicas utilizadas para investigar parâmetros de operação de FMS:

os métodos analíticos e a simulação computacional.

Os métodos analíticos utilizam representações matemáticas do sistema tais como

modelos estocásticos de seu comportamento. A partir de tais representações são derivados

resultados significativos a respeito do FMS. Dependendo das características do modelo

utilizado, diferentes propriedades do sistema podem ser calculadas. Existem trabalhos que

investigam desempenho médio e máximo; análise em regime estável de operação; em

estado transiente; que modelam ou não falhas, etc. Provavelmente não existe um modelo

analítico único, que possa fornecer todas as respostas a respeito das características de um

FMS. Em alguns casos, os modelos analíticos não capturam toda a informação sobre o

sistema, ou apresentam grandes dificuldades para fazê-lo [19]. Outra limitação diz respeito

à dificuldade de aplicar técnicas analíticas. Quanto mais precisos os dados que se pode

obter, em geral maior é o volume e complexidade dos cálculos necessários. Em alguns casos

não basta utilizar fórmulas prontas, sendo preciso realizar manipulação algébrica como

resolver sistemas de equações diferenciais [17]. É mesmo possível que o sistema seja

intratável por métodos analíticos ou numéricos, ou que estes se revelem muito ineficientes

[29].

A simulação computacional por sua vez busca replicar o funcionamento do sistema,

dentro dos parâmetros fornecidos pelo engenheiro, permitindo a este observar o

comportamento do FMS e extrair informações para análise, inclusive econômica [57]. É o

método mais amplamente usado para análise de FMS [66]. Existem diferentes formas de

extrair e organizar as informações a respeito do sistema real, e de criar o modelo que

posteriormente será implementado. Por exemplo, o modelo e a respectiva simulação podem

ser numéricos, baseados em medidas sobre o funcionamento do FMS e em formulações

matemáticas que relacionam essas medidas. Outra possibilidade é a simulação a eventos,

que é baseada em ações e comportamentos do sistema observados durante sua operação.

Alguns fatores tornam a simulação computacional mais interessante do ponto de vista

deste trabalho são:

• permite boas aproximações da realidade a um custo baixo de abstração e

formulação matemática;


• está próxima da realidade computacional do próprio FMS, permitindo por

exemplo incluir IA utilizada em escalonamento;

• pode abranger engenharia empresarial [67];

• pode ser integrada a outras ferramentas de projeto [64].

Entre as ferramentas de modelagem para simulação estão redes de Petri [24] e grafos

de eventos [30], além de ambientes e linguagens de programação específicos [21, 29, 31,

32].

1.8 Conclusão

A construção de um FMS não é trivial, exigindo conhecimento técnico muito específico

e ferramentas apropriadas de apoio. Neste capítulo apresentamos uma das metodologias

existentes para tratar o ciclo de vida de FMS e discutimos pontos importantes que servem de

motivação para o desenvolvimento deste trabalho.

Em primeiro lugar, implementar um FMS é uma tarefa bastante complexa. A descrição

do ciclo de vida em níveis hierárquicos contendo várias atividades ilustra este fato.

Ferramentas de apoio ao gerenciamento e organização das tarefas são de grande valia,

exemplificando-se com manutenção de cronogramas, seqüenciamento de atividades,

repositórios de dados.

Um segundo ponto é a diversidade de problemas, fontes e tipos de informação

envolvidos. Há os aspectos de natureza financeira e administrativa - comuns a realização de

qualquer empreendimento comercial mas aqui agravados pelo cenário altamente

tecnológico, exigindo atenção redobrada em análise de custo e de alternativas de

implementação. Nos aspectos operacionais do FMS tem-se todo um leque de tópicos que

exigem profissionais e recursos técnicos especializados. Entre os problemas já

exemplificados temos a especificação e projeto dos produtos, a aplicação de tecnologia de

grupo e a especificação de controle e escalonamento.

O terceiro e último ponto a destacar é o papel da informática em todo esse cenário.

Os computadores participam, por um lado, como elementos intrínsecos do FMS, embutidos

em máquinas-ferramenta ou realizando controle e administração; e por outro lado, são

ferramentas essenciais para o projeto, permitindo tratar os vários casos de explosão

combinatória na solução de problemas e oferecendo confiabilidade, precisão e ganho de

tempo na execução de tarefas.

Conforme observamos, existe uma brecha no conjunto de software aplicado ao

projeto e análise de FMS, que é a não disponibilidade de ambientes de soluções integradas

no mercado. Se considerarmos que certos sistemas de produção mais simples, como linhas

24 Capítulo I

de transferência flexíveis, podem ser mapeados para um FMS sob restrições, amplia-se ainda

mais o universo de utilidade para tal tipo de pacote. Outros sistemas em que há fluxos

intensos de material - como transporte e despacho de encomendas e bagagens em grandes

aeroportos - também poderiam tirar proveito de algoritmos para determinação de arranjo

físico, escalonamento e simulação de desempenho. Assim, eventualmente até essa classe de

sistemas também poderia ser mapeada em um FMS.

1.8.1 Objetivos do Trabalho

Dentro da motivação apresentada, desenvolve-se atualmente no CPGEI - Programa de

Pós-Graduação em Engenharia Elétrica e Informática Industrial - uma ferramenta

computacional para apoio ao projeto e análise de Sistemas Flexíveis de Manufatura. Nessa

ferramenta pretende-se dar suporte ao ciclo de vida, com ênfase no projeto da planta de

produção e na obtenção de parâmetros quantitativos de operação do sistema. O primeiro

módulo componente desta ferramenta é um simulador de FMS com recursos de animação

gráfica, no qual o sistema é modelado, entre outras informações, à partir de um catálogo de

equipamentos. Tal catálogo deverá ser flexível, podendo ser expandido pelos usuários

conforme suas necessidades.

O simulador aqui descrito foi implementado em conjunto com o aluno de mestrado

Luís Felipe F. Rosinha. Foram desenvolvidos em comum toda a arquitetura básica de

simulação de FMS e os princípios básicos para a modelagem de equipamentos de

manufatura. O foco neste trabalho é o projeto e implementação da arquitetura, porém tendo

em vista obter um simulador de FMS contendo o recurso de apresentação da animação

gráfica do chão-de-fábrica.

Dado o exposto até aqui, os objetivos deste trabalho são os seguintes:

• estudar técnicas de simulação computacional aplicáveis ao problema;

• estudar técnicas de animação gráfica tridimensional aplicáveis a simulação;

• estudar soluções de inter-operabilidade entre o simulador a ser construído e

ferramentas de CAD; e

• projetar e implementar um software para simulação de FMS incorporando as

soluções desenvolvidas no trabalho.

26 Capítulo II

Simulação e Animação Gráfica de FMS 27

2

Simulação e Animação Gráfica de FMS

Dada a complexidade e extensão das atividades envolvidas no projeto de FMS, um

grande número de empresas e instituições de pesquisa tem procurado desenvolver métodos e

ferramentas computacionais para dar suporte a estas atividades. Porém dada a grande

variedade de informações e problemas envolvidos, não se tem notícia de um software ou

mesmo um conjunto de programas que atuem integrados cobrindo todas as diversas etapas do

ciclo de vida de um FMS.

Entre as ferramentas de projeto e análise de FMS encontra-se a simulação

computacional, empregada especialmente na avaliação de parâmetros de operação e teste

de alternativas de projeto. O recurso de animação gráfica é hoje bastante enfatizado na

simulação e contribui proporcionando uma compreensão mais clara do sistema sob estudo. O

projeto da arquitetura de um software de simulação de FMS oferece diversas dificuldades

inerentes a complexidade de tais sistemas, que são agravadas pela adição do recurso de

animação gráfica.

Abordaremos neste capítulo os conceitos e técnicas de simulação e de animação

gráfica relevantes para implementação de um simulador de FMS, bem como aspectos

relativos à integração dessas técnicas em um software. Algumas ferramentas existentes são

brevemente descritas ao final do capítulo.

2.1 Simulação Computacional

2.1.1 Introdução

A modelagem de um sistema com o propósito de análisar seu funcionamento pode

acontecer em duas situações [68]: quando o sistema ainda não existe fisicamente e se

deseja estimar seu desempenho; ou quando o sistema já está implantado e o interesse é

estudar o efeito que modificações em seus parâmetros operacionais podem acarretar sobre

seu funcionamento. Em ambos os casos o modelo constitui uma simplificação ou idealização

do sistema real.

"The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs." -Joseph Weizenbaum

28 Capítulo II

O modelo é um elemento crítico em simulação: todo aspecto considerado relevante no

sistema real deve estar refletido de alguma forma no modelo dentro de um certo grau de

precisão. Isto abrange dados que caracterizam o estado do sistema e regras de execução do

modelo (e.x., algoritmos) que replicam o funcionamento do sistema. Um exemplo comum de

modelo de simulação é um conjunto de equações diferenciais: as variáveis e seus valores

contém informações representativas do estado do sistema, enquanto as equações contém a

lógica que rege as mudanças daqueles valores ao longo do tempo.

A principal motivação para a simulação é a economia de recursos quando se estuda

um problema - sejam esses recursos financeiros, humanos ou o fator tempo. A construção

de modelos substitui a construção de protótipos ou mesmo a experimentação com um

sistema real, muitas vezes não disponível ou de natureza tal que inviabiliza ou desaconselha

o estudo prático. São exemplos o controle de uma usina nuclear, o controle de tráfego

urbano e ensaios de resistência de estruturas.

Utilizando experimentos de simulação é possível investigar hipóteses sobre o

comportamento de um sistema em diferentes cenários. Os resultados servem para predizer o

funcionamento do sistema em situações reais e podem fornecer feedback necessário para

que projetistas realizem adaptações e modificações no sistema. Um exemplo de aplicação

dessa técnica em FMS seria simular a quebra de diferentes equipamentos e observar como o

controle do FMS recupera a falha.

2.1.2 Simulação aplicada a FMS

Paradigmas de simulação

Os diferentes paradigmas ou técnicas de simulação que se pode aplicar estão

divididos em três categorias principais [29, 40]:

• estática ou dinâmica: dizem respeito ao tempo dentro do sistema. A simulação é

dita estática quando a variável tempo não está presente ou não é considerada,

como acontece nos modelos de Monte Carlo, que são essencialmente estatísticos.

A simulação é dinâmica quando o sistema sob análise evolui (muda de estado)

acompanhando a passagem do tempo;

• contínua ou discreta: são subdivisões da simulação dinâmica. Uma simulação é

contínua quando o estado do sistema sob análise pode ser determinado em

qualquer instante arbitrário de tempo; já na simulação discreta, o tempo é

atualizado em “saltos” e entre duas atualizações do relógio considera-se que

todas as variáveis do sistema mantiveram-se inalteradas;

• determinística ou estocástica: uma simulação é dita determinística quando não

existir nenhum dado randômico dentro do modelo sob estudo;


Uma simulação que seja ao mesmo tempo dinâmica, discreta e estocástica é chamada

simulação a eventos discretos. Existem sistemas que apresentam uma combinação de

características de simulação contínua e de simulação discreta, denominados [29] “combined

discrete-continuous”. Uma situação de modelagem que pode exemplificar a necessidade

dessa combinação é o agendamento de um evento discreto para o momento em que uma

variável contínua do modelo atinja um determinado valor (threshold).

Existem ainda classificações que abrangem outras características, como diferenças de

implementação; por exemplo, simulação distribuída síncrona ou assíncrona. Tais

classificações não fazem parte do escopo deste trabalho.

Paradigma de Simulação aplicável a FMS

Um FMS é um sistema dinâmico. As características de operação e de flexibilidade de

um FMS fazem com que seu comportamento mude ao longo do tempo. Exemplos são

processar diferentes ordens de produção ou adaptar-se a ocorrência de uma falha.

Um FMS é um sistema não determinístico, podendo ser representado em um

modelo estocástico. Situações esporádicas e inesperadas como a quebra de uma máquina

podem ser modeladas por uma distribuição de probabilidades, refletindo fatos observados no

sistema real. Algumas fontes de aleatoriedade num FMS são [17, 29]: tempo entre chegadas

de jobs ou peças; tempo de reparo de uma máquina com falha.

Um FMS pode ser modelado como um sistema discreto, em que as variáveis de

estado sofrem alterações instantâneas. Embora algumas medidas possam ser expressas de

forma contínua, como “produção = 1.4 peças por minuto”, na prática é possível derivar tais

resultados a partir de valores totalizados pela execução do sistema em determinados

intervalos de tempo. Assim, despreza-se o conjunto infinito de estados intermediários para

caracterizar o FMS através de variáveis discretas como: “quantidade de peças fabricadas”. O

estado global pode ser descrito pela união dos estados de sub-sistemas, que podem ser tão

pequenos quanto máquinas individuais, por exemplo: “torno-1 utilizando ferramenta-3”;

“robô-2 processando programa NC-4”.

As características de dinâmica (tempo como variável independente), estocástica

(sistema contém variáveis aleatórias) e descrição discreta do estado, fazem do paradigma

de ‘simulação a eventos discretos’ uma opção mais apropriada para implementar um

simulador. De fato, ferramentas comerciais de simulação e implementações de controle e

supervisão de FMS se enquadram em geral nessa categoria [69].

30 Capítulo II

2.1.3 Simulação a Eventos Discretos

Existe uma verdadeira taxonomia para simulação a eventos discretos, abrangendo

diferentes técnicas de implementação: hardware distribuído ou não, mono ou

multiprocessamento, memória compartilhada ou não, etc. Os conceitos básicos de

funcionamento e terminologia utilizada para descrever as arquiteturas em geral são comuns

[31, 35, 36]. Uma revisão destes conceitos básicos é feita a seguir.

O relógio ou clock é uma entidade do simulador que representa o tempo simulado.

Pode guardar alguma relação de proporção com o tempo físico de execução do modelo, como

uma escala 1:n (1 segundo de simulação = n segundos de tempo real), ou pode ser

atualizado livremente em saltos arbitrários. Em alguns casos manter a relação fixa pode ser

necessário, por exemplo para manter sincronia de geração de imagens de animação gráfica.

Um evento representa uma ocorrência que pode causar uma mudança de estado2.

Possíveis exemplos de eventos numa simulação de FMS seriam a entrada de um bloco de

matéria-prima e a saída de uma peça pronta. Um modelo mais detalhado poderia considerar

como eventos a realização de cada operação de manufatura. Eventos são acompanhados de

time-stamps, i.e., rótulos com a hora em que devem ocorrer. É comum que eventos sejam

gerados com antecedência e agendados em listas.

O estado do sistema é dado pelo conteúdo de um conjunto de variáveis denominadas

variáveis de estado. Em outras palavras, em um instante arbitrário de tempo o conjunto

de valores atribuído a tais variáveis representa o estado do modelo. A complexidade de um

FMS sugere que o modelo de simulação não seja monolítico e que assim as variáveis de

estado possam estar dispersas entre diversas entidades que o compõe. Isso torna viável

acessar, por exemplo, o estado de uma célula ou máquina de manufatura.

Mensagens são trocadas entre entidades dentro do modelo e em geral servem para

notificar a ocorrência de eventos. Em alguns casos as mensagens podem veicular dados

relacionados com a execução da arquitetura do simulador, como informações sobre tempo

simulado para sincronização de CPU’s distribuídas.

As tarefas ou processos modelam o funcionamento do sistema real; as duas

expressões são utilizadas indistintamente. Processos são geralmente ativados por

eventos e durante sua execução variáveis de estado podem ser alteradas e novos

eventos podem ser agendados.

Listas são estruturas de dados presentes em praticamente todos os simuladores a

eventos discretos. Alguns exemplos comuns de listas utilizadas são: 1) processos correntes

2 Estamos evitando a definição em que “um evento é uma ocorrência que (necessariamente) muda o

estado do sistema”, por ser possivelmente restritiva em excesso.


ou prontos: contém os processos que estão em funcionamento a um dado instante, como

uma operação de furação em andamento; 2) eventos futuros: contém uma agenda de

disparo de processos, normalmente ordenados por time-stamp; e 3) processos suspensos:

processos que estão aguardando alguma condição (como liberação de um recurso) para

retornarem à lista de prontos.

Os recursos podem representar elementos abstratos tais como condições lógicas, ou

elementos físicos como máquinas dentro do sistema. Recursos são compartilhados por

entidades dentro do sistema e podem determinar a entrada de processos em listas de

espera, aguardando a liberação de recursos ocupados. Um exemplo seria uma lista de peças

aguardando a oportunidade de serem processadas em uma máquina ferramenta.

Implementação do avanço de tempo

Numa simulação discreta existem duas formas de controlar o avanço de tempo [29]:

• avanço a passo fixo (fixed-increment time advance ou time-slice): o relógio sofre

incrementos fixos. A cada atualização, verifica-se a lista de eventos e executam-

se todos aqueles agendados para um tempo menor ou igual ao indicado pelo

relógio;

• avanço ao próximo evento (next-event time advance): sempre que um evento é

processado, o relógio é atualizado com a hora de ocorrência de tal evento. Este

mecanismo é às vezes denominado event-driven.

Algumas arquiteturas para simulação a eventos discretos são projetadas

especificamente para plataformas que suportam paralelismo, com o propósito de acelerar

sua execução [34]. A simulação neste caso apresenta algumas peculiariedades

especialmente quanto a sincronia de tempo para execução dos processos [37]. Contudo este

caso foge ao escopo deste trabalho.

As duas possibilidades de avanço de tempo mencionadas acima podem ser utilizadas

na simulação de um FMS, mas com diferentes conseqüências:

• passo fixo: os eventos são processados seguindo o incremento fixo do relógio;

isto implica alguma perda de precisão, uma vez que eventos são freqüentemente

processados em hora diferente daquela para a qual foram agendados, sendo

atrasados ou adiantados conforme a política adotada no simulador. A abordagem

de passo fixo era utilizada em ANALYTICE. O problema pode ser amenizado

diminuindo o valor do incremento do relógio;

• próximo evento: esta abordagem não sofre a perda de precisão da anterior e

espera-se uma performance ótima, uma vez que não há processamento

desnecessário (ex., gerar avanços de tempo durante os quais nada acontece).

32 Capítulo II

Entretanto, o avanço de tempo em saltos não homogêneos não é adequado para

animação gráfica.

Pode-se combinar as duas estratégias utilizando avanço ao próximo evento para

processar as mudanças de estado do modelo, inserindo eventos “artificiais” em intervalos

fixos [20] para geração de quadros de animação gráfica.

2.1.5 Modelagem de FMS para Simulação

Há uma diversidade de modelos aplicáveis a sistemas flexíveis de manufatura com o

propósito de realizar simulação de desempenho. Esta seção discutirá alguns desses modelos

orientando a discussão para as características desejáveis da ferramenta que se pretende

implementar.

Os modelos analíticos, mais especificamente os puramente matemáticos como os

sistemas de equações diferenciais, são geralmente utilizados para calcular um conjunto

específico de valores, como por exemplo: volumes de produção face a determinadas

configurações de carga e probabilidades de ocorrência de falhas [17]. Podem ser utilizados

em simulação contínua ou discreta e são altamente confiáveis quanto a precisão de

resultados, mas: i) a interface com o usuário limita-se a saída de valores, tabelas, gráficos,

etc.; ii) sofrem uma dificuldade quando se deseja modificar a configuração do sistema, que

pode implicar a derivação de novas equações para executar diferentes experimentos com o

mesmo FMS.

Cadeias de Markov [20] baseiam-se em reconhecer todo espaço de estados do

sistema e definir as probabilidades de mudanças entre tais estados. Assemelham-se aos

modelos por equações diferenciais quanto a dificuldade de representar o mundo real.

As redes de filas [53] representam uma melhoria em relação aos modelos por

equações pois mudanças de parâmetros ou reconfiguração do FMS - por exemplo adicionar

equipamentos - são situações que exigem manipulações mais simples do modelo, como

apenas alterar uma distribuição de probabilidade de tempo de espera em uma fila ou incluir

um novo servidor. A limitação das redes de filas fica por conta da modelagem que se resume

em essência à fluxos de tarefas, regidos por fatores estocásticos.

Os grafos de eventos e as Redes de Petri [23, 30, 39] permitem criar modelos com,

teoricamente, qualquer nível de detalhe que se deseje. Oferecem a verificação de

propriedades importantes tais como estados não alcançáveis, vivacidade, componentes

conservativos e deadlocks. Aplicando técnicas de análise [70] é possível verificar

características e valores significativos sobre o funcionamento do sistema a um custo

relativamente baixo de esforço de abstração, modelagem e cálculo. Como acontece com os

modelos anteriores, entretanto, modificar o sistema pode ter um impacto grande sobre a


estrutura da rede. Além disso, à medida em que aumenta o nível de detalhamento do

modelo, cresce a dificuldade de representação e análise; uma escolha errada de nível de

abstração facilmente leva a uma rede intratável analiticamente. A título de exemplo, a figura

a seguir [69] traz uma RdP que descreve o comportamento de uma única estação de espera

com buffer. O modelo foi construído para a posterior especificação da supervisão do sistema.

A rede foi simplificada pela remoção dos rótulos dos lugares e transições.

Figura 1.5 – Estrutura da RdP para controle de uma estação [69]. A

rede acima ilustra a complexidade dessa representação para modelar

o controle de um FMS completo.

Os modelos computacionais utilizados em softwares de simulação como Arena e

Taylor baseiam-se principalmente em blocos de funcionalidade pronta, tais como estações de

trabalho ou equipamentos isolados em que se configuram parâmetros de operação como:

capacidade de carga, velocidade de operação ou tempo de setup. Os softwares desse tipo

oferecem a possibilidade de alterar também alguns comportamentos pré-definidos dos

equipamentos. Em alguns casos é possível re-escrever completamente e compilar o código

de um equipamento de manufatura, substituindo o originalmente fornecido pelo fabricante.

Essa abordagem permite ao engenheiro construir rapidamente um protótipo bastante

simplificado de um sistema, com objetivo de analisar características gerais de

funcionamento. Uma análise mais detalhada pode ser efetuada posteriormente, caso se

valide o protótipo inicial, bastando para isso aumentar o nível de detalhe do mesmo.

34 Capítulo II

2.2 Animação

2.2.1 Introdução

Um dos importantes argumentos favoráveis à simulação é a possibilidade de observar o

comportamento dinâmico do sistema sob estudo, favorecendo a compreensão de toda lógica e

funcionamento do mesmo. Para que se atinjam tais objetivos é claro que uma interface

adequada deve estar disponível, capaz de comunicar ao usuário as informações necessárias. A

animação consiste na apresentação do modelo ou do conteúdo de variáveis de estado durante

seu funcionamento simulado, ao contrário do que acontece nos simuladores que são

executados ‘silenciosamente’, apenas emitindo um relatório final de resultados.

O apelo visual da animação - no caso da animação gráfica - aumenta a confiança do

usuário na ferramenta que está utilizando [52]. A observação da operação de um FMS durante

uma simulação permite uma compreensão mais fácil do comportamento geral do sistema,

sendo um apoio importante nas tarefas de especificação, projeto e teste de ítens como:

• arranjo físico da planta;

• caminhos de AGV’s;

• algoritmos de controle e escalonamento;

• dimensionamento de buffers intermediários e outros parâmetros.

A ferramenta AutoMod II ilustra outra possibilidade: o arranjo físico do sistema de

manuseio de materiais pode ser fornecido ao simulador através da própria interface gráfica

[20]. SIMGRAPHICS, um pacote gráfico integrado a SIMSCRIPT, fornece funções

semelhantes [21].

A integração entre simulação e funções de projeto - como ilustrado pelo exemplo de

AutoMod - é altamente desejável por agilizar as tarefas de projeto. Nesse contexto, onde se

procura integrar as diversas tarefas de projeto de FMS, a animação gráfica tem se revelado

um recurso de muito interesse. A interface visual favorece não só a comunicação

computador-humano, mas também o trabalho de toda equipe de projeto [64]. A partir daí se

descortina um novo estágio, que é evoluir da simulação do processo de manufatura com

objetivo único de obter medidas de funcionamento, para, através da animação, oferecer o

realismo de apresentar detalhadamente a fábrica em operação:

“The use of all these tools shows that 3D simulation is on the way to real-

time graphic simulation for use in virtual environments” [63].

A animação não é, infelizmente, um recurso que se possa empregar para verificar ou

validar formalmente um modelo. A observação das máquinas simuladas em funcionamento,

como AGV’s em percurso e braços robotizados se movendo, tem nesse sentido um caráter


superficial: pode-se detectar falhas como colisão de equipamentos, mas não se pode

garantir a efetiva coerência das operações sendo realizadas. Para este propósito a animação

serve para uma verificação geral de proximidade entre o mundo real e o modelo,

provavelmente com muito mais conforto e agilidade do que se faria, por exemplo, analisando

a execução de uma Rede de Petri.

Por fim, a animação também pode ser útil em tarefas de treinamento de pessoal na

operação de equipamentos de manufatura visto que:

• é possível realizar o treinamento em qualquer ambiente;

• o mesmo software pode ser utilizado para simular diversas máquinas diferentes,

o que dilui o custo do investimento em sua aquisição;

• ensaios destrutivos de peças, ferramentas e equipamentos podem ser efetuados

a vontade no simulador.

2.2.2 Técnicas de animação

Existem diversas técnicas de animação gráfica [49]: geração de quadros interpolação,

sistemas paramétricos, por script ou acionada por simulação.

Na animação por interpolação devem ser fornecidas a figura ou quadro inicial e a

figura final e o número de figuras intermediárias desejadas. A animação consiste em calcular

os quadros intermediários e apresentá-los em sequência.

Nos sistemas paramétricos a imagem apresentada pelo computador é função de um

número de parâmetros que podem estar expressos em equações matemáticas.

A animação por script é baseada em uma linguagem utilizada para determinar os

movimentos a serem realizados por figuras no monitor. Um exemplo possível de aplicação de

script é a implementação de um jogo de computador.

Neste trabalho nos concentraremos apenas na animação de modelos tridimensionais

de objetos, acionada por simulação.

A animação pode acontecer dissociada da simulação, ou concomitante à esta. No

primeiro caso, durante a execução da simulação são gerados os dados necessários para,

num momento posterior, executar o programa de animação e apresentar o resultado no

monitor [20, 61]. A principal justificativa para esta estratégia é contornar a insuficiência de

poder de processamento para realizar as tarefas simultaneamente. No segundo caso (de

execução paralela) as funções de animação podem estar integradas ao simulador, ou serem

executadas pela comunicação de dados e comandos a partir do simulador a outro programa

responsável pela animação. A execução paralela exige maiores recursos de máquina mas

oferece maior agilidade ao usuário nos ciclos de visualização de um experimento e

reconfiguração do FMS para novos testes.

36 Capítulo II

As primeiras implementações de animação gráfica empregavam recursos bastante

limitados. Com o correr do tempo o aumento de poder de processamento combinado com

baixo custo trouxe melhoras significativas na qualidade de apresentação. As interfaces

evoluiram de gráficos construídos em modo texto a ícones em modo gráfico. Em seguida

utilizaram-se bitmaps estáticos, representações bidimensionais móveis dos equipamentos e

depois modelos geométricos tridimensionais cada vez mais realísticos. Os estudos mais

recentes estão na direção da imersão do usuário em ambientes virtuais [63] onde até

mesmo efeitos sofisticados como texturas, iluminação e sombras são incluídos. Tais recursos

são bastante exigentes em poder de processamento, via de regra exigindo o uso de

hardware específico como placas aceleradoras gráficas [71].

2.2.3 Modelagem geométrica

A modelagem geométrica consiste em abstrair em um modelo de representação a

forma de objetos do mundo real. Existem modelos que, além de informações sobre

geometria, incorporam dados como densidade e resistência de materiais, sendo utilizados

por exemplo em análises de dinâmica em robótica e cálculos estruturais em engenharia civil

ou mecânica.

No presente trabalho o foco está em representações computacionais que permitam a

animação de movimentos de sólidos. Isto permitirá representar um equipamento de

manufatura como um conjunto de sólidos geométricos.

Algumas características desejáveis para a representação de sólidos são [50]:

• acurácia: a proporção de erro entre a representação do objeto e as dimensões

reais deve estar dentro de limites aceitáveis;

• domínio: o modelo deve representar todas as possibilidades de forma e dimensão

dos sólidos que se pretende estudar;

• unicidade: é desejável (às vezes essencial) que exista um único modelo abstrato

possível para cada objeto do mundo real;

• validação: deve ser possível verificar as propriedades da representação (como

consistência e não ambiguidade);

• fechamento: a aplicação de operações (rotação, translação e escala) sobre o

modelo deve resultar em um novo modelo também válido;

• eficiência de armazenamento (compactness): é desejável que a representação

ofereça precisão de modelagem a baixo custo de armazenamento;

• eficiência de algoritmos: operações como determinar fronteiras e colisões, ou

determinar se um ponto está contido em um sólido, devem ser realizadas com

custo computacional aceitável.


A seguir examinam-se rapidamente os métodos mais comuns de modelagem de

sólidos [45].

Wire-frame: normalmente traduzido como “fio de arame”, o modelo em wire-frame é

composto por vértices e arestas, podendo ser representado diretamente por um grafo. Trata-

se de uma representação simples e de baixo custo de processamento, sendo por isso

freqüentemente utilizada para ecoar dados no monitor durante animação de simulações.

Infelizmente a simplicidade da representação implica algumas limitações sérias, como

impossibilidade de calcular automaticamente e sem ambiguidade área de superfícies e

volumes.

Instanciação pura de primitivas: os modelos são construídos utilizando objetos

primitivos pré-definidos, como: cubo, cone e cilindro. Um objeto é representado instanciando

as primitivas disponíveis e parametrizando-as quanto a dimensões e posicionamento. Não

existe a combinação de instâncias de objetos, o que dificulta a formação de objetos mais

complexos.

Enumeração espacial: pode ser exemplificada pela apresentação de imagens na tela

de um computador: o plano é discretizado através de uma retícula, e os pontos que fazem

parte da imagem são nela assinalados. No caso de modelagem em três dimensões,

determina-se uma retícula ou grade também em três dimensões, formada por células

cúbicas. Um sólido será representado no modelo pelas células que ocupa.

Esta representação é bastante ineficiente quanto ao uso de memória, tendo sido

aprimorada através do desenvolvimento de octrees. Ao utilizar octrees o espaço é

recursivamente dividido em cubos cada vez menores. A divisão recursiva é usada com mais

profundidade apenas nas regiões do espaço em que houverem mais detalhes a capturar. O

objeto é então representado através de uma árvore contendo apenas as células que dele

fazem parte. A representação do objeto real continua sendo aproximada, embora

teoricamente seja possível atingir qualquer nível de precisão desejado. O consumo de

memória é melhorado em relação à representação utilizando uma matriz tridimensional de

células cúbicas.

Decomposição em células: o objeto é representado por uma lista de células, como

acontece na enumeração espacial. Entretanto, as células podem ter qualquer forma desde

que não tenham furos.

Representação por arrasto: É realizada através da determinação de uma figura no

plano, e em seguida pela aplicação de operações de rotação ou translação no espaço. O

volume ocupado pela figura durante a movimentação determina o sólido geométrico. Apenas

objetos que exibam simetria podem ser representados. O exemplo típico de uso desse

38 Capítulo II

método é a geração de sólidos de revolução. Este esquema é algumas vezes denominado de

representação em dimensão 2 e ½.

Geometria Sólida Construtiva: objetos são representados em modelos CSG

(constructive solid geometry) utilizando-se três tipos de operação: 1) instanciação de

primitivos sólidos parametrizados; 2) operadores de conjunto: união, interseção e diferença;

3) operadores de movimento: rotação e translação. Objetos são representados em árvores

onde as folhas são primitivos (ex.: cubo) e os nodos intermediários são operações.

Uma árvore CSG é definida da seguinte forma:

<árvore-SCG> ::=<primitivo> |

<árvore-SCG> <operador de conjunto> <árvore-SCG> |

<árvore-SCG> <operador de movimento>

<primitivo>::= cubo, esfera, cilindro, paralelepípedo ...

<operador de conjunto>::= união, intersecção, diferença

<operador de movimento>::= rotação, translação

Representação por fronteira: a representação através de b-rep se baseia na

determinação das fronteiras do sólido. Neste esquema o objeto é dividido em um número

finito de faces; cada face é formada por arestas e estas são definidas pelos seus vértices.

Os modelos em CSG e em b-rep (boundary representation) são bastante comuns,

especialmente em ferramentas CAD. Algumas destas ferramentas aplicam

concomitantemente os dois modelos.

2.2.4 Modelagem Cinemática

A cinemática trata do posicionamento e movimentação de objetos [50]. Dentro da

robótica, enfatiza-se “o estudo da geometria dos movimentos de manipuladores” [59]. Para

os propósitos de animação gráfica de FMS o estudo de robôs é importante por apresentarem

uma grande variabilidade de arranjos cinemáticos.

Para efeito de animação deve-se distinguir, na representação tridimensional de um

equipamento, os componentes ou partes móveis do mesmo e os parâmetros segundo os

quais os movimentos acontecem.

Há dois tipos de transformações geométricas e correspondentes formas de

implementá-las mecanicamente [41]: a rotação, executada por meio de eixos de revolução

(ou rotação); e a translação, implementada utilizando-se eixos prismáticos. O arranjo mais

comum dos elementos móveis de um robô é a cadeia cinemática aberta simples.

Mecanicamente, constitui-se de uma seqüência de elementos móveis ligados entre si através

de eixos de um dos tipos mencionados, ficando livre a extremidade no fim da seqüência.


Quando tal extremidade sofre alguma influência como o contato com uma superfície que

impede sua livre movimentação, diz-se que a cadeia cinemática está fechada.

Devido ao interesse em aumentar a precisão de posicionamento dos efetuadores de

robôs, face a variações da carga transportada, efeitos de vibração e desgaste entre outros,

em alguns casos são adotados arranjos mecânicos especiais para as juntas. Um exemplo é o

robo Yazukawa [41], no qual há quatro juntas rotativas ligadas por um paralelogramo de

barras metálicas, que definem uma subcadeia cinemática fechada. Tais arranjos tornam um

pouco mais complicada a representação da cinemática envolvida. Ilustraremos e

discutiremos a situação com a Figura 2.1 a seguir.

Figura 2.1 - Construções mecânicas de um robô

Todas as juntas apresentadas na figura são rotativas e têm um motor acoplado.

Analisaremos primeiro o “robô A”. Supondo que acionemos o motor da junta-a, teremos

como resultado: uma rotação aplicada sobre o segmento 1; o mesmo ângulo de rotação

aplicado sobre o segmento 2; uma translação sobre o segmento 3, propagada até a garra do

robô. Se agora acionarmos o motor da junta-c, teremos: uma rotação aplicada sobre o

segmento 1; o mesmo ângulo de rotação aplicado sobre o segmento 2; uma translação

aplicada sobre o segmento 3, propagada até o segmento 4 e à garra do robô. Este arranjo

mecânico não corresponde à uma árvore na representação computacional, o que é

evidenciado pelo fato do acionamento da junta-c implicar o movimento tanto do segmento 3

quanto dos segmentos 1 e 2; neste caso seria preciso utilizar um grafo de representação.

Compare-se com o segundo arranjo, “robô B” apresentado na figura: ao acionar qualquer um

dos motores, a rotação resultante será propagada para os segmentos inferiores (em direção

às folhas da respectiva árvore), e apenas para aqueles.

3

12

1

2

3

junta-a junta-b junta-a

junta-b

junta-c

junta-c junta-d

Robô-A Robô-B

40 Capítulo II

Pela maior simplicidade da representação e dada a suficiência para os objetivos de

modelagem deste trabalho, adotou-se como estrutura de dados a árvore para representar a

cinemática. Estruturas como o Robô-A da Figura 2.1 podem ser modeladas no simulador

seguindo as etapas: i) considerar cada segmento móvel como um nó cinemático; ii) para

cada junta mecânica, estabelecem-se as equações (implementadas em C++) que

representam a propagação do movimento daquela junta para as demais; iii) a cada junta

corresponderá uma variável do modelo comportamental (do mesmo código C++). No modelo

cinemático será necessário desconsiderar ou a junta-c ou a junta-d, ficando “solta” a ponta

da haste correspondente; o movimento do segmento 2 será realizado apenas para efeito de

animação, alterando diretamente a variável ligada à junta-a ou, respectivamente, junta-b.

Diminuindo o nível de detalhe da representação do equipamento, é possível

simplificar a implementação. O Robô-A de nosso exemplo poderia ser tratado removendo-se

completamente o segmento 2, considerando um único atuador sobre a junta-a e

implementando os cálculos no modelo comportamental como segue:

void CRoboA::move_junta_A (double angulo) { junta_a = junta_a + angulo; junta_b = junta_b - angulo; }

A Figura 2.2 a seguir apresenta um exemplo prático.

Figura 2.2 – Foto, modelo geométrico simplificado e respectiva

árvore cinemática de um robô Motoman SK150. Os nomes das

rotações são os mesmos apresentados no site da empresa.

Na Figura 2.2 é apresentado um robô SK150 da Motoman. Na modelagem geométrica,

eliminou-se a haste traseira que forma a estrutura em paralelogramo. Pode-se observar que

rotação-S

rotação-L

rotação-U rotação-R

rotação-B

rotação-T

L (lower arm) ±70° ; 100°/s

U (upper arm) +35°, -115° ; 100°/s

base do robô

S (turning) ±180°; 100°/s

R (roll) ±350° ; 125°/s

B (pitch / yaw ) ±130° ; 125°/s

T (twist) ±355° ; 200°/s


entre os eixos de rotação L e U mantiveram-se alguns atuadores hidráulicos apenas por

efeito estético; tais elementos estão fixos sobre o link L-U no modelo simulado. Na árvore

cinemática à direita da figura, cada aresta corresponde a uma transformação geométrica e

cada nó contém um conjunto de sólidos. O último nó da árvore, por exemplo, contém apenas

um cilindro sobre o qual é aplicada a transformação de rotação T.

2.2.5 CAD e padrões de intercâmbio de dados

As ferramentas computacionais provavelmente mais difundidas em ambientes

industriais são os softwares de CAD/CAE/CAM. Os primeiros programas desse tipo eram

bastante simples e restringiam-se a funcionar como pranchetas de desenho sofisticadas. A

demanda por novas funções cresceu rapidamente e novas aplicações surgiram. Evoluiu-se do

desenho em duas para três dimensões; em seguida adicionou-se à geometria dados a

respeito dos materiais utilizados, havendo ferramentas que permitem realizar cálculos

estruturais e ensaios simulados de carga; outras geram automaticamente o código NC para

usinagem de peças e há programas que suportam a modelagem de produtos compostos a

partir da agregação de componentes elementares (ou subprodutos).

Cada diferente representação computacional de informações geométricas exibe

características próprias que podem ser mais adequadas a uma aplicação particular. A troca

de informações entre ferramentas de software, muitas vezes entre domínios de problema

diferentes, depende de um esquema ou modelo comum para representação que seja capaz

de preservar a semântica e a precisão dos dados.

O intercâmbio de dados é um ponto fundamental dentro do CIM e é uma necessidade

percebida pela indústria já há bastante tempo. Essa necessidade levou ao desenvolvimento

de padrões e normas para intercâmbio de dados, em especial para a geometria de produtos.

Alguns exemplos de tais padrões são:

• IGES : Initial Graphics Exchange Specification (ANSI Y14.26M)

• SET : Standard d’Echange et de Transfert

• VDA-FS : Verband Der Automobilindustrie - Flächen Schnittstelle

• EDIF : Electronic Design Interchange Format

• STEP : STandard for the Exchange of Product Model Data (ISO 10303)

• “.DXF”: Drawing Interchange Format - padrão AutoCad de troca de dados.

Três dos padrões mencionados são bastante difundidos: “.DXF”, IGES e STEP.

DXF é um padrão de facto. Trata-se do formato de arquivos gravados pelo software

AutoCad, da empresa AutoDesk. É um padrão de representação reconhecido por diversos

softwares do mercado. Arquivos “.DXF” existem em formato de dados binários ou ASCII.

Neste segundo caso, o arquivo tem a aparência de um script.

42 Capítulo II

IGES é uma norma ANSI, sendo a primeira versão – 1.0 – datada de 1981 (ANS

Y14.26M-1981). A versão 5.3 foi aprovada em setembro de 1996, seguindo prescrições da

U.S. Product Data Association (ANS US PRO/IPO-10001996). Permite a troca de modelos

através de wire frame, representações por superfície ou sólidos. Inclui protocolos de

aplicação que permitem que a norma seja interpretada de forma a satisfazer requisitos

específicos de uso.

STEP [43] é uma iniciativa da ISO, com o propósito de substituir IGES, sendo iniciada

por volta de 1984. Mais do que retratar apenas a geometria do produto, STEP se propõe a

padronizar a representação de todos os dados relevantes do produto e necessários à

manufatura:

“... a neutral mechanism of completely representing product data

throughout the life cycle of a product...The completeness of this makes it

suitable not only for neutral file exchange, but also as a basis for

implementing and sharing and archiving.” [51].

STEP é um padrão de grandes dimensões, desenvolvido pela ISO TC184 SC4

(technical commitee 184, sub-commitee 4), subdividido em vários grupos de trabalho, como

[44]: WG2 – Parts Library, biblioteca de peças; WG3 – Product Modeling, modelagem do

produto; e WG10 – Technical Architecture, arquitetura técnica. A título de exemplo, alguns

dos protocolos de aplicação (AP’s) de STEP são:

• Electrical: AP 212 Electromechanical design and installation;

• Ship Building: AP 216 Ship Moulded Forms, AP 217 Ship Piping, AP 218 Ship

Structures;

• Process Plant: AP221 Functional Data and its Representation, AP227 Plant Spatial

Configuration.

O interesse pelo padrão é tal que existem associações de empresas que designam

profissionais e recursos para o desenvolvimento do padrão. Pode-se citar:

• ProSTEP (1982): BMW, Ford, VW, Mercedes Benz, Porsche, Scania, Volvo, IBM,

HP, Bosch...

• GOSET (1989): Peugeot Citroën, Renault, Matra, Dassault, EDF, Aerospatiale,

France Telecom...

A norma STEP permite representar não apenas a geometria de um produto, mas

outros dados tais como: materiais utilizados e suas propriedades; e montagem do produto,

quando composto por peças ou partes.


2.3 Simuladores aplicados em FMS

Os softwares para simulação computacional de sistemas se extendem em um leque

que varia desde linguagens dedicadas a simulação, passando por ferramentas de aplicação

genérica até os pacotes específicos, como simuladores de circuitos eletrônicos. Nesta seção

apresentaremos brevemente quatro softwares de simulação, sendo dois deles de uso

genérico, um terceiro que oferece um recurso semelhante a bibliotecas de aplicação e um

pacote específico para FMS. Como último exemplo, descrevem-se algumas ferramentas de

projeto sendo implementadas em um instituto de pesquisa especializado em sistemas de

manufatura. Integração de softwares e animação gráfica são recursos fortemente

enfatizados neste último caso.

Simprocess

SIMPROCESS é uma ferramenta para simulação baseada em processos, que utiliza

uma linguagem orientada a objetos – MODSIM. O software trabalha com simulações

baseadas em: atividades, ou seja, a modelagem do sistema deve identificar as atividades

executadas no mesmo; e em eventos.

Os blocos ou primitivas de construção de modelos na ferramenta são:

• processos;

• recursos e

• entidades.

A ferramenta gera código C++ legível, além de prover interfaces para bibliotecas

C++. A linguagem MODSIM, utilizada dentro do software SIMPROCESS apresenta como

características principais:

• propósito geral e alto nível de abstração;

• tipagem forte;

• modularidade e estruturação em blocos

Os recursos de depuração da ferramenta correspondem aqueles normalmente

encontrados em ambientes de desenvolvimento de software, além de alguns específicos para

simulação:

• suporte à detecção e isolamento de erros de programação e de simulação

• uso de memória, limites de arrays, referências a objetos e parâmetros inválidos;

• erros em tempo de execução automaticamente acionam o modo de depuração

• apresentação de lista de eventos pendentes e informações sobre uso de memória.

SIMPROCESS provê gráficos de saída em execução, em formatos como pizza e barra.

É possível produzir saídas em arquivos PostScript, para geração de relatórios e outros

44 Capítulo II

documentos. A animação gráfica está integrada com a linguagem, tornando mais fácil sua

implementação, além de oferecer portabilidade. “Objetos de animação” podem ser criados

através de um editor gráfico integrado, ou pela importação de imagens. Tais objetos de

animação podem ser formados por subcomponentes.

Finalmente, através de ODBC3 a ferramenta pode se conectar a bases de dados para

intercâmbio de informações.

A-SIM

A-SIM é um pacote de simulação desenvolvido pelo “Technological Center For

Informatics Foundation – CTI”, de Campinas - SP. A-SIM utiliza o conceito de redes de filas,

operando a eventos discretos. Distingue-se por utilizar uma interface totalmente gráfica (ou

linguagem gráfica) para modelagem do sistema a ser estudado. O usuário utiliza o mouse

para construir o sistema, instanciando elementos como filas e servidores por meio da seleção

de ícones correspondentes. Tais elementos são interconectados e os respectivos parâmetros

são fornecidos. A Figura 2.3 a seguir apresenta a interface do programa durante a

modelagem de um sistema.

Figura 2.3 – Janela do software A-SIM.

As principais primitivas disponíveis para modelagem são:

3 vide Glossário


• gerador: simula a entrada de entidades na rede simulada; são parâmetros de

configuração desta primitiva a freqüência de geração e número máximo de

entidades a gerar

• filas: armazenam entidades até que uma operação, definida na rede, esteja

disponível; alguns parâmetros são: política de ordenação (ex.: FIFO),

comprimento máximo da fila;

• operação: representa um serviço ou operação executado pelo sistema. Deve estar

sempre associada a uma fila. São parametrizados: número de servidores,

duração da operação;

• ação: serve para representar atrasos, transportes, desvios condicionais e

probabilísticos;

Além dos elementos básicos que descrevem o sistema, incluiram-se ainda coletores

de dados e recursos para apresentação de gráficos e relatórios de saída dos experimentos

executados.

Arena

Arena [32] é uma ferramenta bastante modular, aplicável em diversos contextos por

meio de recursos que permitem sua adaptação a cada diferente domínio de aplicação. Seu

projeto é orientado a objetos.

A versão 3.0 de Arena foi liberada em abril de 1997. A versão anterior, 2.0, é

compatível com os sistemas operacionais Windows 95 e Windows NT. Realiza interface com

outros softwares através de ODBC e OLE4, o que permite, por exemplo, trocar informações

com sistemas de controle de chão-de-fábrica. também compatível com Visual Basic e com o

pacote Office da Microsoft. Finalmente, pode ler arquivos com extensão “.DXF” gerados em

ferramentas CAD.

Através de “pacotes de simulação” denominados Application Solution Templates

(AST), Arena auxilia a modelagem de sistemas em áreas específicas, como: sistemas de

manufatura, re-engenharia de processos empresariais e fabricação de circuitos integrados.

Um AST inclui um conjunto de módulos contendo interface com usuário e lógica específica

para uma dada aplicação. Existe desenvolvimento de AST por terceiros, além dos pacotes

fornecidos pelo fabricante de Arena.

Como ferramentas complementares, pode-se citar:

• um analisador de entrada que permite ler dados brutos (como históricos de

produção ou quebras) e encontrar a distribuição estatística mais apropriada a

eles, incorporando-os em seguida na simulação; e

4 vide Glossário

46 Capítulo II

• um analisador de saída, que permite representar e comparar dados resultantes

dos experimentos de simulação.

Taylor II

Taylor II é um pacote específico para a simulação de sistemas de manufatura, da

empresa F&H Simulations. Possui uma linguagem proprietária, a TLI – Taylor Language

Interface, embora também exporte uma interface permitindo ligação de programas do

usuário escritos em linguagens como C e Pascal.

A ferramenta foi construída para usuários não programadores. Através de uma

interface gráfica (baseada em uso de mouse e edição de valores) são construídos os modelos

de sistemas. Entre as diversas primitivas que podem ser usadas estão: buffer, equipamento

(máquina), AGV e esteira. Instanciando objetos e definindo parâmetros (como velocidade de

deslocamento de um AGV) é realizado o modelo. Para exemplificar a flexibilidade da solução,

trilhos de veículos podem percorrer um espaço tridimensional.

Taylor suporta animação gráfica em duas e três dimensões, conforme demonstra a

próxima figura.

Figura 2.4 – Janela do software Taylor.

A modelagem pode ser hierárquica, significando que um modelo pode ser composto

de submodelos denominados de clusters. Diferentes modelos podem importar um mesmo

cluster e utilizar sua lógica.

A simulação pode ser executada com uma duração pré-fixada, ou variável. Neste

último caso podem ser determinadas as condições de parada desejadas pelo usuário.


Segundo o fabricante, ainda estão disponíveis recursos para:

• simulação automática de diversas alternativas de projeto;

• análise de sensibilidade (a um estímulo); e

• determinação de fase de estabilização do modelo simulado (warm-up)

IPA

O “Fraunhofer-Institute for Manufacturing Engineering and Automation”, IPA, é um

instituto de pesquisa localizado em Stutgart, Alemanha, conduzindo diversas linhas de

pesquisa ligadas à engenharia de manufatura e automação. O IPA desenvolveu nos anos 80

o SIMPLE++, uma ferramenta para simulação de fluxos de materiais em FMS. Atualmente

estão em investigação as possibilidades de integração entre as diversas atividades de

projeto e análise de sistemas de manufatura, para isso sendo utilizado um conceito

denominado “modelo de fábrica virtual” [63].

Construiu-se um simulador com animação gráfica que permite imergir o usuário dentro

da planta de manufatura e navegar através dela. Vários usuários podem acessar o ambiente

simultaneamente, interagir entre si e também com objetos. Ferramentas de realidade virtual

deverão ser construídas, permitindo que os usuários possam definir o projeto e a construção

da fábrica, em seguida realizando testes e validação do sistema construído.

Outro trabalho do IPA é o “virtual desktop system” [64]: um sistema computacional

que apresenta um modelo tridimensional de uma planta de manufatura, projetado em uma

parede. A partir da imagem, engenheiros podem interagir entre si e avaliar visualmente o

arranjo físico da planta. Modificações podem então ser realizadas sobre o posicionamento

dos diversos elementos, inserção e remoção de máquinas e configuração de parâmetros

como tempos de espera e tamanhos de buffers. O objetivo do método em pesquisa é a

integração do sistema de apresentação com outras ferramentas, permitindo que

especificação de planos de processo, modelos de simulação, etc., sejam automaticamente

atualizados recebendo dados à partir do desktop.

Em ambas as ferramentas comentadas, além de criar-se um ambiente favorável à

cooperação dos especialistas que atuam na engenharia do FMS, obtem-se a integração dos

diversos softwares utilizados, maior agilidade no fluxo de informações e uma possível

redução de tempo despendido no projeto.

2.4 Conclusão

A simulação computacional é uma técnica muito utilizada para investigar parâmetros

operacionais e diferentes alternativas de configuração de um FMS. Os simuladores são,

assim, ferramentas importantes nas fases de projeto e análise do ciclo de vida.

48 Capítulo II

Uma das características importantes dos simuladores é permitir ao usuário

acompanhar a execução dinâmica do sistema sob estudo. Dessa maneira, além de obter

informações quantitativas na forma de gráficos e relatórios finais de execução, o usuário

pode acompanhar as modificações de conteúdo das variáveis de estado do modelo durante

seu funcionamento simulado. Nos casos em que haja interesse e conveniência, esse recurso

pode ser aprimorado apresentando-se uma animação gráfica do sistema, por exemplo

utilizando gráficos tridimensionais. Algumas pesquisas mais recentes estudam o emprego de

realidade virtual, imergindo o usuário dentro do sistema e permitindo-lhe iteragir com ele.

Um sistema flexível de manufatura exibe um comportamento complexo, representado

por fatores como a operação paralela e independente de diversas células de manufatura e o

número de alternativas de planos de processo que podem ser selecionados pelo

escalonamento. Esses dois fatores contribuem para tornar muito grande o espaço de estados

de um FMS. A animação gráfica auxilia na compreensão do funcionamento do sistema,

possibilitando que projetistas de controle observem e ajustem o comportamento do FMS - por

exemplo simulando falhas e analisando como o sistema se recupera. A mesma tarefa seria

bem mais difícil de realizar com base apenas em saídas numéricas de uma simulação.

O recurso de animação gráfica também tem se mostrado um importante auxílio a

comunicação entre equipes de projeto, funcionando como uma maquete eletrônica sobre a

qual engenheiros podem realizar análises e efetuar modificações que serão imediatamente

visíveis a todos os participantes do trabalho.

A implementação da animação gráfica de FMS exige um projeto específico de

arquitetura de simulação para suportar esse recurso, além do acréscimo dos modelos

geométrico e cinemático dos equipamentos de manufatura.

Antecedentes: ANALYTICE 49

3

Antecedentes: ANALYTICE

3.1 Introdução

Conforme mencionado na introdução deste trabalho, o projeto ANALYTICE é o

antecessor da ferramenta sendo agora construída. Tal projeto reveste-se de grande

importância neste trabalho por ser uma fonte de informações sobre vários aspectos da

simulação de FMS, como: integração do controle, dados relevantes para modelagem de

equipamentos e necessidades funcionais para usuários de um simulador de FMS.

Alguns dos conceitos originais permaneceram os mesmos; contudo a arquitetura do

novo simulador é completamente distinta. Esta seção fornece uma visão geral da arquitetura

de ANALYTICE, a partir da qual serão extraídos diversos requisitos para o projeto do novo

simulador.

3.2 Características Gerais

Em ANALYTICE distingue-se [52]:

• a função de projeto de FMS sendo proporcionada por ambientes de definição e

catalogação de equipamentos, agregação de equipamentos em estações,

estações em células e destas em plantas de manufatura;

• a função de análise, suportada por um ambiente de simulação com animação

gráfica e monitoração de variáveis do modelo.

Além da operação dos equipamentos e do controle da planta, é suportada a função de

simulação de controle de qualidade [48] e um módulo para análise de custos de operação

[29]. Para o controle de qualidade, além de dados sobre as ferramentas utilizadas (como

vida útil), cada peça armazena as medidas geométricas relevantes, alteradas durante sua

usinagem. No caso dos custos de operação, além de informações como custo de aquisição e

índice de depreciação de equipamentos, implementou-se um plano de contas para flexibilizar

a catalogação de custos fixos de operação e administrativos do FMS.

"Those who do not remember the past are condemned to repeat it." -George Santayana

50 Capítulo III

O sistema foi implementado em estações HP, com sistema operacional HP-UX. A

animação gráfica foi programada utilizando a biblioteca STARBASE e para a interface com

usuário utilizou-se MOTIF. Na época da implementação, a plataforma descrita representava

uma opção adequada, especialmente em relação ao poder de processamento requerido.

3.3 Modelagem de Equipamentos

Em ANALYTICE os equipamentos são primitivas de projeto, isto é, os blocos

fundamentais para modelagem de um FMS. Para obter alguma flexibilidade na criação e uso

de um catálogo de máquinas, foi definido um conceito semelhante a um “meta-

equipamento”, denominado classe, a partir do qual seriam especializados equipamentos

“reais”, denominados tipos [47]. No nível classe ficavam em aberto os chamados parâmetros

operacionais, tais como velocidade de deslocamento de um AGV; no nível tipo os valores

para tais parâmetros são atribuídos, sendo acrescentados os modelos geométrico e

cinemático. Assim é possível criar uma classe “esteira de transporte linear” e a partir dela

criar tipos de esteiras com diferentes comprimentos para uso em simulação.

Foram implementados módulos para executar tarefas associadas com a definição de

equipamentos, que são: modelagem geométrica e cinemática; definição e catalogação de

classes; definição e catalogação de tipos; e por fim, simulação de equipamentos.

3.3.1 Dados para modelagem de equipamentos

Um equipamento é descrito por três estruturas [52]:

• modelo comportamental [14], onde se descreve a interface de operação e

processos associados ao equipamento;

• modelo geométrico [46], onde se atribui uma representação gráfica ao

equipamento; e

• modelo cinemático [46], onde se associa partições do modelo geométrico à

processos do modelo comportamental.

O modelo comportamental (um programa em linguagem C) para um equipamento é

definido durante a modelagem de sua classe, enquanto que o modelo geométrico e

cinemático são definidos durante sua instanciação em tipo. Tipo é assim uma especialização

de uma classe de equipamento, utilizado para fixar atributos como velocidade de operação

dentro de um conjunto de máquinas que compartilham o mesmo modelo comportamental.

Um conjunto de dados faz parte da definição de um equipamento [14, 42, 47],

descritos resumidamente como segue.


Interface de Acesso

A interface de acesso de um equipamento era composta por:

comandos: constituem a interface exportada pelos equipamentos para ativação de

suas operações (processos). São parametrizáveis e podem ser acessados diretamente pelo

usuário do simulador ou pelo controle do FMS;

sinais de resposta: sinais que os equipamentos apresentam em sua interface com o

ambiente externo, como dados enviados ao controle indicando conclusão de uma operação;

estados: conjunto de variáveis de estado do equipamento. As variáveis de estado são

mantidas pelo núcleo do simulador. O acesso de leitura e escrita às variáveis é realizado

através de macros em linguagem C, escondendo do usuário a comunicação entre o modelo

comportamental e o simulador.

Modelo comportamental

A simulação de um FMS é realizada pela execução do simulador e dos diversos

programas correspondentes aos equipamentos. Conforme já mencionado, o modelo

comportamental de um equipamento é constituído por um programa em linguagem C. O

“esqueleto” desse programa é gerado por um ambiente de auxílio à definição de

equipamentos, no qual o usuário entrava com informações como: variáveis e seus tipos;

comandos e parâmetros; respostas; processos. Cabe ao usuário, uma vez gerado tal

esqueleto, preencher o código C do modelo, especificando o funcionamento do equipamento

e sua comunicação com o simulador. Esta última função é realizada por meio de macros, tais

como:

E_VAR_ELEM_ESC escreve em uma variável INICIA_PROCESSO inicia um processo (vide seção 3.4) L_PARAM lê um parâmetro

O modelo comportamental compreende os seguintes elementos:

processos: um processo em ANALYTICE é definido como uma atividade que consome

tempo de simulação. São via de regra ligados às operações realizadas pelos equipamentos,

tais como: processo de furação ou de torneamento. Os processos são ativados por

comandos;

variáveis internas: variáveis auxiliares utilizadas dentro do modelo

comportamental; não tem significado para um observador externo da simulação, diferente

do que acontece com as variáveis de estado, já mencionadas;

sinais de interação: permitem diálogo entre os equipamentos para modelar

interações físicas de trocas de peças e paletes e interações desastrosas que possam resultar

52 Capítulo III

na quebra de um equipamento (ex., depositar uma peça em um torno já usinando outra

peça);

geração de quebra: a ocorrência de uma quebra de equipamento é agendada de

acordo com o parâmetro MTBF desse mesmo equipamento, a partir do início da operação do

equipamento.

Durante a simulação de um equipamento é apresentada ao usuário uma interface por

meio de uma janela. A interface é representada por uma rede de Petri, ilustrando os

comandos e respostas e os processos definidos para um equipamento. A Figura 3.1 a seguir

apresenta um exemplo dessa interface [73].

Figura 3.1 – Exemplo de interface em Rede de Petri entre

equipamento e usuário da simulação, expondo o modelo

comportamental de um equipamento.

Na Figura 3.1 pode-se observar na parte superior transições que correspondem à

comandos e respostas do equipamento, enquanto na parte inferior encontram-se os

processos. Em torno da janela encontram-se botões com comandos como parar e reiniciar a

simulaçào.

Modelo geométrico e cinemático.

Os modelos geométrico e cinemático contém os dados necessários para visualização

da animação de um equipamento em operação.

O modelo geométrico é criado em um ambiente especialmente desenvolvido para

ANALYTICE, podendo ser descrito como um micro-CAD. Cada equipamento é dividido em


partes denominadas de “partições”. Uma partição tem um conjunto de sólidos que se move

em conjunto, formando assim uma parte móvel completa na geometria do equipamento.

A Figura 3.2 a seguir apresenta uma tela de definição do modelo geométrico.

Figura 3.2 – Janela de definição de modelo geométrico.

A Figura 3.2 mostra a edição do modelo geométrico de um braço robotizado. A janela

é dividida em partes que apresentam diferentes perspectivas do equipamento sendo

construído.

Já o modelo cinemático, algumas vezes denominado “modelo hierárquico” [46] ou

“modelo de animação” na bibliografia, relaciona as partições do modelo geométrico a

processos do modelo comportamental. Essa relação consiste, em essência, na atualização de

conteúdo de variáveis geométricas codificadas no modelo comportamental pelo usuário da

ferramenta.

A modelagem cinemática também é realizada em um ambiente específico de auxílio a

essa tarefa, criado em ANALYTICE. São definidos os eixos de aplicação das transformações

geométricas e outros parâmetros relevantes.

A Figura 3.3 a seguir apresenta uma janela para definição do modelo cinemático ou

modelo de animação.

54 Capítulo III

Figura 3.3 – Ambiente de modelagem cinemática.

A janela apresentada na Figura 3.3 mostra em sua parte esquerda o modelo

geométrico de um equipamento e à direita a respectiva árvore cinemática. Na parte inferior

da janela aparecem listas de variáveis, de primitivas (sólidos que compõe o modelo

geométrico) e de eixos de transformação.

3.3.2 Equipamentos de manuseio de materiais

Podemos distinguir duas categorias de equipamentos em um FMS: i) equipamentos de

transformação da matéria-prima que realizam operações como usinagem e

ii) equipamentos de manuseio, ou seja, de transporte e armazenamento. Os equipamentos

de manuseio de materiais foram estudados no contexto de ANALYTICE em [47], tendo sido

tratados: trocadores, robôs, veículos de transporte e esteiras.

Os equipamentos de transporte de materiais contém informações de interesse

particular para o projeto de arranjo físico, como capacidade de carga e velocidade de

deslocamento. Para o desenvolvimento do novo simulador interessam especialmente dois

tipos de equipamentos de transporte: veículos (como AGV’s) e esteiras, pois em ambos os

casos existirá um modelo comportamental invariável (o funcionamento do equipamento será

sempre o mesmo), associado a informações de geometria que podem mudar com o arranjo

físico do FMS. No caso de um AGV tem-se uma malha que representa os caminhos que


podem ser percorridos; já para as esteiras a própria forma física do equipamento -

compreendendo a superfície transportadora - pode ser alterada em função do arranjo físico.

Em ANALYTICE a malha de um AGV é representada diretamente no código do controle

do FMS. A partir da definição de um comando adequado na interface do AGV, os dados

necessários para executar um deslocamento - como percorrer uma linha reta ou uma curva

ligando dois pontos - são transmitidos do controle ao equipamento. A execução do comando

acontece pela ativação de um processo, ao término do qual atualizam-se as variáveis de

estado (e posição) do AGV e envia-se um sinal de resposta, informando o controle do final

da operação. A detecção de colisões é possível apenas se implementada no controle - a

única entidade conhecedora do estado e posição de todos os equipamentos.

No caso de esteiras, o estabelecimento de um percurso como um retângulo de cantos

arredondados é realizado também no modelo comportamental do equipamento. Seria

possível mudar as dimensões do percurso usando o mecanismo de parâmetros operacionais

(ao criar um ‘tipo de equipamento’ baseado em uma ‘classe’ - v. início da seção 3.1.2). Já

alterar o formato desse percurso, dentro da ótica de ANALYTICE, dependeria diretamente de

alterações do código do modelo comportamental.

3.3.3 Controle NC

A execução de programas NC foi resolvida por meio da definição de uma linguagem e

da implementação de um interpretador [42]. Esta abordagem justificou-se porque: 1) não se

modelava um processador específico para cada equipamento; 2) a linguagem definida era

simples e o interpretador não consomiria muita CPU na simulação; 3) o projeto do

interpretador era mais simples em comparação a implementação de NC utilizando linguagem

compilada.

A linguagem definida em [42] tem como características:

• 10 registradores inteiros e 10 reais, com operações: zerar, incrementar, atribuir

constante ou resultado de operação aritmética (adição e subtração).

• Salto incondicional e salto condicional, utilizando expressões com registradores e

constantes;

• Interface para utilização dos comandos definidos dentro da estrutura de classe do

equipamento, com até 5 parâmetros; a execução de um comando é tratada pela

sua inclusão na lista respectiva (seção 3.1.3);

• Um comando de aguardar resposta, definido para interromper o fluxo de

programa até que a resposta seja produzida pelo equipamento (provavelmente

pelo término de execução de algum processo);

• Um comando para término do programa;

56 Capítulo III

Além dos ítens descritos acima, é necessário definir o tempo de setup antes do início

de execução do programa, qual a operação realizada e sobre qual peça o programa deve

atuar. Em [48] é descrito o desenvolvimento de um editor voltado a sintaxe para auxílio a

programação NC.

A inclusão de um interpretador repercutiu sobre a seqüência de atividades de geração

de eventos executadas pelo simulador (v. seção 3.1.3). O programa NC é executado até um

comando aguardar resposta ser encontrado, sendo pausado até a resposta esperada ser

gerada. A quebra do equipamento também interrompe o interpretador.

3.4 Execução do simulador em ANALYTICE

A arquitetura de simulação em ANALYTICE coordena as seguintes atividades [52]:

Animação do chão-de-fábrica: permite ao usuário visualizar o estado físico corrente

do FMS para uma validação informal da operação física. Devido ao alto custo computacional

da animação, é possível desativá-la durante a simulação;

Monitoração de variáveis de estado: apresentação numérica ou gráfica do conteúdo

das variáveis que descrevem o comportamento do sistema, permitindo ao usuário monitorar

o estado do sistema durante sua operação. Assim como a animação, pode ser desativada

pelo usuário durante a execução do simulador;

Execução do controle: corresponde à ativação das rotinas de controle e

escalonamento nos diferentes níveis de hierarquia do FMS. Durante a execução do controle

serão gerados comandos para a parte operativa (equipamentos, estações, etc.). Sob o ponto

de vista de execução da simulação o controle do FMS é não-preemptivo: uma vez acionado,

apenas ao término de seu processamento o simulador progride sua execução.

Geração de eventos: responsável pela atualização das variáveis que retratam o

estado atual do sistema e pela simulação da execução das operações físicas dos

equipamentos.

O modelo comportamental dos equipamentos é implementado em linguagem C. A

execução dos equipamentos mantém estreita relação com o núcleo de simulação de

ANALYTICE, onde são armazenadas:

• listas de processos ativos dos equipamentos: contém operações sendo

realizadas pelos equipamentos;

• lista de comandos: direcionados aos equipamentos, sendo originados pelo usuário

- por meio da interface do simulador - ou do controle do FMS;

• lista de respostas: enviadas pelos equipamentos ao final da execução de

processos;


• lista de sinais de interação: sinais de quebra gerados pelo simulador, ou de

interação entre equipamentos (ex.: troca de peças entre equipamentos).

A cada ciclo de simulação as listas são percorridas; para cada registro ativa-se o

modelo comportamental (MC) do equipamento correspondente. Na lista de processos ativos,

ignoram-se aqueles processos para os quais a hora de fim de execução ainda não foi

atingida; nos demais casos, ativa-se o MC do equipamento para atualização de estado,

refletindo o final de execução do processo. A transferência de comandos e respostas entre os

níveis controle e operativo é executada por um 'módulo de troca de informações [60].

3.4.1 Controle de tempo

ANALYTICE executa a simulação em time-slice. Duas variáveis configuradas pelo

usuário desempenham funções vitais na execução do sistema [38, 42]:

• o_int: contém o menor intervalo de tempo possível entre operações sucessivas

executadas no FMS. Operações que ocorram em intervalos menores serão

atrasadas, o que compromete a precisão da simulação. Isto pode ser contornado

diminuindo o valor de o_int , o que consome mais poder de processamento;

• s_int: contém o intervalo de tempo esperado entre dois ciclos de simulação.

A duração de um ciclo de simulação depende das atividades a serem realizadas:

ativação de modelos comportamentais, envio de sinais e respostas, etc. Se a execução do

ciclo ocorreu num espaço de tempo menor que s_int , o simulador entra em estado de

espera até completar tal intervalo. Caso ocorra o inverso, s_int é aumentado

momentaneamente para abranger todo o processamento do ciclo demasiado longo.

A relação entre o_int e s_int permite executar a simulação em ritmos diferentes:

retardado, s_int > o_int ; tempo real, s_int = o_int ; e acelerado, s_int < o_int.

3.4.2 Atividade de Geração de Eventos

A geração de eventos é realizada pelas etapas [42]:

1) atualização dos tempos: adiciona ao valor do tempo atual da simulação um valor

igual ao intervalo de simulação (s_int );

2) geração de quebra: compara os tempos de MTBF dos equipamentos com o seu

tempo de utilização na simulação com o objetivo de gerar possíveis quebras;

3) destruição de processos: remove da lista de processos ativos daqueles cujos

tempos de conclusão tenham sido alcançados. Quando um processo é removido da lista, o

MC do equipamento correspondente é ativado de maneira que os sinais de resposta

apropriados possam ser gerados;

58 Capítulo III

4) execução de programa NC: conforme comentado na seção anterior, esta etapa foi

acrescentada depois da implementação do interpretador NC;

5) criação de processos: envia comandos da lista de comandos para os MC’s dos

equipamentos correspondentes. Durante o processamento de um comando pelo MC é

possível ativar novos processos (na lista).

6) atualização geométrica: realiza uma chamada ao MC para atualizar as variáveis

dependentes do tempo; ex.: posição de um braço mecânico em movimento.

3.5 Controle do FMS

Para o projeto da arquitetura de simulação considerou-se a implementação de um

controle a eventos discretos organizado hierarquicamente. A princípio, os níveis de tal

hierarquia corresponderiam a níveis de estruturação do FMS, seguindo o que foi proposto no

ciclo de vida (seção 1.4.2): equipamentos – estações – células – planta de manufatura.

Em uma descrição geral sobre a arquitetura de controle suportada em ANALYTICE

para realizar uma simulação, podemos enumerar as seguintes características e restrições

[14]:

1) o relação entre um elemento de controle e seus elementos subordinados, ou seja, a

parte operativa, pode ser descrita como mestre-escravo. O diálogo segue as regras: i) o

controle envia comandos; ii) a parte operativa pode enviar: respostas; comunicar falhas ou

solicitar serviços e recursos compartilhados ao controle;

2) elementos de mesmo nível hierárquico não cooperam diretamente, mas sempre

subordinados ao elemento mestre do nível superior;

3) a interação entre o controle de uma camada com os elementos da camada inferior

baseia-se nas informações disponíveis na interface de acesso de tais elementos;

4) um nível de controle opera apenas sobre o nível imediatamente inferior.

A abordagem adotada traz vantagens tanto para o projeto do controle como para a

simulação de FMS. A relação mestre-escravo, por exemplo, auxilia a manutenção de um

estado consistente sobre os dados e atividades da parte operativa pois as informações são

centralizadas na camada de controle. A restrição sobre a comunicação horizontal abrange o

controle e a parte operativa do FMS: adotando-se tal conceito, não se admite que dois

equipamentos troquem dados, a não ser por intermédio do controle. Para simulação isso

significa não haver a necessidade de modelar comunicação de dados equipamento a

equipamento, o que se traduz em um ganho de simplificação do código do modelo

comportamental.

Por fim vale salientar que na implementação do controle de FMS em ANALYTICE

focou-se o conceito de controle reativo: dado um sinal fornecido ao elemento de controle,


este responde imediatamente - sem avanço de tempo simulado - enviando comandos à

parte operativa do FMS.

3.6 Modelagem de FMS

Dentro do ciclo de vida proposto (seção 1.4), adotou-se uma estratégia hierárquica

ascendente para construir o FMS, partindo da seleção de equipamentos para a definição de

estações, depois definição de células e, por fim, da planta. Esta mesma organização

hierárquica é comumente adotada para organizar a arquitetura de controle de um FMS. A

Figura 3.4 a seguir apresenta essa seqüência de projeto e corresponde ao que foi

estabelecido também para ANALYTICE.

Figura 3.4 –Seqüência de projeto de FMS.

A cada nível de agregação corresponde um software para definição e catalogação dos

elementos utilizados. No caso de ANALYTICE haveriam também simuladores especializados

para cada nível, basicamente devido a diferenças no controle em cada caso.

3.7 Conclusão

O projeto ANALYTICE investigou diversos aspectos da simulação computacional de

sistemas flexíveis de manufatura, desenvolvendo-se em várias dissertações de mestrado que

trataram de problemas específicos do ciclo-de-vida de FMS. Na construção do software

ANALYTICE não foram implementados completamente todos os recursos previstos nas

dissertações. Isso se deveu principalmente ao fato das novas pesquisas elencarem requisitos

simulação de equip.

definição de

equipamentos

definição de estações

de trabalho

definição de células

de manufatura

definição de

planta

catálogo de equipamentos

catálogo de estações

catálogo de células

base de dados – planta de produção

simulação de estação

simulação de célula

simulação de FMS

60 Capítulo III

não previstos anteriormente, o que levaria à modificações complexas de código e até mesmo

da arquitetura já implementada do programa.

O funcionamento da arquitetura de simulação, baseada em eventos discretos com

avanço de tempo a passo fixo, dá margem à imprecisões de resultado quando o usuário

configura um intervalo de ciclo de simulação muito longo. A escolha de um intervalo muito

pequeno, por outro lado, pode ser tal que implique ciclos de execução do simulador

desnecessários, resultando em ineficiência. Essa situação pode ser corrigida mudando a

forma de atualização do relógio, de passo fixo, para avanço ao próximo evento. Contudo

esta estratégia requer várias alterações no projeto do simulador de ANALYTICE.

Em duas situações o controle do FMS deve ser utilizado para modelar características

inerentes aos equipamentos de manufatura, durante a construção de um experimento de

simulação: i) na modelagem de malhas de transporte e ii) para realizar trocas de materiais

entre equipamentos.

No primeiro caso - tratamento de veículos - é necessário incluir nos algoritmos de

controle do FMS informações sobre a geometria das malhas de transporte. Isso é necessário

para realizar a atualização de posição de veículos no chão-de-fábrica, tanto para efeito de

animação gráfica como para simulação de tempo despendido pelos equipamentos ao

movimentar-se pelos percursos das malhas.

No segundo caso - troca de peças entre máquinas - a operação também é

implementada explicitamente no controle, principalmente no nível estação. Exemplificando,

isto significa que não basta o controle comandar a abertura da garra de um robô sobre um

torno, sendo preciso também explicitar a transferência de uma peça entre os dois

equipamentos e guardar este dado em uma variável de estado.

Nas duas situações apresentadas o controle do FMS está sofrendo modificações

impostas pela arquitetura de simulação. Seria altamente desejável evitar esse tipo de

ocorrência, modelando as informações necessárias em alguma outra entidade da arquitetura

do simulador.

61

II Parte

Desenvolvimento do Trabalho

Requisitos da Arquitetura 63

4

Requisitos da Arquitetura

A arquitetura de simulação de sistemas automatizados de manufatura, de que trata

esta segunda parte da dissertação, foi concebida como parte de um ambiente computacional

contendo diversas ferramentas, conforme apresentado na seção 1.8.

Ela compõe o primeiro módulo a ser implementado por representar um papel chave no

ambiente, que é prover uma 'plataforma de testes' para o projeto de FMS. Cada diferente

alternativa de arranjo físico, estratégia de controle e escalonamento, conjunto de planos de

processo, etc., poderá ser avaliada quantitativamente pela execução simulada do FMS.

É essencial, portanto, que as interfaces entre o simulador e os demais módulos estejam

definidas de antemão.

Este capítulo descreve os requisitos do simulador. A seção 4.1 mostra as interfaces

entre o simulador e outros módulos da ferramenta de projeto e análise de FMS; a seção 4.2

descreve requisitos específicos da simulação, a seção 4.3 requisitos de animação gráfica e,

por fim, a seção 4.4 apresenta uma visão geral da arquitetura do simulador.

4.1 Ferramenta de projeto e análise de FMS

4.1.1 Visão Geral do FMS simulado

Este trabalho enfatizou desde o início a modularidade na concepção e projeto do

simulador. Esta característica é na verdade um dos fundamentos do sistema, antevendo-se a

futura agregação de novas funções ao ambiente de análise de FMS.

O primeiro aspecto a ser observado neste contexto é a metodologia definida para a

criação de um FMS. A princípio adotou-se a mesma sistemática de ANALYTICE, apresentada

na seção 3.6 e ilustrada na Figura 3.4. Conforme se pode observar nessa figura, o modelo de

simulação do FMS é construído em níveis hierárquicos, sendo que a cada nível corresponde

um simulador específico.

O projeto do novo software se concentrou diretamente no problema de simulação de

planta e, em decorrência, na solução de uma das maiores dificuldades que se apresentava: a

interação física entre os equipamentos. Esta abordagem levou a uma solução única para a

simulação de todos os níveis (de equipamento até planta). Desta maneira, a simulação do

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." -C.A.R. Hoare

64 Capítulo IV

FMS é compreendida como a operação de um conjunto de equipamentos independentes em

paralelo subordinados a um elemento de controle. Assim, é possível ao usuário simular, por

exemplo, uma única célula e seu respectivo controle, ou toda uma planta de produção com

um controle hierárquico. A comunicação dos equipamentos e do controle com o simulador é

realizada por uma API, projetada de forma a distanciar o programador dessas entidades dos

detalhes internos de implementação do simulador. A Figura 4.1 a seguir sumariza esta

solução.

Figura 4.1 – Implementação de diferentes níveis hierárquicos de um

FMS no simulador.

Na Figura 4.1 pode-se ver o simulador utilizando interfaces para troca de dados com

os equipamentos e com o controle que compõem a planta do FMS. O diálogo do simulador

acontece diretamente com os equipamentos de manufatura, não distinguido-se, para esse

efeito, estações e células. Já o controle, do ponto de vista do simulador, consiste em um

módulo de software com o qual são trocadas informações seguindo um protocolo

estabelecido, a exemplo do que acontece com os equipamentos. A organização interna do

controle não é visível ao simulador; implementações monolíticas, hierárquicas ou

distribuídas podem ser utilizadas indiferentemente, desde que o protocolo de comunicação

seja respeitado.

Simulador

Equip. 1 Equip. 2 Equip. 3

Controle de Célula

Simulador

Controle de Célula 1

célula

Controle de Célula 2

Controle de Planta

equip 1

equip 2

equip 1

equip 2

célula 1 célula 2

API


4.1.2 Interface do simulador com outros módulos

O simulador deverá interfacear com outros módulos da ferramenta de projeto e

análise, tanto recebendo informações de definição e configuração de FMS, como gerando

dados de saída.

Além dos equipamentos de manufatura e do controle, já mencionados, é preciso

enumerar ainda outros elementos usados como entrada de informação para definir

completamente um Sistema Flexível de Manufatura. Se considerarmos que dados como

planos de processo, volumes de produção e outras características operacionais possam ser

tratados pelo controle, restarão ainda os seguintes elementos a analisar:

• paletes e peças;

• a disposição ou arranjo físico dos equipamentos; e

• malhas de transporte.

Os paletes são suportes padronizados utilizados para o transporte das peças, sendo

manuseados principalmente pelos equipamentos de armazenagem e transporte. As peças

são objeto da operação do FMS, interagindo com os equipamentos e sofrendo as operações

de manufatura.

A informação sobre arranjo físico estabelece quais equipamentos interagem para

trocas de peças. Existem pelo menos quatro maneiras de resolver o problema de interação

física entre equipamentos:

i) codificando algoritmos de interação diretamente nos equipamentos;

ii) codificando as interações no controle;

iii) fornecendo a informação de arranjo físico por parametrização aos equipamentos,

que executam explicitamente a troca de peças entre si; e

iv) estabelecendo uma interface entre os equipamentos para realizar as interações

físicas, arbitrada por uma entidade externa conhecedora do arranjo físico.

A última alternativa foi adotada, sendo examinada em maiores detalhes no próximo

capítulo, que trata da implementação do simulador.

As malhas de transporte fazem parte da definição do arranjo físico, mas são

informações utilizadas especificamente pelos equipamentos de transporte. Um caminho pode

ser definido estaticamente por um trilho ou uma fita reflexiva instalado no chão; ou pode ser

definido dinamicamente, por malhas de cabos elétricos, energizados separadamente para

estabelecer um percurso. Tais cabos são enterrados e emitem rádio-freqüência; é possível

estabelecer diferentes percursos energizando os cabos desejados e programando cada AGV

para seguir uma dada freqüência. Esta última opção foi adotada no simulador, por mostrar

66 Capítulo IV

maior flexibilidade de configuração. Os detalhes de implementação são examinados no

próximo capítulo.

Como informação de saída da simulação tem-se os dados de desempenho coletados

do FMS, como taxas de utilização de equipamentos, tempos de operação, de permanência de

peças no sistema, etc. Para obtenção desses valores é necessário definir interfaces para

extração das informações dos equipamentos e das peças. Nestas últimas também é

interessante que estejam disponíveis mecanismos para escrita de dados, tornando possível

registrar informações como hora de execução de uma operação de usinagem ou a margem

de precisão com que a mesma foi realizada.

A Figura 4.2 a seguir mostra um DFD (Diagrama de Fluxo de Dados) do simulador,

apresentando os principais módulos com os quais o software realiza interface.

Figura 4.2 - DFD em nível 0 do Simulador

Do arquivo de arranjo físico é obtida a informação de posicionamento dos

equipamentos no chão-de-fábrica. O modelo geométrico de um equipamento é realizado em

um CAD e, em seguida, importado por um programa para definição do modelo geométrico e

cinemático de um equipamento. Tal modelo é utilizado na animação gráfica, pelo simulador,

bem como os modelos comportamentais, gerados a partir de outro módulo. Finalmente, os

dados de saída podem ser armazenados num arquivo de saída para serem analisados por

outro programa.

Simulador

arquivo de definição da planta

definição de arranjo físico

análise de dados

CAD

definição de cinemática

definição de modelo comportamental de

equipamentos

arquivo de dados de saída

arquivo de modelos geométricos arquivo de modelos

geom.+cinemático

arquivo de catálogo de equipamentos

68 Capítulo IV

4.2 Requisitos do simulador

Nesta seção descreve-se os requisitos para o simulador. São apresentados resumos

das discussões em torno das alternativas de implementação e a repercussão que as decisões

tomadas tiveram sobre a arquitetura do software.

4.2.1 Características gerais

O novo simulador preservou diversas idéias oriundas de ANALYTICE, acrescentando

novos requisitos obtidos de uma análise daquele software.

A primeira diferença importante é a definição do hardware de execução do simulador:

microcomputadores compatíveis com PC ao invés de estações de trabalho. A razão para isso,

já mencionada na introdução deste trabalho, é facilitar o uso da ferramenta por empregar

um recurso bastante acessível em termos financeiros e de treinamento e, via de regra, já

disponível na indústria. Após considerar o sistema operacional a ser empregado decidiu-se

pelo Microsoft Windows em virtude da amplitude da base instalada. A disponibilidade de

ferramentas de desenvolvimento no CPGEI e a experiência da equipe envolvida em

programar em tal ambiente também determinaram a escolha desta opção. Para a

implementação foi escolhida a linguagem C++, do mesmo fornecedor do sistema

operacional. As principais razões sustentando esta escolha foram: i) o fato de ANALYTICE ter

sido desenvolvido em linguagem C; ii) a experiência da equipe e as vantagens oferecidas

pelo paradigma de orientação a objetos e iii) a disponibilidade do compilador.

No projeto do simulador enfatizaram-se diversas funções a serem fornecidas ao

usuário, que compuseram a base de especificação do software. Em linhas gerais pode-se

listar as seguintes características principais:

simulação dos equipamentos:

• operações de manufatura, com atenção especial em manter precisão ao replicar

o consumo de tempo em tais operações;

• execução de programas NC;

• interação de um equipamento com: outros equipamentos, peças e paletes,

usuário (para execução direta e imediata de comandos e para forçar falhas) e

controle do FMS;

• facilidades para monitoração de estado interno de equipamentos (conteúdo de

variáveis); mecanismo para implementação de animação gráfica;

• comportamentos pré-definidos: falha (quebra) de equipamento configurada pelo

parâmetro MTBF e processo de manutenção consumindo tempo especificado pelo

parâmetro MTTR;


modelagem de equipamentos de transporte, compreendendo:

• a modelagem comportamental e os requisitos já listados sobre simulação de

equipamentos;

• desenvolvimento de uma solução para representar malhas de transporte e

topologia de esteiras, atendendo aos requisitos discutidos na seção 3.3.2;

animação gráfica:

• apresentação dos equipamentos em funcionamento;

• apresentação de peças e paletes em movimentação no chão-de-fábrica;

• configuração do número de quadros (frames) gerados por segundo;

• não interferência sobre a execução do simulador, pela indução de efeitos como

atraso do relógio e retardo excessivo da execução de experimentos;

monitoração: recurso permitindo que o usuário do simulador acesse, por meio de

interfaces adequadas, o estado de qualquer equipamento sendo simulado. Tal recurso é de

utilidade aos usuários para acompanhamento dos experimentos sendo realizados e obtenção

dos parâmetros de desempenho de equipamentos individuais ou para posteriormente derivar

resultados do sistema como um todo. Dentro da função de monitoração deve-se acrescentar

ainda recursos para:

• apresentação imediata (i.e., durante a execução da simulação) de dados em

tabelas ou gráficos;

• exportação dos dados, por exemplo escrevendo arquivos de saída a serem

utilizados por ferramentas de análise numérica;

controle do FMS: é implementado pelo usuário e conectado ao simulador por meio

de uma interface, como já apresentado (seção 4.1); deveria preservar as seguintes

características de um controle real:

• ser executado em paralelo com a parte operativa, isto é, equipamentos e

operários. Isso expande o conceito de controle reativo adotado em ANALYTICE

(seção 3.5), permitindo por exemplo incluir escalonamento em tempo real no

controle do FMS;

• aproximar o consumo de tempo da execução do controle simulado àquele

apresentado por uma planta real. Exemplificando, se o escalonamento referido na

característica anterior consome um tempo t para execução no sistema real, é

desejável que o relógio no experimento simulado seja atualizado com um valor

condizente (i.e.: dentro de uma determinada precisão).

interação entre equipamentos: recursos disponíveis para modelar ocorrências de

interações físicas para troca de peças e paletes entre equipamentos, além de eventuais

70 Capítulo IV

falhas e quebras de equipamentos por interações indevidas; mecanismos para diálogo e

trocas de dados dos equipamentos ao controle do FMS;

funções gerais de simulação:

• controle sobre a velocidade de execução dos experimentos (retardada, tempo real

ou acelerada);

• exportar interface para o usuário configurar e controlar a simulação (ex.:

comandos de pausa e reinício);

• geração de relatórios;

• geração de mensagens de aviso, etc.

Finalmente, deveriam ser consideradas algumas peculiariedades dos equipamentos de

transporte e manuseio de materiais, principalmente a variabilidade de informações de

geometria. As informações envolvidas são: as malhas de transporte de AGV’s e a topologia

de esteiras, ambas configuráveis durante a definição do arranjo físico de uma planta.

4.2.3 Controle do FMS

A definição de uma API permitiu encarar o controle como uma entidade monolítica

para fins de projeto do simulador. Desde que respeitado o protocolo de comunicação e a

forma de funcionamento estabelecida, é possível ligar quaisquer elementos ao núcleo usando

as API's de equipamentos e de controle. A arquitetura interna de tais elementos - em

especial do controle - pode ser definida conforme as necessidades do usuário, sendo assim

possível implementar abordagens hierárquicas, distribuídas ou outros requisitos que se

façam necessários, como incluir inteligência artificial aplicada a escalonamento. A Figura 4.1

ilustra essa forma de implementação.

Qualquer comunicação originada ou destinada aos equipamentos de manufatura

passa obrigatoriamente pelo núcleo do simulador, que atua assim como um roteador. Todas

as trocas de informação entre controle e equipamento são veiculadas através de eventos,

estabelecendo-se assim um mecanismo homogêneo de comunicação para toda a arquitetura

de simulação. Programando uma interface adequada é possível executar o núcleo de

simulação e os equipamentos simulados em uma máquina e o controle do FMS em outra.

Isto abre a possibilidade de contornar uma eventual falta de poder de processamento para

simular o FMS e seu controle em tempo real.

A restrição feita em ANALYTICE e apresentada na seção 3.5 quanto a não haver

comunicação horizontal foi mantida para o nível de equipamentos. Isto significa que também

o novo simulador não permite o diálogo direto entre equipamentos, exigindo a intermediação

do controle quando isto se fizer necessário.


4.2.4 Equipamentos

Modelo comportamental

Preservou-se o conceito de ANALYTICE de equipamentos como primitivas para o

projeto de FMS. Define-se um modelo comportamental, descrevendo as funcionalidades e

dinâmicas do equipamento. Este modelo é implementado pela codificação de algoritmos em

uma linguagem de programação. Porém uma diferença marcante foi utilizar tipos abstratos

de dados, suportados pela linguagem C++, para encapsular os equipamentos em unidades

independentes: todos os dados e código relativos a cada equipamento foram isolados em

seus respectivos objetos. A partir daí, qualquer informação a respeito de um equipamento,

como a verificação de estado de um processo por um usuário, seria realizada por meio de

requisições à instância do objeto correspondente, por meio de sua interface.

Uma das discussões mais longas da equipe de projeto foi quanto ao uso de Redes de

Petri ou de código para especificação do modelo comportamental dos equipamentos. As

principais justificativas motivando o uso de RdP eram: i) a verificação automática de

propriedades, tais como ausência de deadlock ou de lugares inatingíveis na rede; e ii) uma

provável facilidade ao usuário para compreender o equipamento como sendo uma máquina

de estados, retratada pela rede. Cogitou-se que as RdP seriam particularmente vantajosas

para especificar transições com condições de disparo complexas, como arcos de entrada

oriundos de diversos lugares espalhados pela rede. O código correspondente em um

equipamento equivaleria ao uso intenso de comandos de desvio condicional (IF) com

expressões provavelmente longas. Em contrapartida não houve evidência suficiente para

garantir duas condições básicas: i) que a RdP de um equipamento não se tornasse

exageradamente grande e complicada (elevado número de lugares e arcos, causando

dificuldade de interpretação); e ii) que seria possível modelar um equipamento

exclusivamente por uma RdP predicado-transição extendida com expressões matemáticas

nas transições. Representar os modelos de equipamentos utilizando uma linguagem de

programação, por outro lado: i) garantia de que qualquer comportamento que pudesse ser

expresso como um algoritmo seria representável; ii) por mais complicado que

eventualmente se tornasse o código de um equipamento, tal situação seria manejável por

técnicas bem conhecidas (estruturação, modularização, etc.); e iii) parecia uma exigência

menos complexa que o usuário da ferramenta conhecesse programação de computadores do

que fosse experimentado em Redes de Petri. Finalmente, previu-se que a eficiência de

código executável seria maior do que a de um jogador de rede com um intepretador de

expressões matemáticas embutido. Assim, a alternativa escolhida foi utilizar uma linguagem

de programação.

72 Capítulo IV

Haviam duas possibilidades de modelagem usando programação: ou definir uma

linguagem e criar um interpretador, ou utilizar C++ e compilar equipamentos em bibliotecas

de “linkagem” dinâmica (DLL’s). Em favor da linguagem interpretada estava a possibilidade

de controle total sobre a execução de um equipamento, o que inclui monitorar e evitar

acessos indevidos à memória e chamadas a rotinas e/ou bibliotecas indesejáveis. Esta opção

não se sustentou face à vantagens de C++ como eficiência de execução e poder de

representação, que inclui os benefícios de mecanismos de encapsulamento e herança. A

possibilidade de crashes do simulador devido à erros de codificação ficou relegada a segundo

plano, pesando nessa decisão o fato de que em qualquer uma das abordagens a codificação

de um equipamento exigiria o conhecimento e fidelidade de uso dos conceitos e do

funcionamento da arquitetura do simulador.

Modelos geométrico e cinemático

Nas especificações preliminares do simulador ficou claro que não seria implementado

um modelador geométrico como feito em ANALYTICE. Desta forma seria necessário verificar

soluções para interoperabilidade do simulador com ferramentas CAD comerciais disponíveis e

importação de modelos geométricos conforme necessário. A modelagem cinemática poderia

estar embutida no software de CAD externo, ou os dados deveriam ser posteriormente

agregados ao modelo geométrico.

O detalhamento da problemática de animação gráfica é apresentada na seção 4.3.

Programação NC

Os programas NC são utilizados para diminuir a carga de operações do controle do

FMS, permitindo um certo grau de autonomia na operação dos equipamentos. No projeto do

simulador, encarou-se tais programas como sendo simples scripts, admitindo-se não haver

diferenciação ao comandar a operação de um equipamento diretamente pelo seu console ou

por meio de programação.

Pela inexistência de um único padrão, os fabricantes de equipamentos de manufatura

utilizam padrões diferenciados de linguagens NC. Implementar a programação NC

respeitando essa característica exigiria muito esforço. Para acrescentar um equipamento de

num novo fabricante ao catálogo do simulador, seria necessário que o usuário codificasse um

novo interpretador específico.

A solução para o problema seria padronizar no simulador o tratamento de

programação NC. Cogitou-se que o simbolismo gráfico GRAFCET talvez fosse uma

alternativa, inclusive simplificando a representação de paralelismo e sincronização.

Entretanto, verificou-se que esta opção seria na verdade muito sofisticada; o projeto de um

editor gráfico e especialmente de um interpretador de GRAFCET exigiria muito investimento


de tempo e pesquisa. Concluiu-se que a estratégia empregada em ANALYTICE, de definir e

utilizar uma linguagem interpretada, para implementar a programação NC de qualquer

equipamento, seria adequada. Adotou-se a mesma solução, enumerando-se os seguintes

requisitos como sendo essenciais à linguagem a ser definida:

• possibilidade de acionar qualquer comando da interface do equipamento;

• operadores aritméticos e relacionais;

• desvio condicional e incondicional.

A linguagem foi definida próxima dos mesmos moldes da utilizada em ANALYTICE

[42], sendo examinada em maiores detalhes em [74].

Monitoração de variáveis

A monitoração é uma função a ser desempenhada por um módulo específico do

simulador. Sua implementação está dividida em duas partes:

• nos equipamentos, a implementação consiste em prover um mecanismo - ou seja

uma interface - que permita a uma entidade externa examinar o conteúdo de

determinadas variáveis do modelo comportamental;

• no simulador, é preciso criar interfaces que possibilitem ao usuário selecionar um

equipamento, as variáveis que deseja observar e como os dados devem ser

apresentados ou arquivados. Além disso, deve ser estabelecida uma ligação com

o equipamento monitorado utilizando a interface já referida para extrair os

dados.

Por fim é preciso definir em que instantes é realizada a monitoração. Uma alternativa

simples é realizar amostragens aproveitando a ocorrência do evento de time-slice, gerando

assim novos dados a intervalos de tempo regulares.

Comunicação entre equipamentos

A restrição de que equipamentos não podem se comunicar, já comentada na seção

4.2.3, elimina a necessidade de mecanismos de diálogo direto entre os equipamentos e

restringe o universo de sistemas que podem ser simulados. Observe-se que para executar tal

diálogo seria necessário tornar os equipamentos envolvidos na comunicação cientes da

existência um do outro. Assim, além de especificar uma interface de comunicação, seria

preciso desenvolver uma solução de interconexão por meio da qual fosse possível

efetivamente criar as ligações necessárias. O arranjo físico das máquinas não representa

informação suficiente para resolver o problema, uma vez que tal conexão seria realizada por

cabeamento.

É evidente que a comunicação direta entre dois equipamentos do chão-de-fábrica é

uma alternativa de controle e eventualmente pode ser a estratégia adotada na definição de

74 Capítulo IV

algum FMS. Entretanto, a arquitetura do simulador não foi projetada para suportar

comunicação horizontal entre equipamentos; para realizar o diálogo entre dois equipamentos

é preciso recorrer a solução apresentada na figura a seguir, onde o elemento de controle do

FMS é utilizado como um roteador.

Figura 4.3 – Comunicação horizontal entre equipamentos, realizada

pelo controle do FMS.

Interações físicas entre equipamentos

Uma segunda categoria de interação entre equipamentos, além do diálogo de dados é

a troca de materiais: peças e paletes.

A solução adotada em ANALYTICE consistia na programação de sinais de interação

utilizando a interface das máquinas simuladas. Isto envolvia, uma vez mais, explicitar no

controle tais interações, uma vez ser aquele elemento conhecedor do arranjo físico durante a

execução do FMS.

Decidiu-se adotar uma nova abordagem trazendo a modelagem dos equipamentos

para mais próximo da realidade. Um robô ao abrir sua garra soltando uma peça, não tem

nenhum conhecimento a respeito dos equipamentos à sua volta para “avisá-los” sobre tal

ocorrência. Este raciocínio foi adotado, simplificando-se a implementação da operação pelo

robô pela execução de um comando “SoltarPeça”, ficando a cargo da arquitetura de

simulação verificar se: i) havia uma peça na garra do robô; ii) se tal peça foi depositada em

outro equipamento.

A solução implica explicitar no modelo geométrico os pontos em que um objeto pode

ser colocado em uma máquina, disponibilizando no modelo comportamental alguns

mecanismos para realizar as operações de captura e liberação de objetos. Além disso, um

controle, escalonamento, monitoração, etc.

tratamento de diálogo horizontal

robô-3 torno-1

kernel do simulador

controle do FMS

API


sinal padrão seria estabelecido para avisar a um equipamento simulado sobre a deposição de

um objeto sobre ele.

Os conceitos de classe e tipo de ANALYTICE

A maneira como se orientou o projeto do novo simulador enfraqueceu a idéia de criar

níveis de abstração diferentes para equipamentos. Uma vez que o modelo geométrico de um

equipamento seria agora criado em um CAD e depois importado, criar uma ‘classe’ de robôs

e depois derivar ‘tipos’ parametrizando comprimento do braço, como era sugerido em

ANALYTICE, tornou-se inviável.

Estando o uso da parametrização confinado a algumas medidas dentro dos

equipamentos, como velocidade de deslocamento, entendeu-se que tal mecanismo poderia ser

substituído pela criação direta, no catálogo de equipamentos, daquelas diferentes variedades

disponíveis.

4.2.5 Interface com Usuário

A interface com o usuário permite o controle do funcionamento do simulador,

configuração de alguns parâmetros e acesso aos equipamentos. As funções disponíveis são:

• carga de arquivos de malhas de transporte e carga de equipamentos;

• escrita de arquivo de projeto de FMS5; tal arquivo contém a lista de malhas de

transporte, os equipamentos, suas posições e nomes;

• carga de arquivo de projeto de FMS;

• configuração de número de quadros de animação por segundo a gerar;

• para cada equipamento carregado, uma interface para seleção de variáveis

internas a serem monitoradas;

• para cada equipamento carregado, uma janela para acionamento dos comandos e

visualização de sinais de resposta; caso um comandos tenha parâmetros, os

mesmos são apresentados para configuração em uma janela de diálogo;

• comandos ao simulador: iniciar, pausar, reiniciar e parar.

A implementação do controle do FMS simulado não faz parte do escopo do trabalho. A

interface desse elemento com o usuário deverá ser tratada caso a caso, respeitando-se as

particularidades de cada controle utilizado: comandos e forma de ativação, representação de

indicadores, lâmpadas de aviso, etc.

A janela de interface com um equipamento apresenta uma Rede de Petri, idêntica a

utilizada em ANALYTICE e já apresentada na Figura 3.1. Trata-se de uma solução simples e

5 Ou arquivo de arranjo físico.

76 Capítulo IV

eficaz, permitindo validar o funcionamento do simulador e do catálogo inicial de

equipamentos sendo testados. Para uma versão seguinte e para simulação de um FMS

completo, é recomendável modificar essa solução já que a tela provavelmente ficará poluída

por um grande número de janelas abertas.

Os gráficos e listas de variáveis de monitoração de cada equipamento são

apresentados também em janelas individuais. Como no caso anterior, esta solução se

apresentou como de implementação simples e suficiente para validar o funcionamento do

simulador. É recomendável estudar e implementar um módulo com uma interface ou janela

única, em que o usuário possa escolher os equipamentos e dados a serem coletados, as

formas de apresentar esse dados, programar alarmes condicionais (i.e., disparados quando

uma condição calculada for verdadeira) e configurar relatórios e/ou arquivos de saída a

serem utilizados em ferramentas de análise numérica. Não houve um aprofundamento no

estudo de todas essas características uma vez que as necessidades de monitoração serão

particulares a cada caso de simulação e análise de FMS, como por exemplo: definição de

arranjo físico; testes de escalonamento, etc.

4.3 Requisitos de Animação Gráfica

Distinguimos três problemas relacionados com a animação gráfica neste trabalho:

i) armazenar os modelos de geometria e cinemática dos equipamentos;

ii) definir a arquitetura de simulação de maneira a suportar esta função; e

iii) definir a arquitetura do módulo de animação.

Cada um desses tópicos é discutido nas seções a seguir.

4.3.1 Modelos Geométrico e Cinemático

Forma geométrica dos equipamentos

Ao invés de escrever um pequeno módulo de CAD dedicado ao simulador, como foi feito

em ANALYTICE, decidiu-se utilizar um software de CAD comercial e importar os modelos nele

gerados. Possíveis dificuldades para importação de dados seriam amplamente compensadas

pela economia de recursos e esforço de implementação e pela funcionalidade e precisão

oferecida pelos CAD's disponíveis no mercado. Estes programas são ferramentas obrigatórias

no ambiente de trabalho com FMS e, portanto, facilmente disponíveis. Existem ainda opções de

custo muito baixo como programas comercializados como shareware via Internet, com

recursos suficientes para a modelagem geométrica necessária. Além destes fatores, observe-se

que seria um contrasenso implementar um programa de simulação incapaz de comunicação

com outros softwares utilizados no projeto de FMS, quando afirmamos ser justamente esta


uma das dificuldades - a interoperabilidade - que encontramos ao analisar as ferramentas

existentes.

Outro ponto importante favorável a essa abordagem é a existência de formatos bem

conhecidos para armazenamento de informações geométricas e, mais do que isso, padrões

como os já mencionados IGES e STEP.

A primeira hipótese estudada para intercâmbio de arquivos foi o padrão STEP (seção

2.2.5). Os programas AutoCad e SolidWorks, por exemplo, oferecem a exportação de

geometria em STEP. Ao analizar o padrão, todavia, observou-se que a complexidade de

representação o tornava inconveniente para o propósito de animação. Para exemplificar, na

Figura 4.4 na próxima página é apresentado um modelo geométrico e dois trechos do

respectivo arquivo STEP.

O formato apresentado na figura corresponde à AP203 - Application Protocol 203,

uma parte de STEP em que se define apenas a geometria de produtos. Até onde se pôde

observar em exemplos, na AP203 não são identificados os sólidos que compõem o produto.

Provavelmente devido à precisão envolvida, a representação geométrica é algo complexa;

para a animação geométrica seriam suficientes modelos bem mais simples.

Finalmente, não estavam disponíveis informações sobre como interpretar as

informações gravadas como AP2036.

#5638=QUASI_UNIFORM_CURVE('',1,(#5636,#5637),.POLYL INE_FORM.,.F.,.U.); #5639=EDGE_CURVE('',#4097,#4307,#5638,.T.); #5640=ORIENTED_EDGE('',*,*,#5639,.T.); #5641=ORIENTED_EDGE('',*,*,#4325,.T.); #5642=CARTESIAN_POINT('',(0.50000000000000,19.0,0.0 )); #5643=CARTESIAN_POINT('',(2.0,19.0,0.0)); #5644=QUASI_UNIFORM_CURVE('',1,(#5642,#5643),.POLYL INE_FORM.,.F.,.U.); #5645=EDGE_CURVE('',#4099,#4309,#5644,.T.); #5646=ORIENTED_EDGE('',*,*,#5645,.F.); #5647=EDGE_LOOP('',(#5635,#5640,#5641,#5646)); _________ #6168=ADVANCED_BREP_SHAPE_REPRESENTATION('None',(#6167),#117); #6169=SHAPE_DEFINITION_REPRESENTATION(#118,#6168); ENDSEC; END-ISO-10303-21;

Figura 4.4 – Exemplo de modelo geométrico -“jipe lunar” - e dois trechos do respectivo arquivo STEP. Disponível em www.steptools.com

Decidiu-se então utilizar outro formato, adotando-se arquivos do tipo ".3DS", gerados

pelo programa 3DStudio. A geometria é representada por meshes ou malhas de triângulos,

classificando-se esta representação como b-rep. Cada sólido é constituído por um conjunto

6 Não foi possível adquirir a norma.

78 Capítulo IV

de faces, sendo cada face segmentada em triângulos. Linhas são representadas na mesma

estrutura de dados como sendo um sólido com uma única face contendo apenas dois

vértices.

O formato de arquivo “.3DS” está disponível em diversas ferramentas e é bem

divulgado na Internet, encontrando-se informações sobre sua especificação e mesmo algum

código pronto de leitores de arquivo.

A adoção de um determinado formato de representação não impede que suporte a

novos formatos seja futuramente acrescentado. Isto é visto em mais detalhes na seção

6.3.4.

Pontos de interação física

Para apresentar no vídeo peças e paletes em movimento seguros por garras de robôs,

ou aqueles mesmos objetos depositados sobre esteiras ou outros equipamentos, é necessário

identificar o local, na geometria de cada equipamento, em que ocorre o contato físico entre

objeto e máquina. Essa identificação serve a dois propósitos: primeiro, determinar a posição

em que deve ser apresentado o objeto (ex., peça), enquanto o equipamento opera; segundo,

verificar, na ocorrência de trocas físicas de materiais - como um robô colocando uma peça em

um torno - se não ocorrem erros de posicionamento. Tais erros podem acontecer por falha de

programas NC ou de controle e podem resultar em falha mecânica ou até quebra dos

equipamentos envolvidos.

A implementação dos pontos de interação, bem como exemplos ilustrando o conceito,

serão apresentados na seção 6.3.2.

Modelagem cinemática

Os dados sobre cinemática são representados utilizando uma árvore, conforme

discutido na seção 2.2.4; o mesmo formato (de árvore) é o adotado em ANALYTICE. Um

software específico foi projetado para criar a estrutura de dados a partir do modelo

geométrico e da entrada de dados pelo usuário. Cada nó dessa árvore, correspondendo à

uma partição na nomenclatura de ANALYTICE, contém os seguintes dados:

• conjunto de sólidos; os dados sobre faces e arestas devem estar armazenados e

disponíveis para a posterior apresentação visual;

• eixos de rotação e translação: definindo as referências para realização de

movimentos na animação;

• nome da variável, dentro do modelo comportamental, que contém o ângulo ou a

distância a ser aplicada ao eixo, durante execução da simulação.

Como a modelagem geométrica será realizada em um CAD, os eixos de rotação e

translação devem ser incluídos já durante a execução dessa tarefa, sendo representados por


linhas (segmentos de reta). Não se justificaria criar um software adicional com este

propósito, perdendo-se toda a funcionalidade e precisão já disponíveis no CAD. Durante a

animação gráfica, os eixos são suprimidos da apresentação.

No modelo geométrico devem ser acrescentados ainda os seguintes elementos:

• eixos Z e X: indicando, respectivamente, a orientação vertical e horizontal do

equipamento;

• eixo de escala: permitindo definir as dimensões do equipamento em alguma

unidade de medida. Este dado não está disponível nos arquivos “.3DS”.

Adotou-se o sistema métrico decimal, sendo que em toda a modelagem e simulação

dos equipamentos são usadas as unidades: segundos (tempo), milímetros (distância) e

graus (ângulos).

4.3.2 Geração de eventos para animação gráfica

A solução adotada em ANALYTICE de simulação a eventos discretos exclusivamente

em time-slice, como já comentado (seção 3.7), produzia imprecisões indesejáveis. Essa

imprecisão aumenta à medida em que o quantum de tempo, isto é, o intervalo entre os

ciclos de simulação, configurado pelo usuário, seja maior.

Na nova arquitetura corrigiu-se o problema adotando-se como estratégia de controle

de tempo o avanço ao próximo evento. A partir daí, para realizar a animação gráfica, foi

necessário incluir eventos adicionais denominados time-slice, TS, conforme descrito na seção

2.1.3. A freqüência de geração desses eventos, isto é, o intervalo de tempo entre dois

eventos de animação, pode ser decidida pelo usuário da ferramenta sem afetar a precisão

dos resultados de um experimento.

A simulação a eventos discretos ocorre numa velocidade não uniforme; o tempo

despendido no processamento de cada diferente evento é imprevisível. Em consequência,

embora os eventos TS sejam agendados em intervalos regulares do relógio simulado, são

processados em períodos não uniformes de tempo real. Se não for efetuada uma correção o

resultado será uma animação gráfica bizarra, em que os equipamentos movimentam-se

bruscamente. A Figura 4.5 da próxima página ilustra essa falta de sincronia do tempo.

Conforme se observa na Figura 4.5, a hora real de processamento dos eventos não

corresponde à hora em que foram agendados para ocorrerem. Os primeiros eventos da lista

foram agendados para ocorrer nos instantes de tempo simulado 17, 30 e 32 segundos,

respectivamente. O primeiro evento é processado quando o relógio do hardware marca 10

segundos. Este evento consome 10 segundos de CPU, fazendo com que o segundo evento

seja processado no instante 20 segundos. Este evento por sua vez consome 5 segundos de

CPU e faz com que o terceiro evento, agendado para a hora simulada 32 segundos, seja

80 Capítulo IV

processado na hora real 25 segundos. Observa-se, portanto, que não existe uma relação

linear entre tempo simulado e tempo real. Os tempos de processamento foram aqui

exagerados para ilustrar mais claramente o problema.

Figura 4.5 – O problema de sincronia de tempo de simulação.

Para que a animação seja apresentada de forma contínua e suave, sem essas

disparidades de atualização de relógio, é preciso garantir que a atualização do tempo real

guarde uma proporção linear em relação ao tempo real; por exemplo, 1:1.

Como se espera que na maioria das vezes os eventos sejam processados na

simulação mais depressa do que acontecem no mundo real7, a solução do problema de

sincronia consiste em introduzir tempos de espera e atrasar o processamento dos eventos

para a hora adequada. A próxima figura mostra essa técnica.

Figura 4.6 – Solução para sincronia de tempo de simulação pela

introdução de atrasos de processamento.

Todos os eventos da Figura 4.6 foram agendados de maneira que seu processamento

ocorrerá no futuro, tanto em tempo simulado quanto em tempo real. Existe outra

possibilidade que é um evento ser agendado para um instante de tempo simulado que, em

tempo real, já ocorreu. Exemplificando, considere-se uma seqüência de eventos separados

7 Caso isso não se verifique, está claro que o poder de processamento da CPU utilizada é insuficiente para

executar o simulador.

eventos e hora de agendamento

tempo real 5 10 15 20 25 30 35 40 45 50 55 60

17 30 32 40 55

tempo real 5 10 15 20 25 30 35 40 45 50 5 5 60

17 30 32 40 55

hora real de processamento

atraso induzido


entre si por um segundo de tempo simulado; se o computador demorar mais do que um

segundo para processar um evento, a simulação ficará atrasada, como mostra a Figura 4.7 a

seguir.

Figura 4.7 – Atraso no processamento de eventos.

Neste caso é preciso fazer frame-skip: pular quadros de animação e desta forma

diminuir a carga de processamento sobre a CPU, tentando recuperar o atraso da simulação.

A geração do evento TS levou a adaptações na arquitetura do núcleo, para geração de

eventos e sincronização de tempo simulado com tempo real. O modelo comportamental dos

equipamentos também precisou ser projetado para tratar o evento TS, atualizando as

variáveis referentes à geometria.

A utilização de informações da geometria em outras operações - especificamente as

interações físicas entre equipamentos - demandou outra alteração do modelo

comportamental original dos equipamentos, que consiste na execução do código de

tratamento do evento TS na chegada de qualquer evento ao equipamento. Isto é necessário

para garantir que as variáveis de geometria estejam atualizadas e portanto a posição dos

pontos de interação física não esteja num estado inconsistente em nenhum momento. O

processamento adicional é reduzido uma vez que a geração de quadros de animação gráfica

só acontece de fato no tratamento do evento TS pelo módulo de animação gráfica.

4.4 Arquitetura de Simulação

Nesta seção descreveremos em linhas gerais a operação e a organização interna do

simulador.

4.4.1 Modelo da Arquitetura

A operação do simulador requer o paralelismo de algumas atividades: i) execução dos

equipamentos simulados; ii) execução do controle do FMS; iii) animação gráfica; e iv)

interface com usuário. Não necessariamente as quatro atividades ocorrem simultaneamente,

existindo alguma seqüências de operação a serem observadas.

tempo real 1 2 3 4 5 6 7 8 9 10 11

1 2 3 4 5

82 Capítulo IV

A Rede de Petri apresentada na Figura 4.8 ilustra o funcionamento do software.

Figura 4.8 - Rede de Petri da arquitetura de simulação

A execução da rede inicia na transição Tinit , onde é atribuída a hora inicial do relógio

de simulação, é agendado um evento TS e cada equipamento é solicitado para realizar sua

inicialização. O lugar Pev corresponde à lista de eventos, ordenada ascendentemente por

hora de ocorrência dos eventos. A transição Tsync faz a sincronização de tempo simulado e

tempo real, gerando os atrasos explicados na seção 4.3.2. Assim que um evento possa ser

processado, o mesmo é roteado para uma dentre três transições:

Pev

ev.hora = Rr.hora clock.hora � ev.hora

Pr

Tusuário <clock>

Tinit

clock.hora � Rr.hora ev.tipo � TS

n

Tsync

<ev>

<ev>

<ev>

<ev>

<ev>

<ev>

<Rr>, <clock>

<ev>, <*>

<ev>

Pequip

Tcontrole Tag Tcmd

Tmonit <*>

<*>

<ev> (ev.tipo = TS)

<*>

Paux Pmutex

Taux


• Tcontrole: esta transição é disparada pela chegada de um evento ao controle, que é

notificado pelo simulador por meio do envio dos dados contidos no evento;

• Tcmd: esta transição equivale a execução do modelo comportamental de um

equipamento. Um evento dessa natureza pode estar transmitindo um comando,

proveniente do controle ou do usuário; ou pode ser um dos eventos pré-definidos

na arquitetura, listados na seção 5.2.1;

• Tag: a transição de atualização geométrica é disparada por um evento TS, time-

slice. Sua execução acarreta a ativação do modelo comportamental de todos os

equipamentos, seguida da atualização da apresentação do FMS no vídeo.

O lugar Pequip contém a lista dos modelos comportamentais dos equipamentos sendo

simulados. O lugar Pequip contém os predicados relógio de tempo real <Rr> e relógio da

simulação <clock>.

A transição Tusuário corresponde ao agendamento de um evento pelo usuário,

utilizando a interface com equipamentos ou com controle. A hora de disparo desse evento

pode ser igual à hora atual,; ou pode ter sido atribuída para um tempo futuro. Essa

interação entre usuário e simulador é assíncrona, ou seja, pode ocorrer a qualquer momento

durante a operação do software.

Por fim, na transição Tmonit é executado o módulo de monitoração do estado interno

dos equipamentos.

O lugar Pmutex contém uma marca que habilita a execução de processamento de um

evento e, portanto, um ciclo de simulação.

Os equipamentos podem ser executados serialmente, já que a referência de tempo ou

relógio de simulação é avançada apenas obedecendo à hora de agendamento dos eventos.

Isso significa que eventos agendados para o mesmo horário são processados em seqüência,

teoricamente sem nenhum prejuízo para a precisão da simulação. O controle pode ser

executado em paralelo com os equipamentos que compõem o FMS.

Finalmente, o lugar Paux pode receber novos eventos gerados em Tcmd , Tcontrole e Tag;

um evento Paux habilita o disparo da transição Taux, que coloca tal evento na lista Pev.

4.4.2 Módulos Internos do Simulador

A Rede de Petri da figura 4.8 mostra a arquitetura do simulador, explicitando as

operações sequenciais e o paralelismo em seu funcionamento. As funções apresentadas na

rede estão distribuídas em módulos, cabendo a coordenação de todas as operações a um

kernel ou núcleo de simulação.

Para descrever a organização interna do simulador utilizou-se o diagrama de classes

UML apresentado na Figura 4.9.

84 Capítulo IV

Figura 4.9 – Diagrama de classes do simulador.

O usuário controla o simulador através de comandos como iniciar, pausar, parar e

reiniciar a execução, presentes na ‘interface de controle da simulação’. Já o controle do FMS

é, em realidade, a entidade de controle do FMS sendo simulado. Deve ser fornecido pelo

usuário e, conforme já mencionado, interage com o simulador por meio de uma API de

comunicação. A interface desse elemento deverá ser provida também pelo usuário.

O kernel contém uma lista de equipamentos simulados, da classe CEquipamento . Todo

equipamento é derivado a partir desta classe, que fornece a interface de comunicação ou

API com o kernel.

O módulo de monitoração contém referências a todos os equipamentos sendo

simulados. Este módulo foi implementado de modo a fornecer uma interface básica com o

usuário do simulador, permitindo escolher e apresentar o conteúdo de variáveis no monitor,

através de históricos ou gráficos.

O módulo de ambiente físico e animação gráfica é responsável por funções de

apresentação de imagens em vídeo e tratamento de interações físicas. No diagrama

apresentado, o módulo é retratado de forma simplificada. Maiores detalhes são apresentados

no capítulo 6.

O módulo de ambiente físico e animação contém referências a todas as malhas de

transporte utilizadas num experimento. A ligação entre um veículo e uma malha de

Controle do FMS

Equipamento

Robô

Fresa

Torno

AGV

Kernel

de Simulação

Supervisão

Comando

Escalonamento

Interface de controle da simulação

Monitoração

Ambiente Físico e Animador Gráfico

Malha de Transporte

Objeto Móvel

Peça Palete

Animador de Equipamento

*

*

**

acessa consulta dados cinemáticos

posiciona

*


transporte é conceitual: o AGV exemplificado no diagrama obtém dados sobre uma malha

utilizando a API com o kernel.

Peças e paletes exibem atributos e métodos comuns, implementados na super classe

‘Objeto Móvel’. Equipamentos são as entidades que podem instanciar e destruir objetos dos

tipos peça e palete. Para um experimento de simulação seriam definidos equipamentos

especiais, para criação (fonte) e destruição (dreno8) de tais elementos. Estas relações entre

equipamentos, peças e paletes não foram apresentadas para simplificar o diagrama.

4.5 Conclusão

O projeto de um simulador de FMS deve levar em consideração uma lista extensa de

requisitos funcionais. Neste capítulo tais requisitos foram analisados com o propósito de

explicar o projeto do software.

O primeiro ponto a salientar é que o simulador funcionará integrado a princípio com

dois outros módulos que são: o programa para auxílio à definição de arranjo físico e o

programa para análise dos dados quantitativos obtidos da simulação. As interfaces mínimas

de comunicação foram apresentadas para os dois casos.

O núcleo do simulador coordenará a execução de um modelo do FMS. Para projetar o

núcleo e definir a organização dos modelos é preciso antes definir os comportamentos,

parâmetros e características relevantes de um sistema flexível de manufatura que se deseja

replicar na simulação. Entre os principais pontos analisados pode-se citar:

• modelagem dos equipamentos de manufatura;

• requisitos para apresentação tridimensional e animação dos equipamentos;

• tratamento para malhas de transporte e esteiras

• tratamento das interações físicas entre equipamentos e

• organização do controle do FMS.

O estabelecimento dos requisitos para o simulador é uma etapa crítica do trabalho,

sendo definidas questões a respeito de dois grandes tópicos: i) as características funcionais

do programa e os recursos disponíveis aos usuários; e ii) as estratégias para modelagem de

um FMS e os limites de nível de abstração e detalhamento na representação do sistema.

8 Esta nomenclatura é usual em análise quantitativa por Redes de Petri.

86 Capítulo V

5

Implementação da Simulação

Neste capítulo apresenta-se as informações mais importantes a respeito da

implementação da arquitetura proposta para simulação de FMS. Como este trabalho está

focado na simulação com animação gráfica, será dada uma atenção maior para as

informações que se relacionam com o funcionamento do animador. Para obter informações

sobre tópicos mais relacionados com implementação dos modelos comportamentais e

implementação do núcleo do simulador, recomenda-se consultar a dissertação do

pesquisador Luís F. F. Rosinha [74], co-responsável pelo desenvolvimento do projeto.

As seções que se seguem estão assim divididas: em 5.1 são apresentados a

terminologia e conceitos básicos sobre a operação do simulador; em 5.2 descreve-se a

implementação do modelo comportamental dos equipamentos; a seção 5.3 apresenta

características de peças e paletes; a seção 5.4 trata de particularidades de equipamentos de

transporte de materiais, especificamente veículos e esteiras9. Por fim, a seção 5.5 apresenta

o diálogo do simulador com o controle do FMS.

5.1 Conceitos

Para codificar equipamentos e o controle do FMS é preciso conhecer alguns conceitos

definidos pela arquitetura do simulador e que regem seu funcionamento.

Eventos são implementados como registros de comprimento variável. Possuem como

informações padrão a hora em que devem ocorrer e um destinatário, que pode ser um

equipamento de manufatura ou o controle. Os equipamentos são identificados internamente

na arquitetura pelo endereço em memória do objeto correspondente. Eventos podem conter

um número arbitrário de parâmetros, criados no momento em que o evento é agendado. Os

tipos de dados admitidos são: inteiro (32 bits), real (implementado como double) e string

(ASCIIZ).

Comandos de equipamentos são os comandos disponíveis na interface de uma

máquina ferramenta ou outro equipamento qualquer. Essa interface tanto pode ser

9 Robôs foram tratados como equipamentos de transformação. O tratamento diferenciado para

equipamentos de transporte é dispensado àqueles que tem informações variáveis de geometria.

"I do not fear computers. I fear lack of them." -Isaac Asimov

Implementação da Simulação 87

representada pelo console e comandos disponíveis aos operadores, como pelos sinais

elétricos trocados com o controle. Na modelagem de um equipamento, todos os comandos

são considerados em um único conjunto. Comandos podem ter um número arbitrário de

parâmetros. Os tipos de dados disponíveis são os mesmos utilizados em eventos.

Processos são tarefas executadas pelos equipamentos, consumindo um determinado

tempo de simulação. Processos típicos correspondem às atividades que uma máquina

executa em resposta a comandos, tais como: ligar, furar, tornear, mover junta. Não é

estabelecido um nível de abstração a ser seguido; se o usuário desejar codificar processos

internos de um equipamento, como funcionamento de motores, isto é plenamente possível.

Entretanto, é bastante provável que esse nível de detalhe não contribua com o objetivo da

simulação, que é obter parâmetros de funcionamento de um FMS, servido apenas para

complicar desnecessariamente a modelagem de um equipamento.

A atualização geométrica demanda um tratamento específico em cada modelo

comportamental. Para todo processo de um equipamento em que ocorra a movimentação de

alguma parte móvel de sua geometria, é preciso escrever código que realize a atualização de

sua representação tridimensional no vídeo. Conforme já mencionado na seção sobre

modelagem cinemática (2.2.4), cada nó cinemático contém o identificador de uma variável

de geometria no modelo comportamental. Sempre que ocorrer uma mudança de

posicionamento de partes do equipamento, as respectivas variáveis de geometria deverão

ser atualizadas. Além disso, sempre que o evento TS, time-slice for recebido, todas as

variáveis de geometria deverão ser atualizadas, levando em conta para cada uma:

• velocidade de movimentação daquela parte do equipamento;

• tempo decorrido desde a última atualização, contido na variável delta_hora .

Pontos de interação física foram mencionados no capítulo anterior, dentro de

requisitos de animação gráfica. Cada PIP de um equipamento definido no modelo geométrico

deve ter no modelo comportamental um objeto que lhe corresponda, do tipo class

CPIPoint . A variável criada no modelo comportamental é utilizada para, a partir do código,

interagir com peças e paletes que sejam recebidas pelo equipamento durante a simulação.

Usos típicos são atualizar medidas geométricas de peças ou gravar/consultar dados na

memória de paletes.

As Interações Físicas são ocorrências de troca de objetos, como peças e paletes,

entre os equipamentos. O tratamento de uma interação física pelo simulador, é realizado

com base nos modelos geométricos, simplificando e diminuindo o volume de código escrito

no modelo comportamental.

A Monitoração de variáveis de estado é realizada pelo simulador, acessando

diretamente variáveis internas do modelo comportamental. Uma rotina especial,

88 Capítulo V

MapeiaPrimitivaToVariavel () , deve ser codificada em cada equipamento para

implementar o mecanismo.

5.2 O Modelo Comportamental dos equipamentos

A codificação de um equipamento acontece derivando uma classe a partir de class

CEquipamento :

class CPuma : public CEquipamento { . . . };

A classe CEquipamento provê a interface com o núcleo do simulador, por meio de uma

série de funções. A classe derivada CPuma é um equipamento exemplo e será utilizada no

texto para explicar detalhes sobre o modelo comportamental.

Inicialização

A inicialização de um equipamento pode ser dividida em dois momentos: criação de

um objeto em memória e preparação do mesmo para ser executado na simulação.

A criação de um equipamento inicia pela alocação de memória para o objeto

correspondente. Isto é feito pelo simulador10 sempre que um equipamento é carregado do

disco. Em seguida acontece a invocação do construtor de class CEquipamento , seguido do

construtor da subclasse (class CPuma ), de acordo com a semântica da linguagem C++.

Cumprida esta etapa é preciso invocar a rotina EstadoInicial() . S ua tarefa é

colocar o equipamento num estado inicial, pronto para ser executado em um experimento.

Esta rotina é invocada pelo núcleo do simulador sempre que um usuário inicia a simulação.

Depois de uma parada na simulação esta rotina será novamente invocada se o usuário

utilizar o comando 'iniciar simulação'.

São tarefas da rotina EstadoInicial () :

• atribuir valores iniciais às variáveis de estado;

• atribuir valores iniciais às variáveis de geometria;

• agendar evento de quebra;

• executar outras ações programas pelo usuário.

10 A alocação de um novo objeto (i.e., equipamento) é um serviço provido pela DLL que contém o código

do equipamento.


Processos

Cada processo é codificado em uma rotina (método ou função membro) diferente

dentro da classe CPuma. Processos são ativados pelo recebimento de eventos; tais eventos

são tratados pela rotina CEquipamento::mc (), onde ‘mc’ significa ‘modelo

comportamental’.

Toda rotina que modela um processo é dividida em três seções ou partes: início e fim

do processo e atualização geométrica. Tais seções são descritas a seguir:

• início:

1) verificar o estado do equipamento em relação à execução do processo e tomar

as medidas necessárias. Exemplos: o comando “ligar” é desconsiderado se o

equipamento já estiver ligado; o comando "baixar broca" quebra um

equipamento se a broca já estiver baixada;

2) se houverem parâmetros, verificar sua validade;

3) agendar o evento de final de processo;

4) atualizar variáveis de estado e mudar o estado do processo para ATIVO11.

• atualização geométrica:

atualização de todas as variáveis relacionadas com a geometria do equipamento

(esta atualização será descrita a seguir);

• fim:

atualizar todas as variáveis de estado e geometria para refletirem o estado do

equipamento ao término da execução do processo.

Execução da Animação Gráfica

A execução da animação dentro de class CPuma consiste apenas em atualizar as

variáveis de geometria afetadas pela execução dos processos. Exemplificando, se o robô

Puma estiver executando o processo de rotação de punho (último link de sua cadeia

cinemática), a atualização geométrica resume-se à execução da seção de atualização

geométrica da rotina que modela este processo, por exemplo CPuma::RotacionaPunho () .

O código poderá ser semelhante à:

case ATUALIZACAO_GEOMETRICA: diferenca = velocidade * delta_hora; angulo_punho = angulo_punho + diferenca; break;

11 Um processo pode estar no estado ATIVO ou no estado NÃO-ATIVO. Isto é indicado no modelo

comportamental por uma variável booleana.

90 Capítulo V

A variável delta_hora é local ao objeto CEquipamento , super-classe de CPuma e

contém o intervalo de tempo entre a última atualização geométrica e a hora atual. Sempre

que um evento é recebido por um equipamento, faz-se necessário executar o procedimento

de animação descrito em "Eventos pré-definidos" (seção 5.2.1), com o propósito de colocar

as variáveis de geometria num estado consistente em relação à execução do equipamento e

seus processos.

A chegada do evento TS dentro de class CPuma é tratada em CPuma::mc (). Cada

processo ativo do equipamento deverá ser invocado, para que as variáveis de geometria a

ele associadas sejam atualizadas. Posteriormente, o módulo de animação geométrica e

ambiente físico utilizará o mecanismo de monitoração para obter o conteúdo das variáveis

de geometria e atualizar a representação no vídeo.

Comandos

Comandos podem ser originados de duas maneiras: pelos programas de controle do

FMS, que dialogam com o simulador solicitando o envio de cada comando a seu

equipamento destino; ou pelo usuário da simulação, que pode utilizar a interface do software

de modo a operar o equipamento, como se estivesse usando diretamente um console. Em

ambos os casos a arquitetura utiliza eventos para transmitir cada comando ao equipamento

destinatário.

Respostas

As respostas geralmente são sinais enviados por um equipamento ao final da

execução de um comando. Em ANALYTICE as respostas eram atreladas obrigatoriamente ao

encerramento de um comando. No simulador atual preferiu-se aumentar a flexibilidade do

conceito, permitindo a um equipamento gerar um sinal de resposta a qualquer momento.

Programação NC

Conforme já comentado no capítulo anterior, a programação NC foi implementada por

meio de um interpretador. A linguagem definida permite ao usuário executar os comandos

contidos na interface do equipamento, instanciar variáveis de alguns tipos pré-definidos,

realizar cálculos aritméticos e executar laços e desvios condicionais e incondicionais.

Cada equipamento definido pelo usuário herda da classe CEquipamento um

interpretador completo. Para executar um programa, basta que o usuário utilize o seguinte

código:

run (programa)


Maiores detalhes sobre o interpretador podem ser encontrados em [74].

Pontos de Interação

Os pontos de interação física são utilizados no tratamento de trocas de peças e

paletes entre equipamentos. A cada ponto de interação física existente no equipamento

deverá corresponder uma variável (objeto) do tipo CPIPoint . Para estruturar e facilitar o

trabalho de codificação do usuário, foi definida a estrutura de dados apresentada a seguir:

struct _Pontos_de_Acesso { char nome [32]; CPIPoint *ponto; }

o campo nome contém o identificador do ponto de interação; é uma string ASCIIZ

menor que 32 caracteres, sensível a maiúsculas. O conteúdo dessa string deve ser igual ao

nome de um ponto de interação existente no modelo geométrico-cinemático. O campo ponto

deverá ser atribuído em tempo de execução, com o endereço de um objeto do tipo CPIPoint

alocado dinamicamente.

Um ponto de interação física pode conter uma peça ou um palete, sendo possível que

existam peças sobre o palete. Tais objetos são criados em tempo de execução, sendo

destruídos automaticamente caso o simulador seja interrompido (comando ‘Parar’). Peças e

paletes são apresentados na seção 5.3.

Monitoração

A codificação de monitoração nos equipamentos consiste em preencher o código da

rotina MapeiaPrimitivaToVariavel () , permitindo que uma entidade externa obtenha,

por meio de um ponteiro, acesso à dados internos do objeto equipamento.

A rotina MapeiaPrimitivaToVariavel() recebe como parâmetro uma string ASCIIZ

menor que 32 caracteres, sensível a maiúsculas, contendo um identificador do dado

requisitado. A rotina deve retornar um ponteiro void com o endereço de um objeto que

contenha a informação solicitada, ou NULL.

As variáveis geométricas e os pontos de interação devem obrigatoriamente ser

retornados, sob pena de não funcionamento da simulação.

A Tabela 5.1 a seguir sumariza as categorias de informações retornadas pela rotina.

92 Capítulo V

Tabela 5.1: Informações retornadas pela rotina

MapeiaPrimitivaToVariavel ().

tipo da informação tipo de variável origem da requisição

variável de monitoração double / int /

char*

módulo de monitoração

variável de geometria double módulo animador geométrico e

ambiente físico

variável de cor unsigned char[3] módulo animador geométrico e

ambiente físico

ponto de interação CPIPoint módulo animador geométrico e

ambiente físico

5.2.1 Eventos pré-definidos

Alguns eventos estão pré-definidos na arquitetura de simulação e devem receber um

tratamento adequado no código de cada equipamento. Descreve-se a seguir estes eventos

pré-definidos.

Evento Time-slice: quando um equipamento recebe este evento é preciso que, para

cada processo ativo, a respectiva rotina seja invocada com o parâmetro

ATUALIZACAO_GEOMETRICA.

O código a seguir exemplifica o tratamento do evento:

for (unsigned i = 0; i < _numero_de_processos; i ++) { if (processo[i].ativo) // array gerado auto maticamente switch (i) { case MOVENDO_J1: ProcessoMovendo1 (ATUALIZACAO_GEOMET RICA); break; case MOVENDO_J2: ProcessoMovendo2 (ATUALIZACAO_GEOMET RICA); break;

No código apresentado o laço é utilizado para pesquisar, entre todos os processos,

aqueles que estão ativos. Para estes invoca-se a rotina correspondente solicitando que a

atualização geométrica seja realizada.

Evento de Interação física: a chegada deste evento a um equipamento pode ter

um entre dois significados:

1) remoção de objeto: outro equipamento removeu uma peça ou um palete deste

equipamento. São passados como parâmetros o equipamento que realizou tal ação e o

handle ou identificador do ponto de interação (dado do tipo HPIPOINT);


2) chegada de objeto: foi depositada uma peça ou palete neste equipamento. As

informações recebidas são as mesmas do caso 1).

A realização de interações físicas é explicitada apenas no código do modelo

comportamental de equipamentos que iniciam tal processo. Geralmente isso será feito em

robôs e consiste apenas em invocar uma função, avisando ao simulador sobre a ação de

apreender ou liberar um objeto. No caso de um robô soltando uma peça sobre uma

superfície, o código a ser incluído dentro do processo de abertura da garra será:

... SoltarPeca (ponto_de_interacao[0].ponto); ...

O código dos equipamentos "passivos", isto é, que participam da interação física sem

iniciar esse processo é bem mais simples. Admitindo que nenhuma restrição esteja presente

para processar a interação (como sinalizar erro por uma tentativa de retirada de uma peça

que está fixada por algum mecanismo), não há código nenhum a escrever. O exemplo a

seguir foi retirado de um AGV de demonstração, plenamente funcional e utilizado durante os

testes do simulador. A troca de possessão de peças (entre AGV e um robô com o qual

interage) é toda realizada pelo ambiente físico, não restando nada para o equipamento AGV

fazer:

case INTERACAO : switch (ev->evento) { case ADICIONAR_PECA : case REMOVER_PECA : break; case FALHA : break; } break;

Evento de falha por interação física desastrosa: este tipo de evento modela

ocorrências de interação física desastrosa. Um exemplo seria um robô tentar retirar uma

peça de um torno que está realizando uma operação de usinagem. O tratamento típico para

essa situação corresponde a seguinte seqüência:

1) o robô recebe o evento Fechar Garra e inicia o processamento;

2) o robô conclui a ação e invoca a rotina PegarPeça () ;

3) o ambiente físico verifica que o ponto de interação do robô está próximo de um

ponto de interação do torno. É agendado o evento de Interação Física para o torno;

4) o robô encerra execução do processo Fechar Garra ;

5) o torno processa o evento de Interação Física ; percebe o erro e invoca a rotina

FalhaInteracaoFisica () do núcleo do simulador;

94 Capítulo V

6) o ambiente físico recebe a informação de erro e gera um evento de quebra dos

equipamentos envolvidos.

Outras hipóteses de falha seriam: i) um robô tentar depositar uma peça sobre um

ponto de interação já ocupado por outro objeto; e ii) um robô tenta depositar uma peça num

espaço vazio. No primeiro caso, o ambiente físico detecta a falha, retorna um erro ao robô e

agenda um evento de aviso de falha de interação para o torno. No segundo caso, o ambiente

físico reporta um erro ao simulador que apresenta uma mensagem ao usuário. O robô recebe

como retorno da função SoltarPeca () um valor FALSO, indicativo de que a interação não

ocorreu.

Interações físicas com esteiras: a colocação de peças em esteiras precisa de um

tratamento especial. Tais equipamentos não possuem pontos de interação "fixos" em sua

geometria; a coordenadas para interação com uma esteira dependerão do arranjo físico do

FMS. Num caso extremo podemos admitir que um objeto pode ser depositado em qualquer

ponto sobre a superfície da esteira. Isto levou a criação do conceito de ponto de interação

dinâmico, apresentado na seção 5.3.2.

As duas possibilidades de ocorrência de interação levam a duas implementações

diferentes: i) interação sobre toda a superfície, ou ii) interação apenas em pontos

determinados.

No projeto da implementação da possibilidade i) - interação em qualquer ponto da

superfície - recorreu-se uma técnica usada em detecção de colisão: a utilização de bouding-

boxes. Trata-se da definição de volumes que circunscrevem os objetos que se deseja

monitorar; quando ocorre interpenetração dos volumes uma colisão é detectada. Em nosso

caso, tal condição sinaliza que uma interação física pode ocorrer. A Figura 5.1 a seguir

ilustra o processo na realização da interação de um robô que deposita uma peça sobre uma

esteira.

Figura 5.1 – Uso de bouding-box para determinar se interação física

pode ocorrer.


Quando a garra de um robô se aproxima de uma esteira, faz-se um teste verificando

se a garra se encontra dentro de um volume que circunscreve o segundo equipamento,

conforme apresentado na Figura 5.1. Caso a resposta seja afirmativa, como acontece neste

exemplo, a interação pode ocorrer; caso contrário, é provável que a peça caia no chão,

sendo retornado um código de erro ao robô.

A interação deverá ser processada pelo ambiente físico sinalizando ao equipamento

esteira sobre a “chegada” de uma peça. A esteira deve criar um novo PIP e atribuir a ele o

objeto recebido. No processamento do evento TS, o modelo comportamental da esteira

deverá atualizar as coordenadas do PIP para realizar a movimentação do objeto. A retirada

do objeto implica a destruição do PIP.

Em outra forma de implementação, podemos estabelecer que as interações físicas

acontecem exclusivamente em determinados pontos. As coordenadas desses pontos estão

restritas pelos programas NC dos equipamentos. Nesse caso, pode-se cadastrar PIPs

dinâmicos apenas nos locais pré-determinados para receber objetos. Quando uma interação

acontece, deve ser criado outro PIP dinâmico, auxiliar, com a função de conter e movimentar

o objeto recebido durante a operação da esteira. Esse PIP auxiliar será destruído na retirada

do objeto.

Atualmente utiliza-se esta última alternativa de implementação, considerada

satisfatória para a simulação de FMS. Existe no módulo de animação gráfica e ambiente

físico o código básico para extender a implementação de modo a suportar o primeiro caso

descrito, utilizando bouding-boxes que circunscrevem toda a superfície de transporte da

esteira.

Detalhes sobre como é feito o tratamento da interação física no simulador e no

módulo de ambiente físico são apresentados no capítulo 6.

Evento de quebra por MTBF: a falha ou mal funcionamento de um equipamento é

modelada pelo agendamento de um evento de quebra, na rotina estado_inicial () , de

acordo com um parâmetro fixado pelo usuário. O processamento de quebra consiste em:

1) ao receber o evento E_MTBF, ativar o processo de manutenção do equipamento,

agendando um evento E_MTTR correspondendo a hora em que termina a manutenção; e

2) ao receber o evento E_MTTR, desativar o processo de manutenção, agendar um

novo evento E_MTBF e executar outras ações necessárias, como talvez retornar o

equipamento ao estado inicial.

5.3 Peças e Paletes

Peças e paletes são elementos passivos do ponto de vista do usuário do simulador, já

que não realizam atividade alguma. Ambos objetos não possuem modelos geométricos.

96 Capítulo V

Considerou-se que o custo de implementação de tal recurso não seria compensado por um

ganho significativo de realismo gráfico. Ao invés, simplificou-se a apresentação de peças e

paletes a paralelepípedos, parametrizáveis quanto à:

• dimensões nos eixos x, y e z;

• cor;

• no caso de paletes, número e posição dos pontos em que peças podem ser

depositadas (aqui denominados slots).

A cada peça e a cada palete existente dentro do FMS simulado corresponde uma

instância da classe CPart ou CPalete , respectivamente. Ambas as classes implementam

uma memória que pode ser utilizada para guardar dados durante a execução da simulação,

conforme comentado na seção 4.1.2. Exemplos de dados são:

• dimensões geométricas de uma peça, alteradas pelos equipamentos durante

operações de usinagem;

• memória interna de paletes, utilizada pelo controle.

A criação do palete e das peças e sua ‘colocação’ sobre o ponto de interação de um

equipamento é realizada utilizando funções implementadas pelas classes CPallet e CPart .

Estão disponíveis ainda, comandos de atribuição de cor (sendo default o cinza) e utilização

da memória interna dos objetos.

O trecho a seguir ilustra a criação de um palete com dois slots, estando um ocupado

por uma peça; e a colocação do palete no ponto de interação do equipamento que o criou.

CPart *part; CPallet *palete; palete = new (CPalete) (150, 100, 50) ; // posições (x, y, z) em relação ao centro do pa lete. palete->AddSlot ( 0, 0, 40); // primeiro slot palete->AddSlot ( 100, 0, 40); // segundo slot palete->AddSlot (-100, 0, 40); // segundo slot // coloca peça sobre primeiro slot part = new (CPart) (55, 55, 55); palete->ReceivePartAt (0, part); *ponto_de_interacao[0].ponto = palete;

Na execução das atribuições aos pontos de interação, pelo método

CPIPoint::operator = () , é estabelecido o vínculo ou ligação entre o objeto (peça ou

palete) e o ponto de interação, além do posicionamento correto de tais objetos para

animação.


A Figura 5.2 a seguir foi obtida da tela do simulador. Mostra um palete com três slots,

sendo dois ocupados por peças. Um robô aproxima sua garra de uma das peças para retirá-

la do palete.

Figura 5.2 – Palete com duas peças e braço robotizado.

A escolha de cubos para representar peças resulta em eficiência de processamento.

Como não existe a noção de orientação espacial para as peças, a forma geométrica mais

adequada seria uma esfera ou um poliedro que a aproximasse, representando um maior

custo de processamento geométrico. As peças são desenhadas sobre um palete utilizando o

sistema de coordenadas deste, motivo pelo qual os respectivos cubos, neste caso, aparecem

corretamente alinhados. Na apresentação de uma peça segura por um robô ou fixada em

outro equipamento qualquer, é bastante provável que o cubo esteja rotacionado nos eixos x,

y e z em relação ao ponto de interação.

5.4 Equipamentos de transporte

5.4.1 Veículos de transporte

A simulação de funcionamento de um veículo de transporte exige a disponibilidade de

uma malha que define o percurso a ser percorrido. Tais malhas são definidas por arquivos

texto, sendo representadas por segmentos de reta e arcos de circunferência. Um exemplo de

malha e respectivo arquivo de definição encontra-se no Anexo I.

Durante o processamento da movimentação de um veículo, é preciso:

• calcular, para cada trecho de malha, o tempo necessário para percorrê-lo;

• ao terminar o percurso de um trecho, obter as informações acerca do próximo;

• no tratamento do evento TS, atualizar a posição do AGV no chão-de-fábrica.

Além dos trechos que definem o percurso da malha, definem-se também elementos

denominados 'sensores', que correspondem a possíveis pontos de parada de um veículo. Na

carga de um veículo são solicitados como parâmetros a malha de transporte associada; o

sensor inicial sobre o qual o equipamento é posicionado e sua orientação, na forma de um

peça 1

peça 2

palete

98 Capítulo V

ângulo medido em graus em relação ao eixo x do plano cartesiano do chão-de-fábrica,

conforme mostra a Figura 5.3 a seguir.

Figura 5.3 – AGV em movimento sobre uma malha de transporte. À

esquerda vê-se a origem de coordenadas cartesianas para

posicionamento de equipamentos no chão-de-fábrica.

Para executar o movimento de um veículo, é preciso inicialmente obter as

informações sobre próximo trecho a percorrer. Isto é realizado invocando a rotina

RetornaCaminhoAGV () . A rotina retorna o endereço de uma estrutura de dados estática, do

seguinte tipo:

struct s_walk_info { HAGV_PATH path; // id da mal ha HAGV_PATH_ELEMENT cur_path_el; // id de ele mento da malha int type; // tipo: ret a / curva / sensor char name[32]; // nome do s egmento double length, // comprimen to a percorrer xc, yc, zc, radius, // centro de curva x0, y0, z0, // ponto ini cial de reta x1, y1, z1, // ponto fin al de reta angle0, // orientaçã o do AGV na entrada angle1, // e na saíd a do trecho alpha0 , // ângulos d e início e fim de alpha1 ; // de arco d e circunferência };


A partir dos dados contidos na estrutura - que não devem ser modificados pelo

modelo comportamental de um equipamento - é possível calcular o tempo necessário para

percorrer o trecho. Deve ser agendado então um evento para a hora em que termina o

percurso sobre o trecho. O processamento desse evento repete todo o procedimento descrito

até aqui.

O tratamento da atualização geométrica é feito com base nos dados da estrutura

struct s_walk_info e na velocidade de movimentação do veículo. Dado o tempo decorrido

desde a última atualização geométrica, obtido na variável delta_hora , é calculado o espaço

percorrido pelo veículo. No caso de um segmento de reta, calcula-se uma distância em

milímetros; se o trecho atual for um arco de circunferência, o valor será dado em graus,

conforme mostra a próxma figura.

caso de um segmento de reta caso de um arco de circunferência

delta_hora = 1 segundo hora entrada na curva = t1 ângulo inicial = 10 ângulo total da curva = 170 graus raio = 1000 mm hora saída da curva = t1 + 2.965” cálculos: ângulo percorrido = 170/(1/2.965) = 57.3 nova posição � x = xc + r * seno (10 + 57.3 graus) y = yc + r * cosseno (10 + 57.3 graus)

delta_hora = 1 segundo hora entrada na reta = t2 pos inicial = (xi,yi); posição final = (xf, yf) comprimento total reta = 3500 mm hora saída da reta = t2 + 3,5” cálculos: fração percorrida =(1/3,5) =.28 nova posição � x = x + .28 * (x1-x0) y = y + .28 * (y1–y0)

Figura 5.4 – Cálculo de atualização de posição de veículo na simulação.

Finalmente, é preciso então informar ao simulador que houve uma mudança de

posição do equipamento. Diferente do que acontece com as variáveis de geometria,

consultadas automaticamente pelo simulador, a mudança de posição de um equipamento no

chão-de-fábrica deve ser explicitada invocando a função DefinePosicao () da API do

simulador.

evento n+1

evento n evento k

evento k+1

AGV entra aqui; velocidade = 1m/s

diferença = 1 seg.

(x0, y0) (x1, y1)

(xc, yc)

r

100 Capítulo V

5.4.2 Esteiras

As esteiras de transporte são modeladas como os demais equipamentos de

manufatura, mas representam um problema especial de modelagem devido ao fato de

possuírem uma geometria variável, determinada pelo arranjo físico do FMS. Diferentes

disposições dos equipamentos levam a mudanças não apenas na topologia, mas também no

seu comportamento. Uma esteira pode, por exemplo, ter seu comprimento aumentado para

atingir novos equipamentos; isso pode exigir que sejam incluídos novos sensores e travas

usadas para bloquear a passagem de paletes.

Modificar o código do modelo comportamental de uma esteira a cada vez que se refaz

o arranjo físico do FMS é, obviamente, muito indesejável. A modelagem do sistema de

manufatura se tornaria demasiado trabalhosa e demorada, agravada pela possibilidade de

incorrer em erros de programação.

Uma possível saída para o problema é oferecida por esteiras modulares: são dados

módulos padronizados, que podem ser ligados conforme necessário para compor o percurso

da esteira; em cada módulo podem ser configurados sensores ou travas. Embora tal

equipamento exista na prática e parecesse uma alternativa viável, surgiram dúvidas quanto:

a capacidade de tal solução representar qualquer esteira possível; e, principalmente, a

facilidade de definir e configurar uma esteira completa utilizando módulos.

Para atender ao requisito de flexibilidade, achou-se conveniente definir a topologia de

uma esteira, seus sensores e travas, utilizando uma estrutura de dados semelhante a já

utilizada em malhas de transporte. Tal estrutura poderia ser preenchida a partir do software

de auxílio a definição do arranjo físico, com informações fornecidas pelo usuário. Utilizando

um modelo comportamental padrão, bastaria parametrizar o equipamento com tal estrutura

de dados para realizar a simulação. Dentro dessa abordagem, necessidades muito

específicas podem requerer modelos comportamentais diferentes, mas que podem ser

obtidos a partir do padrão fornecido. Embora não se garanta que qualquer esteira possa ser

simulada com essa técnica, está claro que o escopo de possibilidades abrangidas é bastante

amplo, com extrema flexibilidade de uso.

A estrutura de dados de definição de esteira não está implementada mas consiste de

trechos ou segmentos, similares aos utilizados em malhas de transporte. O modelo

comportamental deve se adaptar para funcionar de acordo com as informações obtidas; a

configuração e operação da esteira consiste dos tópicos a seguir.

Definição da topologia: a topologia da esteira é definida por uma estrutura de

dados lida a partir do disco. As informações contidas nessa estrutura orientam o modelo


comportamental da esteira para atualizar o posicionamento dos objetos que estiverem sendo

transportados.

Definição dos pontos de interação: diferente dos demais equipamentos, nas

esteiras os pontos de interação são definidos em função do arranjo físico. Para tratar este

caso foi criado o conceito de ponto de interação dinâmico. Um PIP dinâmico é instanciado e

posicionado no espaço em tempo de execução, pelo esteira que o “possui”.

Definição de volumes: conforme discutido na seção 5.2.1, no tópico “Interações

físicas com esteiras”, se admitirmos que uma peça possa ser depositada em qualquer

posição na superfície da esteira, torna-se necessário implementar volumes de teste (bouding

boxes). Um equipamento como um robô conseguirá depositar um objeto na esteira, desde

que sua garra esteja dentro do volume que envolve a superfície de transporte.

Como a esteira é composta por segmentos, durante a carga da estrutura de dados

que define sua topologia deverão ser calculados e definidos os volumes espaciais que

circunscrevem cada um desses segmentos (um exemplo é representado na Figura 5.1). Tais

volumes serão posteriormente usados pelo módulo de ambiente físico para tratar as

interações físicas. Este recurso foi projetado e especificado, na hipótese de que no futuro se

verifique ser realmente necessário implementá-lo.

Movimentação de objetos: a velocidade de deslocamento e o comprimento de cada

trecho da esteira devem ser utilizados pelo modelo comportamental para calcular o tempo

gasto por uma peça ao percorrer tal segmento. Devem ser agendados eventos

correspondendo ao término do percurso de um segmento por uma peça, trantando-se os

seguintes casos particulares:

• sensor: se um objeto (peça ou palete) chegar a uma posição em que há um

sensor, agenda-se um evento de aviso ao controle;

• trava: se um objeto chega a uma posição contendo uma trava, verifica-se o

estado aberto ou fechado da trava, e impede-se ou não a movimentação de

objetos;

• trecho (segmento de reta ou arco de circunferência): se um objeto estiver em

trânsito sobre um trecho, calcular o tempo de percurso e agendar um evento para

a hora de saída de cada objeto do trecho considerado. Terminado o percurso,

verificar o próximo trecho e agendar o evento final correspondente.

Se nenhum objeto estiver sobre a esteira, o equipamento pode ficar em

funcionamento com um único evento agendado: o de MTBF.

A atualização geométrica consiste no reposicionamento dos objetos sendo

transportados. Os cálculos necessários são praticamente idênticos aos já apresentados para

102 Capítulo V

veículos de transporte. A movimentação é realizada alterando a posição do PIP, executando

uma chamada como:

ponto_de_acesso[i].PutAt (x, y, z);

Atualmente é possível simular uma esteira codificando explicitamente no modelo

comportamental toda a geração de eventos e lógica descrita para movimentação de objetos.

Durante os testes do simulador implementou-se uma esteira simulada dessa maneira. As

diferenças em relação a esteiras em que a topologia seja definida num arquivo específico

são:

1) o modelo comportamental poderá ser genérico, sendo parametrizável pelo arquivo

de topologia. Em consequência, mudar o arranjo físico do FMS e a forma de uma esteira não

implicará alterar o código do modelo comportamental; e

2) a animação gráfica poderá apresentar a superfície da esteira. Enquanto a

informação de topologia não está disponível, como no caso da esteira implementada durante

os testes do simulador, as peças são representadas em movimento sobre uma superfície

invisível.

5.5 Interface de equipamentos com controle

Num FMS ‘real’, as trocas de informações entre controle e equipamentos acontecem

através de uma rede local. Existem diferentes tecnologias de implementação; uma das mais

conhecidas na literatura é o protocolo MAP/TOP. No simulador de FMS a rede de

comunicações foi completamente abstraída, cabendo ao usuário apenas a identificação de

equipamento destino ao iniciar uma comunicação a partir do controle.

Todas as trocas de informação entre equipamentos e controle, em ambos os sentidos,

são realizadas por meio de eventos. Como já foi comentado, o kernel do simulador atua

como um roteador de mensagens. Podemos distinguir dois tipos de trocas de mensagens,

com respeito a maneira de executá-las no simulador:

• comandos e informações originadas no controle, destinadas a equipamentos; e

• respostas dos equipamentos ao controle.

A primeira situação é resolvida pelo agendamento de um evento, por parte do

controle, ao equipamento destino. Como os dados devem ser enviados pelo kernel no

mesmo instante em que foram gerados, isso é feito pelo agendamento de um evento

imediato, isto é, para ser despachado na hora atual. Isto é ilustrado a seguir:


CParametros parm(2); parm.AtribuiParametro (1.25477); parm.AtribuiParametro (0.0332); AdicionaEvento (CONTROLE, TORNEAR, id_torno, hor a_atual, &parm);

No código exemplificado são criados dois parâmetros do tipo real. Em seguida utiliza-

se a API do simulador para agendar um evento do controle para um equipamento,

identificado por um id, passando-lhe um comando e os dois parâmetros. A hora para

despacho desse evento é a hora atual do relógio, presente na variável hora_atual de

CEquipamento .

No caso das respostas de equipamentos ao controle utiliza-se uma interface mais

simples, exemplificada a seguir:

CParametros parm(2); parm.AtribuiParametro (OPERACAO_OK); parm.AtribuiParametro (0.0331); AdicionaResposta (ID_RESPOSTA, &parm);

Não é necessário identificar o destinatário da resposta, bastando preencher um

parâmetro de identificação do tipo da resposta e, opcionalmente, enviar parâmetros.

As respostas são direcionadas ao controle do FMS, ficando disponíveis em um buffer.

Respostas não utilizadas são sobrepostas quando é gerado um novo sinal de resposta, do

mesmo tipo e do mesmo equipamento.

5.6 Conclusão

Este capítulo apresentou a organização interna do simulador e sua lógica de

funcionamento. Foram descritos o modelo comportamental e a operação simulada dos

equipamentos, bem como a interação do modelo comportamental com o núcleo do

simulador.

Os eventos desempenham um papel fundamental no funcionamento do simulador.

Eventos coordenam o início e fim de processos simulados nos equipamentos, controlam a

geração de quadros de animação gráfica e são também utilizados para transportar

mensagens entre os equipamentos e o controle do FMS.

O modelo comportamental de um equipamento é implementado como uma classe

derivada da classe CEquipamento . Essa classe provê a interface ou API com o núcleo de

simulação, provendo funções para realizar tarefas como como:

- agendamento de eventos, geralmente utilizado por um equipamento para agendar o

final de um processo;

104 Capítulo V

- escrita de mensagens no console, para depuração dos modelos simulados;

- realização de interações físicas de trocas de peças e paletes entre equipamentos;

- obtenção de informações sobre malhas de transporte e posicionamento de

equipamentos como AGV’s que se movimentam no chão-de-fábrica.

No projeto dos modelos comportamentais e da API do simulador procurou-se tornar o

mais simples possível a tarefa do programador de um equipamento. Ao implementar essa

característica não se deixou de cumprir nenhum dos requisitos funcionais do simulador.

As funções de atualização de geometria, animação gráfica e interações físicas são

processadas pelo módulo de animação gráfica e ambiente físico do simulador que é

apresentado no capítulo 6.

Implementação do Animador Gráfico e Ambiente Físico 105

106 Capítulo VI

6

Implementação do Animador Gráfico e Ambiente Físico

Durante o projeto do simulador analisaram-se diversas alternativas para

implementação da animação gráfica. Entre as condições que influenciaram as decisões

tomadas estavam, principalmente: a economia de esforços pela utilização de softwares

prontos; os dados necessários para animação e a comunicação com o modelo

comportamental; e as características de execução do simulador, que poderiam influenciar

sobre toda a arquitetura envolvida com a função de animação.

A função de animação antes (em ANALYTICE) limitada a um recurso de apoio ao

usuário, mostrou possibilidades de solução para alguns dos problemas de simulação de FMS.

Dessa forma, ela acabou por tornar-se essencial para execução da arquitetura projetada, o

que é ilustrado pela definição e utilização dos pontos de interação física.

Este capítulo descreve aspectos de projeto e destaca pontos importantes relacionados

com a implementação do módulo de animação gráfica e ambiente físico do simulador.

6.1 CAD e Animação Gráfica

Na especificação inicial do simulador cogitou-se utilizar o mesmo software de CAD em

que seria feita a modelagem geométrica para executar também a animação gráfica. A

maioria dos programas mais sofisticados como planilhas, pacotes de cálculo e engenharia

fornecem mecanismos de interoperabilidade como DDE ou API's de programação. Pretendia-

se então interfacear o simulador de FMS com um programa CAD, que seria usado para

realizar a saída gráfica.

O primeiro CAD avaliado foi o software SolidWorks, que é utilizado para projeto de

peças usinadas e produtos compostos. Este CAD apresenta como características principais:

modelagem de sólidos; produtos compostos formados por objetos; definição de hierarquias

de objetos correspondendo a cadeias cinemáticas; funções para realizar movimentação de

objetos; reconhecimento de colisão (não permite interpenetração de sólidos); recursos para

melhoria de realismo gráfico, como texturas, iluminação e sombras. SolidWorks fornece uma

"There is no more difficult art to acquire than the art of observation, and for some men it is quite as difficult to record an observation in brief and plain language." -William Osler, Aphorisms from His Bedside Teachings and Writings


extensa API, podendo ser linkado com aplicações escritas em VisualBasic ou Visual C++. A

nova versão disponível a partir de 1999 oferece um módulo denominado 'SolidWorks

Animator', capaz de gerar arquivos .AVI (de vídeo) e realizar apresentações de peças

individuais ou produtos compostos. Embora todas as características mencionadas levassem a

pensar que o software resolveria a implementação de animação gráfica, verificaram-se

depois algumas restrições que viriam a comprometer a possibilidade de implementar o uso

dessa ferramenta ou outro CAD para a função de animação do simulador.

A hipótese de uso de um CAD para saída gráfica da animação dependia de

implementar a interoperabilidade entre o simulador e um software de CAD. Teoricamente

este é um objetivo plenamente factível, bastando criar uma camada de interface que

propicie a necessária troca de dados e comandos entre os programas, usando um

mecanismo de comunicação apropriado. Uma vez que não existe uma padronização entre os

programas existentes, para cada diferente CAD se pensava construir, conforme necessário,

uma camada de compatibilização de interface. A Figura 6.1 a seguir ilustra essa abordagem.

Figura 6.1 – Interface entre simulador e programa CAD.

A implementação neste caso dependeria principalmente das características

necessárias nas diferentes possíveis interfaces de compatibilização, para cada CAD que se

decidisse utilizar. A menos então que se realizasse um estudo comparativo entre as API's de

alguns programas CAD, se incorreria no risco de implementar uma solução satisfatória

apenas para uma ferramenta em particular, talvez tornando muito difícil ou mesmo

inviabilizando a construção da interface de compatibilização para outro programa utilizado

para saída de animação. Entre os pontos a considerar ao escrever a API do simulador

tem-se:

módulo de animação gráfica

Simulador

CAD I

CAD II

API

API camada de compatibilização

108 Capítulo VI

i) o diálogo com um CAD para fazer a representação de um FMS completo a partir da

carga de modelos geométricos de equipamentos individuais;

ii) a identificação de cada equipamento e seus componentes móveis para efetuar

animação; e

iii) outras informações de interesse, como a possibilidade de detectar colisões e a

maneira pela qual tal ocorrência seria informada pela API do CAD e daí transmitida ao

simulador.

O problema com a arquitetura de animação gráfica agora seria determinar a priori,

todo o protocolo de comunicação necessário para programar as interfaces de

compatibilização, com a complexidade mais baixa possível.

Uma análise não aprofundada da API de SolidWorks foi suficiente para constatar que a

escrita da interface de compatibilização demandaria um conhecimento extenso da lógica do

CAD, ou seja: como carregar modelos de objetos, identificá-los e executar operações de

movimentação. Diga-se de passagem que a documentação da API de SolidWorks

mencionava as funções de rotação e translação, mas parecia indicar a disponibilidade só em

uma próxima versão; a informação não foi confirmada pelo suporte do produto. Outro

complicante era o fato do programa ter sido projetado para modelagem de produtos

compostos; isto significa que um FMS seria representado como um gigantesco produto

composto e não um agregado de equipamentos. Isso adicionaria complicações na interface

de compatibilização com o simulador para mapear equipamentos e suas partes móveis às

'peças' correspondentes daquele pseudo produto representado dentro de SolidWorks.

Outra alternativa para realizar a animação gráfica seria codificar um módulo de

animação importando os modelos geométricos de um CAD e os dados sobre arranjo físico de

um aplicativo específico. Construirn um módulo de animação já seria uma tarefa bem menos

custosa do que escrever um programa de modelagem de sólidos. Como ganhos por esta

abordagem teria-se um programa auto-suficiente para simulação e animação, uma

simplificação radical na comunicação entre os módulos executores dessas duas funções e a

certeza de poder controlar condições especiais de execução, como taxa de frame-rate.

Examinadas as alternativas, optou-se por implementar um módulo de animação. A decisão

por esta abordagem ocorreu juntamente com a escolha dos arquivos ".3DS" para importação

dos modelos geométricos. Futuramente, outros formatos de arquivo poderão ser

acrescentados.


6.2 Bibliotecas de implementação de animação gráfica

O modelo comportamental dos equipamentos, descrito na seção 5.2, foi projetado de

forma a simplificar a tarefa do programador de um equipamento. Este concentra-se apenas

na representação (i.e., codificação) da operação da máquina. O tratamento de animação

dentro do modelo comportamental ficou reduzido ao cálculo e atualização das variáveis

relacionadas com geometria. A apresentação do equipamento na tela, inclusive refletindo a

atualização das variáveis, é transparente ao programador.

Entretanto, para obter essa simplicidade foi preciso implementar na arquitetura de

simulação todos os mecanismos necessários para construir a representação tridimensional

do equipamento na tela. Para cumprir com esse objetivo identificam-se três funções: i)

obtenção do conteúdo das variáveis de geometria; ii) cálculo da nova situação das partes

móveis de um equipamento; e iii) apresentação dos resultados no vídeo. A primeira função,

de obtenção de valores, foi facilmente solucionada empregando o mecanismo já estabelecido

para monitoração das variáveis de estado (seção 5.2). A implementação das funções

restantes dependeriam de soluções escolhidas para o projeto do módulo de animação como

um todo.

A programação de visualização dos modelos geométricos no módulo de animação

gráfica poderia ser realizada através de dois caminhos alternativos:

• utilização de bibliotecas prontas para animação gráfica no contexto de

programação de jogos;

• utilização de bibliotecas genéricas para apresentação de imagens 3D.

Foi feita uma rápida análise comparativa entre algumas bibliotecas que se poderia

empregar, estando comentadas a seguir: 1) Crystal Space, biblioteca para programação

de jogos desenvolvida para LINUX; 2) Direct3D, biblioteca da Microsoft; e 3) OpenGL, da

Silicon Graphics.

6.2.1 Bibliotecas para jogos

No caso de bibliotecas prontas para implementação de jogos, enquadram-se diversas

opções que variam desde bibliotecas freeware até softwares comerciais cujo preço do código

fonte chega a casa de dezenas de milhares de dólares. Geralmente as soluções encontradas

apresentam bastante sofisticação. Crystal Space é uma biblioteca freeware projetada para

codificação de jogos em computadores pessoais. Está em desenvolvimento em ambiente

LINUX, dela participando mais de cem programadores e havendo versões (ports) disponíveis

para DOS, Unix (X-Windows), Linux (X-Windows, SVGA-lib, Glide, OpenGL), Windows-32

110 Capítulo VI

(DirectDraw, Direct3D, OpenGL, Glide), Macintosch, Amiga, OS/2, NextStep, OpenStep e

Rhapsody.

Crystal Space é um exemplo típico dos ambientes disponíveis e oferece recursos

como:

• texturas podem ter tamanho arbitrário (potência de dois) e não precisam ser

quadradas; podem ser mapeadas para polígonos de diversas maneiras

(rotacionadas, escalonadas, espelhadas);

• cores dinâmicas com sombras suaves (soft shadows) e efeito de fog volumétrico;

• sistema hierárquico para detecção de colisão (por bounding-box);

• utiliza COM para comunicação entre layers (ex.: 3D engine e 3D rasterizer),

mesmo em plataformas que não suportam COM;

• suporte à MMX, 3D-Now!, e aceleração gráfica para OpenGL e Glide.

Aos recursos gráficos somam-se diversas características específicas para a

programação de jogos, como suporte à rede, suporte à sons e ferramentas para editar

cenários.

Os softwares dessa categoria – bibliotecas e outros recursos destinados a

programação de jogos – se destacam pela elevada performance gráfica e pelas facilidades

para construção e movimentação de objetos na tela. O código freeware impressiona pela

qualidade, sendo que novas extensões como drivers para lançamentos de placas de vídeo e

aperfeiçoamentos de algoritmos são continuamente liberados.

Infelizmente, o fato das bibliotecas serem projetadas com um propósito específico as

torna inadequadas para a animação que se pretende realizar. Em alguns casos existe um

número de funções e características que não interessam para a animação de FMS e que

acabam por representar obstáculos para o projeto. Crystal Space, para exemplificar, foi

projetado para compor labirintos em três dimensões. Sempre que um polígono é designado

como ‘portal’, o algoritmo de renderização da cena é recursivamente aplicado para

determinar o conteúdo daquele polígono – que pode ser a visão de uma outra sala. Estas e

outras características contribuem com complicações para modelar graficamente o FMS e

também resultam em carga de processamento desnecessária, diminuindo a performance que

se pretende obter. Na animação do FMS poderão existir na mesma cena dezenas de objetos

móveis simultaneamente – diferente do que acontece tipicamente nos jogos

computadorizados. Tais fatores levaram então a abandonar essa alternativa.

6.2.2 Direct3D – Microsoft

DirectX, desenvolvida pela Microsoft, é um grupo de tecnologias visando suportar

programação multimídia dentro da família de sistemas operacionais Windows. Naturalmente,


uma das aplicações comuns é a programação de jogos. Através de DirectX está disponível um

conjunto de API’s com diversos propósitos, como: geração de gráficos, de sons, suporte a

dispositivos de entrada como mouse e joystick. As diversas funções são implementadas por

componentes separados: DirectDraw®, Direct3D®, DirectInput®, DirectSound®, DirectPlay®,

e DirectMusic®. Estes componentes formam a camada de baixo nível do sistema. Sobre ela

está localizada uma camada denominada “DirectX Media Layer” e que contém seus próprios

componentes: DirectShow™, DirectAnimation™ e DirectX Transform. A camada intermediária

provê funções para coordenar efeitos de multimídia, como sincronizar movimentos e

sonorização dentro de jogos.

Atualmente está em desenvolvimento a versão 8 da biblioteca Direct3D. As primeiras

versões, de 1 a 3 foram reconhecidas como praticamente não-utilizáveis; a versão 5 incluiu

uma API nova, anunciada como de uso mais fácil que as anteriores. O fato de novas versões

serem liberadas com freqüência é considerado negativo, já que as modificações realizadas

nem sempre asseguram a compatibilidade para os desenvolvedores de código.

Para realizar a implementação do animador seriam utilizados apenas as capacidades

gráficas de DirectX e descartados outros recursos como suporte a som e entrada de joystick.

Ainda que houvesse interesse apenas nessa parcela da biblioteca da Microsoft, a excessive

complexidade da API desmotivou seu emprego para implementar o animador. Na próxima

seção apresentamos um exemplo de código ilustrando essa característica.

6.2.3 OpenGL – Silicon Graphics

OpenGL foi precedida por outra biblioteca conhecida como IRIS GL, ambas

desenvolvidas pela Silicon Graphics Inc. A IRIS GL tinha o propósito de ser uma biblioteca

portável entre diversas linhas de workstations. Embora não mantenha compatibilidade com

código escrito usando IRIS, Open GL preservou o conceito de uma API fácil de utilizar e a

habilidade de renderizar objetos em três dimensões com eficiência. A nova biblioteca se

tornou um padrão importante, controlado por um consórcio – OpenGL Architectural Review

Board, composto por empresas como IBM e Digital Equipment.

A biblioteca da Silicon trabalha com primitivas de baixo nível: os objetos em duas e

três dimensões são construídos a partir de vértices e segmentos de reta. Isto é feito

facilmente, bastando combinar seqüências de vértices para formar polígonos que por sua vez

podem determinar um sólido no espaço. OpenGL não trabalha com sólidos ‘reais’ mas, a

partir da definição de suas faces, permite modelar e apresentar objetos e cenários

complexos, além de movimentá-los segundo uma hierarquia (correlata a uma cadeia

cinemática).

112 Capítulo VI

OpenGL foi projetada para utilização em estações de trabalho com o propósito de criar

imagens de alta qualidade e exibe recursos sofisticados de renderização de imagens. A

biblioteca foi originalmente utilizada em aplicações profissionais e científicas. A partir da

evolução do poder de processamento dos computadores pessoais, todos os recursos de

OpenGL passaram a estar disponíveis nos PC’s, existindo versões da biblioteca para

plataformas como Windows, MacOS, UNIX e BeOS.

O código a seguir ilustra a facilidade de programar em OpenGL

comparativamente a Direct3D. O exemplo foi obtido na Internet, sendo criado por John

Carmack – programador da Id Software, uma renomada empresa no ramo de jogos de

computador.

Tabela 6.1 - Comparação entre código OpenGL e Direct3D.

OpenGL Direct3D

glBegin (GL_TRIANGLES); glVertex (0,0,0); glVertex (1,1,0); glVertex (2,0,0); glEnd ();

(psuedo 12 code, and incomplete) v = &buffer.vertexes[0]; v->x = 0; v->y = 0; v->z = 0; v++; v->x = 1; v->y = 1; v->z = 0; v++; v->x = 2; v->y = 0; v->z = 0; c = &buffer.commands; c->operation = DRAW_TRIANGLE; c->vertexes[0] = 0; c->vertexes[1] = 1; c->vertexes[2] = 2; IssueExecuteBuffer (buffer);

A biblioteca OpenGL foi a escolha adotada para implementação do simulador, pelos

seguintes motivos:

• qualidade da API: amplos recursos e facilidade de uso;

• padronização: a biblioteca está disponível em diversas plataformas e mantém-se

estável;

• qualidade dos resultados: a sofisticação de recursos da biblioteca satisfaz e

excede as necessidades do simulador de FMS;

• adequação à cinemática: a API da biblioteca oferece recursos que facilitam a

implementação - especificamente o empilhamento de matrizes de transformação;

e

• aceleração gráfica: existe aceleração por hardware disponível para diversas

placas no mercado;

12 “psuedo”, mantido do original extraido da Internet.


6.3 Modelagem geométrica e cinemática

A realização da animação gráfica e das funções de interação física na simulação

dependem dos modelos geométrico e cinemático de cada equipamento, além do modelo

comportamental. Este último, como já mencionado, é compilado em uma DLL. Para realizar

a execução simulada de um equpamento haviam duas alternativas para tratar essas

informações: i) incluir na DLL de um equipamento uma área de dados contendo os modelos

geométrico e cinemático; ou ii) empacotar os modelos de geometria e cinemática em um

arquivo separado da DLL. Para implementar a primeira alternativa, seria preciso criar uma

estrutura de dados estática dentro do modelo comportamental do equipamento, preencher

com os dados de geometria e cinemática e então compilar gerando a DLL. No segundo caso,

seria utilizado algum mecanismo para relacionar o modelo comportamental a seu respectivo

arquivo de modelos geométrico e cinemático. Uma vantagem importante da segunda solução

é a flexibilidade, permitindo que o usuário altere a aparência de um equipamento ou corrija

algum erro na geometria ou cinemática, sem obrigá-lo a recompilar a DLL. Esta segunda

opção foi adotada.

Foi implementada uma ferramenta para modelagem cinemática que importa os

arquivos de geometria (".3DS"), interage com o usuário e grava arquivos contendo os dados

necessários para a posterior animação gráfica, em um formato próprio com uma extensão

denominada ".KKT" (kinematics tree). O funcionamento do software consiste apenas em

dialogar com o usuário para definição da árvore cinemática e para obtenção de alguns dados

adicionais. As seções a seguir detalham as estruturas de dados de geometria e cinemática,

deixando claras todas as informações envolvidas. A seção 6.3.4 faz uma rápida descrição do

programa para modelagem cinemática.

6.3.1 Modelo Geométrico

A estrutura de dados para geometria foi projetada sob alguma influência do formato

de arquivos ".3DS". A simplicidade da estrutura não levará a grandes dificuldades caso haja

interesse em importar arquivos de geometria a partir de outro formato.

A cada sólido da representação tridimensional do equipamento corresponde um

registro no modelo geométrico. A implementação atual utiliza um array alocado

estaticamente, dimensionado para cinqüenta sólidos. Nesse array são carregados os sólidos

definidos no arquivo “.3DS”, que incluem os eixos de transformação13. Isso permite um

modelo com as seguintes características:

13 A estrutura de dados do arquivo “.3DS” não usa representações diferentes para segmentos de reta e

para sólidos. A simplicidade da implementação foi mantida nas estruturas de dados internas do simulador.

114 Capítulo VI

- vinte e três objetos móveis;

- os respectivos vinte e três eixos de transformação;

- eixos x, y e de escala.

O programa 3D Studio permite que um sólido seja uma figura complexa, formada pela

união de outros sólidos. Assim, o limite de cinqüenta elementos mencionado acima

extrapolou completamente as necessidades durante os testes do simulador. Havendo

necessidade, entretanto, seria uma modificação muito simples utilizar alocação dinâmica.

Cada registro de sólido geométrico contém os seguintes dados:

struct s_solid { char name [LEN_NAME] ; // nome do sólido (o riundo do CAD) int is_access , // 1 se ponto de acesso is_transform , // 1 se eixo, 0 otherwis e nvertices , // número de vértices nfaces ; // número de faces float *vertices ; // em seqüência: x,y,z, x,y,z ... int *faces ; // seqüência de vértices: v1, v2,v3,v2,v4... float colorR , // cor do sólido colorG , colorB ; };

O array vertices é alocado dinamicamente e contém as coordenadas tridimensionais

de cada vértice do sólido, na sequência: x1, y1, z1, x2, y2, z2, etc.

O array faces também é alocado dinamicamente e contém uma sequência de inteiros

v1, v2, v3, v4 ... vn , onde os elementos v(3*i), v(3*i)+1, v(3*i)+2 ∀ i definem os três vértices de

um triângulo. Como já mencionado (seção 4.3.1), os sólidos são representados em arquivos

".3DS" em malhas de triângulos. Um elemento vi relaciona-se com as três coordenadas de

um vértice do array vertices . A Figura 6.2 a seguir ilustra a estrutura de dados descrita.


sólido 1

sólido 2

sólido 3

sólido n

faces vértices 0 0.000 1 0.000 3 0.000 1.000 0.000 0.000 0.000 -1.000 0.000

Figura 6.2 - Estrutura de dados de armazenamento de sólidos.

Um segmento de reta é representado como um sólido formado por uma única "face"

que tem dois vértices.

A saída gráfica utilizando OpenGL apresenta uma melhora dramática de qualidade ao

utilizar-se iluminação. Para isso é necessário fornecer, para cada face de cada sólido

desenhado, um vetor normal. Esse vetor é utilizado pelo algoritmo de iluminação de OpenGL

e é calculado pelo módulo de animação como o produto vetorial de duas arestas de uma

face.

6.3.2 Representação de pontos de interação física

Um ponto de interação, PIP, identifica, na geometria de um equipamento, o local

exato em que uma peça ou palete pode estar presente. Por exemplo, no caso do Puma 360,

o único ponto de interação existente será a garra.

Para identificar um ponto de interação física em um equipamento, inclue-se em seu

modelo geométrico uma das seguintes figuras geométricas:

- sólido: um sólido geométrico qualquer, como um cubo, é adicionado à forma do

equipamento; o centro de massa do sólido será considerado como o ponto em que o centro

de massa da peça ou palete deverá ser posicionado;

- segmento de reta: um segmento de reta é usado para determinar pontos de interação

física que devem manter uma orientação, utilizados por paletes. Fez-se a restrição de que

116 Capítulo VI

paletes depositados nesses pontos devem estar horizontais em relação ao chão-de-fábrica. No

ambiente de modelagem cinemática determina-se qual dos dois vértices da linha indica o

ponto de interação; o vértice restante indica a direção de orientação. As Figuras a seguir

exemplificam os dois tipos de PIP mencionados.

Figura 6.3a – Definição de ponto de interação física para peça.

Figura 6.3b – Definição de ponto de interação física e orientação

para palete.

Na Figura 6.3a tem-se a definição do ponto de interação de um robô Kuka, no

ambiente de definição de cinemática. Observe-se que o sólido desenhado no punho do robô

(figura à esquerda), uma vez definido como PIP não é mais apresentado na animação gráfica

(figura à direita). Na Figura 6.3b é mostrada uma mesa; o ponto de interação é definido por

um segmento de reta no CAD. No tela do ambiente de cinemática, tal segmento é

apresentado (figura à esquerda), sendo dada ao usuário a possibilidade de escolher em qual

sólido que representa o ponto de interação

reta para definição do ponto de interação e da orientação de palete

cubo que marca o ponto de interação


extremidade da reta ficará o PIP. Nesse ponto geométrico o software de definição de

cinemática apresenta um cubo na tela. A reta fornecida pelo usuário é usada pela animação

gráfica para orientar um palete que seja colocado sobre o PIP. Durante a animação gráfica a

reta e o cubo são suprimidos (figura à direita).

O sólido que representa o ponto de interação deve receber um nome conhecido, que

será referenciado no código do modelo comportamental. O flag ponto_de_interacao do

sólido é marcado como TRUE pelo software de modelagem cinemática.

Durante a carga de um equipamento seu modelo comportamental será solicitado,

através da interface de monitoração, a fornecer o endereço de uma variável do tipo CPIPoint

que corresponda ao sólido ou a linha que representa o ponto de interação física na

geometria.

6.3.3 Modelo Cinemático

O modelo cinemático é uma estrutura arborescente, conforme mencionado na seção

2.2.4. Utilizou-se alocação dinâmica e um fator de ramificação máximo igual a dez. Isto

significa que a partir de um nó cinemático é possível derivar até dez ramos. Na maioria dos

equipamentos observados é utilizado apenas um ramo; são necessários dois para modelar as

duas pinças da garra de um robô. Durante os testes foi modelado um operário e um fator de

ramificação quatro - dois braços e duas pernas. O número dez foi arbitrado por parecer ser

um limite muito difícil de se esgotar. Utilizar uma lista ligada representaria uma pequena

economia de memória, mas também uma complicação injustificável e algoritmos mais

lentos.

Cada nó da árvore cinemática contém as seguintes informações:

struct s_knode { char name [LEN_NAME], // nome do nó cinemátic o variable [LEN_NAME]; // variável no modelo c omportamental int nsolids , // número de sólidos deste nó *solids ; // array de sólidos (índices p/ array Solids) float x0, y0, z0 , // coordenadas do eixo de t ransformação x1, y1, z1 ; int idx_axis , // índice do eixo no array de sólidos. is_rotation, // 1 se transformação = rot ação is_inverted; // 1 se direção invertida e m relação ao original.

118 Capítulo VI

float offset , // posição atual do eixo pr ismático/rotacional min , // limite mínimo (graus / m ilímetros) max ; // limite máximo struct s_knode *son[NUM_SON] ; // array com 10 nós-cinemá ticos-filhos };

Os campos name e variable contém respectivamente os identificadores do nó

cinemático e da variável de geometria associada. solids é um array de inteiros; cada

elemento é um índice, identificando um dos sólidos da geometria do equipamento. Os

campos x0..z0 x1..z1 contém as coordenadas dos dois extremos de um segmento de reta,

que representa o eixo de transformação. Essas coordenadas foram repetidas à partir do A

distinção entre rotação ou translação é identificada pelo flag “is_rotation ”. O flag

“is_inverted” , determina a direção de uma transformação: quando setado, indica que o

vetor associado ao eixo indicado por “idx_axis ” deve ser invertido. O campo “offset ”

contém a posição do nó cinemático como foi definido no CAD; “min ” e “max” definem limites

de movimentação. Finalmente, o array “son ” tem ponteiros para os nós filhos.

6.3.4 Software de auxílio a definição de cinemática

O software para definição do modelo geométrico cinemático funciona a partir da

leitura de um arquivo “.3DS”. O módulo de leitura desse formato de arquivo pode ser

substituído, de forma a permitir que outros formatos - como “.DXF” sejam utilizados se

necessário. Nesse caso o que é preciso fazer é interpretar o arquivo contendo os dados,

traduzindo ou mapeando seu conteúdo para as estruturas de dados definidas pelo simulador

e já descritas nas seções 6.3.1 e 6.3.2.

Uma vez carregados os dados sobre geometria, é apresentada ao usuário a lista de

todos os sólidos geométricos existentes; a partir daí, é preciso preencher as seguintes

informações:

• identificação dos eixos X e Z, utilizados pelo animador para orientar corretamente

o equipamento no chão-de-fábrica;

• identificação do segmento de reta de escala e fornecimento do respectivo

tamanho do segmento, em milímetros.

O usuário constrói a árvore cinemática criando nós e inserindo, em cada nó, os sólidos

que dele fazem parte e um eixo de transformação. Em cada nó, o eixo de transformação

requer os dados:

• definição como eixo de rotação ou de translação;


• definição de sentido, sendo possível inverter a direção do vetor associado ao eixo,

usado na respectiva transformação geométrica;

• nome da variável de geometria no modelo comportamental;

• limites mínimo e máximo de movimentação da junta, fornecido em graus ou

milímetros dependendo do tipo de transformação escolhida;

• posição da junta, também em graus ou milímetros, conforme consta no desenho

importado do arquivo “.3DS”.

Atualmente, as informações sobre limites de movimentação constam apenas como

documentação do modelo; optou-se por requerer ao usuário que explicite no modelo

comportamental esses dados.

Em cada nó cinemático, definem-se pontos de interação escolhendo os sólidos que os

representam e ligando um atributo correspondente. Desta forma, qualquer sólido da

geometria do equipamento pode ser marcado como ponto de interação física.

Finalmente, o software permite alterar as cores dos sólidos e observar o resultado em

vídeo. É possível mover as juntas visualizando instantâneamente as atualizações

geométricas e verificar se o modelo cinemático foi corretamente definido.

A Figura 6.4 a seguir apresenta uma janela do software, durante a definição do

modelo cinemático de um equipamento.

Figura 6.4 – Janela do software de definição de modelo cinemático.

120 Capítulo VI

6.4 Organização do módulo de animação gráfica e ambiente físico

O módulo de animação gráfica e ambiente físico é formado por diversos componentes.

As funções de animação e interação estão distribuídas nesses componentes e envolvem

ainda a participação de: modelo comportamental dos equipamentos, paletes e peças.

Na figura 4.9 foi apresentado um diagrama UML geral do simulador. A seguir

detalharemos melhor as funções que tratam de interações físicas e animação geométrica,

utilizando um diagrama UML mais detalhado.

Figura 6.5 – Diagrama de classes do módulo de animação gráfica e

ambiente físico

O módulo CKinematicsTree realiza as operações de escrita e leitura em disco das

estruturas de dados de geometria e cinemática (arquivos de extensão ".KKT" mencionados

na seção 6.3). É utilizado pelos objetos de animação gráfica, para carga dos modelos

utilizados na simulação e pelo software de definição da árvore cinemática.

CEquipamento

CGAnimatorModule

Malha de Transporte

CMovableObject

CPart CPallet

CEAnimator

consulta variáveis de geometria

posiciona

*

*

0..* CPIPoint

pesquisa vizinho

Slot

0..1 0..1 1..n 0..*

ou

CKinematicsTree


A cada equipamento simulado, CEquipamento , corresponde um objeto de animação

gráfica, CEAnimator . Tal objeto executa os comandos OpenGL que apresentam o

equipamento no vídeo.

A classe CMovableObject implementa dados e funções utilizadas pelo pontos de

interação e pelos objetos palete e peça. A movimentação de um equipamento no vídeo,

calculada por um objeto de animação, causa a atualização de posição de seus pontos de

interação. Esta atualização é propagada a paletes e peças que estejam ligados ao

equipamento.

Os modelos comportamentais de equipamento interagem diretamente com peças

(CPart ) e paletes (CPallet ) nos seguintes momentos: criação e destruição de tais objetos;

modificação de parâmetros como cor; modificação de propriedades como a memória interna

de paletes ou medidas geométricas de peças (seção 5.2).

As estruturas de dados de malhas de transporte são carregadas e mantidas pelo

módulo de animação, responsável pela apresentação das mesmas no chão-de-fábrica.

Equipamentos de transporte, como AGVs, obtêm as informações necessárias para sua

movimentação por meio de requisições ao simulador. Mais de um equipamento pode trafegar

na mesma malha.

Nas próximas seções examinaremos mais detidamente a organização e funcionamento

do módulo de ambiente físico e animação gráfica.

6.5 Objetos de animação

Os objetos de animação gráfica foram utilizados tanto no simulador como no programa

de modelagem cinemática. A classe CEAnimator foi projetada visando portabilidade, tanto

entre programas quanto entre plataformas. A única dependência de compilação existente é em

relação à biblioteca gráfica utilizada: OpenGL. Ainda neste caso, foi evitado o uso de qualquer

função com dependência de implementação14.

Nas seções a seguir será descrita a implementação e funcionamento da classe

CEAnimator.

6.5.1 Inicialização

A primeira função de um objeto de animação gráfica é carregar os dados de geometria

e cinemática, armazenando-os em estruturas de dados próprias. Isto é feito pela execução

da rotina load_ktree () . Esta rotina lê para as estruturas de dados internas de CEAnimator

14 Não foram utilizadas, por exemplo, funções de OpenGL específicas para Windows.

122 Capítulo VI

os dados contidos no array de sólidos (struct s_solids ) e na árvore cinemática, alocados

no objeto CKinematicsTree .

Cada objeto de animação constrói sua própria árvore cinemática. As informações

referentes a sólidos geométricos são traduzidas para comandos OpenGL, sendo armazenadas

em display lists 15.

Durante a carga do modelo geométrico-cinemático, um objeto CEAnimator utiliza a

interface de monitoração de CEquipamento , isto é, a rotina MapeiaPrimitivaToVariavel ()

para obter dados necessários para preencher certas estruturas de dados:

• para cada sólido, a rotina é invocada com o nome do sólido. Se um valor NULL

for retornado, utiliza-se a cor já estabelecida no modelo geométrico. Caso

contrário o valor retornado é interpretado como um ponteiro para uma seqüência

de três bytes16 contendo os componentes RGB (vermelho, verde e azul) da cor do

sólido. Este recurso foi projetado para permitir a criação de luzes ou lâmpadas de

aviso nos equipamentos. Pode ser empregado para mudar dinamicamente a cor

de qualquer sólido;

• para cada nó cinemático, MapeiaPrimitivaToVariavel () é invocada com o

identificador da respectiva variável de geometria existente no modelo

comportamental. O valor retornado é interpretado como um ponteiro para um

double. Caso seja retornado um NULL, o objeto CEAnimator retorna FALSO, o que

significa um erro na carga do equipamento.

6.5.2 Operação

A apresentação do modelo geométrico é realizada por uma rotina recursiva que

percorre a árvore cinemática em profundidade. Inicialmente são computadas rotações em

relação aos eixos x e y, para orientar corretamente o modelo do equipamento no espaço

(parte superior voltada para cima). Em seguida, aplicam-se translações nos eixos x e y

conforme especificado pelo arranjo físico do FMS, e z para que o equipamento esteja

nivelado ao chão-de-fábrica. Por fim, rotaciona-se sobre o eixo z também conforme

especificado no arranjo físico. A orientação dos eixos no espaço pode ser visualizada na

figura 5.3.

Após as operações de posicionamento, é desenhada a base do equipamento,

correspondendo ao nó raiz da árvore cinemática. A cada novo nó processado, aplica-se a

15 Trata-se de um recurso de OpenGL que agiliza o processamento de comandos gráficos.

16 Tanto os arquivos “.3DS” quanto OpenGL utilizam três números em ponto flutuante com essa função. Entretanto, inteiros com faixa de valores [0, 255] são habitualmente usados em programas gráficos. Optou-se pela última opção tornando a interface com o programador mais intuitiva.


transformação de rotação ou translação nele especificada, utilizando o conteúdo da variável

geométrica do modelo comportamental. Tal valor é obtido diretamente por um ponteiro,

conforme descrito no passo de inicialização (seção 5.2.1). Caso a transformação aplicada ao

nó seja uma rotação, o conteúdo da variável é interpretado como um ângulo fornecido em

graus; caso a transformação seja uma translação, interpreta-se como uma distância dada

em milímetros.

Cada nó cinemático é desenhado em um sistema de coordenadas locais, onde o eixo

de transformação passa pela origem. OpenGL aplica às coordenadas fornecidas pelo usuário

a matriz de transformação corrente, que acumula todas as rotações e translações realizadas

até o momento. OpenGL possui ainda as funções glPushMatrix () e glPopMatrix () , que

permitem respectivamente empilhar e desempilhar matrizes de transformação. Este recurso

foi empregado na rotina de desenho do equipamento, simplificando a elaboração do

algoritmo.

Finalmente, a cada nó cinemático as informações sobre cor de sólidos são

consultadas, por meio dos ponteiros referidos na seção anterior.

6.6 Tratamento de interações físicas

6.6.1 Cálculo de cinemática direta

OpenGL permite ainda obter a matriz de transformação atual que é utilizada em seus

cálculos para apresentação de imagens. Em todo nó cinemático em que existe um ponto de

interação, a rotina CEAnimator::draw () obtém a matriz de transformação corrente e a

aplica sobre as coordenadas do ponto de interação. O resultado é a posição física do ponto,

medida em milímetros em relação à origem do chão-de-fábrica. Este procedimento

corresponde ao cálculo de cinemática direta e é a chave para a implementação das

interações físicas no simulador.

Ao utilizar o cálculo de cinemática direta para solucionar a implementação das

interações físicas, criou-se uma dependência da função de simulação de chão-de-fábrica

para a função de animação gráfica. Embora ainda seja possível desligar a geração do evento

TS, é preciso que os equipamentos no mínimo realizem atualização geométrica nos demais

eventos. Isso garante a consistência do estado geométrico de todos os equipamentos para

processamento de interações físicas.

Um erro de simulação poderia ocorrer se, por exemplo, um robô tentasse depositar

uma peça sobre um PIP em movimento, como um AGV. A posição do AGV só é atualizada ao

fim do movimento deste; se a interação ocorrer a posição dos pontos de interação física

124 Capítulo VI

estará incorreta. O mesmo acontece se o evento time-slice estiver ativo mas a interação

acontecer algum tempo antes ou depois desse evento.

Considerou-se que esse tipo de ocorrência é, mais provavelmente, um erro de

programação NC. Não foi implementado nenhum tratamento especial quanto a interações

físicas entre PIP’s em movimento. O único caso admissível é o de esteiras e pode ser tratado

criando pontos de interação dinâmicos. A solução depende da implementação da noção de

volume, comentada na seção 5.2.1.

O cálculo automático de cinemática direta e a implementação de interações físicas

baseadas nesse cálculo satisfez os requisitos de funcionalidade do simulador, valendo

ressaltar:

• não era interesse do trabalho realizar simulação de "caixa-preta", mas sim

aproximar ao máximo a operação física dos equipamentos; a implementação está

assim condizente com o objetivo inicial;

• as coordenadas dos pontos de interação podem ser utilizadas para criar e

verificar os programas NC de robôs e outros equipamentos;

• ao considerar o posicionamento de objetos como foi feito, torna-se possível testar

com maior minúcia o controle do sistema, verificando por exemplo erros de

posicionamento;

• a modelagem do FMS corresponde mais à realidade, já que para realizar

interações físicas não é preciso que o usuário identifique os equipamentos

envolvidos; basta posicioná-los corretamente pois o simulador processará as

interações.

6.6.2 Processamento das interações

No tratamento das interações físicas distingue-se: um equipamento ativo, que realiza

a ação de depositar ou remover um objeto como um palete ou peça; e um equipamento

passivo, no qual o objeto é depositado ou de onde é removido. Geralmente o equipamento

ativo é representado por um robô (outra possibilidade seria um operário). Um caso

intermediário é um AGV munido de um braço robotizado, capaz de retirar um objeto de

outro local ou equipamento e depositá-lo sobre si mesmo (ou o inverso).

O código do equipamento ativo deve explicitar a ocorrência da interação física para

que a mesma possa ser tratada pelo simulador. Para isso estão disponíveis as seguintes

rotinas:

SoltarPalete () ; PegarPalete () SoltarPeca () ; PegarPeca ()

Foi necessário distinguir o tipo de objeto envolvido na interação já que podem haver

casos em que: um equipamento remove um palete de um lugar; ou é retirada apenas uma


peça do palete. Isto acontece quando são usados paletes para transportar várias peças, que

são usinadas individualmente numa estação de trabalho.

O processamento da interação de deposição de um palete, efetuada por um robô

sobre um centro de usinagem é processado da seguinte forma:

1) O robô chama a rotina SoltarPalete ()

2) O módulo de ambiente físico recebe uma chamada de função, parametrizada com o

endereço do PIP do equipamento ativo. Chamaremos este ponto de po, ponto origem. Todos

os pontos de interação existentes no FMS simulado são cadastrados em uma lista; esta lista

é percorrida, obtendo-se o PIP mais próximo de po existente: o ponto destino, pd.

3) Se a função é SoltarPalete () , verifica-se se pd está vazio; caso contrário a

interação acaba com sinalização de colisão. O mesmo se aplica a po e a rotina PegarPeca

() .

4) Calcula-se um pseudo-diâmetro para o palete, d, como sendo a média aritmética

da soma dos comprimentos x, y e z desse objeto. Calcula-se a distância l, em linha reta,

separando po e pd. Se l > cd, considera-se que a distância entre os pontos de interação era

excessivamente grande. O processamento acaba e é sinalizado erro ao equipamento ativo. A

constante c é um valor percentual do tamanho do palete, por exemplo 5% = 0,05 .

5) O palete é transferido de po para pd, pelo seguinte código:

CPallet *aux; aux = po.pallet; po.pallet = NULL; pd.pallet = aux;

6) É gerado um evento, avisando ao centro de usinagem de que acaba de receber um

palete.

7) O robô termina seu processamento e devolve controle ao simulador.

8) O centro de usinagem recebe o evento de interação, parametrizado com o

equipamento que iniciou o processo. Caso seja detectado alguma inconsistência, como

recebimento de peça em um momento inválido, o centro de usinagem pode chamar a rotina

de falha de interação. Caso contrário, a interação física termina aqui.

9) O ambiente físico recebe o aviso de falha de interação, parametrizado com o

identificador do robô. É gerado um evento de falha de interação.

10) O robô recebe o evento de falha de interação e decide se simplesmente o ignora,

aplica uma distribuição de probabilidade para decidir sobre sua quebra ou realiza algum

outro processamento.

O processamento para a rotina PegarPalete () funciona de forma similar.

126 Capítulo VI

A rotina SoltarPeca () deve tratar a deposição de uma peça sobre o PIP de um

equipamento ou sobre um palete. O mesmo se aplica a PegarPeca () . Para a rotina

SoltarPeca () , o algoritmo consiste em linhas gerais do seguinte:

1) dado o PIP origem, po, encontrar o PIP destino, pd

2) se pd estiver vazio, realizar processamento idêntico ao já explicado para

SoltarPalete () . Se pd contiver um palete, executar o seguinte código:

pd->pallet->ReceivePartNearTo (po);

O algoritmo dentro do objeto palete consiste em determinar sobre qual slot a peça

(apontada por pd->part ) será depositada (v. seção 5.2); determinar ocorrência de colisões e

relatar erros; executar a deposição da peça, se possível.

O modelo de interação implementado, descrito nesta seção, é uma simplificação dos

fenômenos que acontecem numa interação física real. Diversos dados como atrito ou

trepidação não são tratados. Algumas situações como um robô abrir a garra e soltar uma

peça por engano no chão, são resolvidas simplesmente pela emissão de uma mensagem de

erro ao usuário do simulador. Contudo, o tratamento das interações físicas como

implementado satisfaz plenamente os requisitos de modelagem anteriormente definidos para

o simulador.

6.6.3 Posicionamento de peças e paletes

No algoritmo da rotina SoltarPalete apresentado na seção anterior, no passo 5

ocorria a transferência do palete na seguinte linha de código:

pd.pallet = aux;

O operador '=' está sobrecarregado na classe CPIPoint . Quando aquela atribuição é

executada, o objeto recebido na interação, como o palete em nosso exemplo, é ajustado

para ficar posicionado corretamente sobre o equipamento destino - centro de usinagem. Isto

tem o propósito de simular o encaixe da peça ou palete na correta posição sobre o

equipamento.

Em todos os equipamentos nos quais um objeto (peça ou palete) é encaixado num

ponto de interação física - como acontece com AGV’s ou tornos - tal objeto é plotado em

coordenadas locais, fazendo com que o centro de coordenadas (0, 0, 0) coincida com o PIP

e com o centro do objeto. O modelo geométrico e cinemático do equipamento que possui o

objeto, fornece uma matriz de transformação que, aplicada ao palete, o posiciona e orienta


corretamente, resultando em sua apresentação gráfica colocado sobre o PIP. No caso de

robôs isto não acontece: a garra pode fechar-se sobre virtualmente qualquer ponto em torno

de uma peça ou palete. Neste caso a matriz de transformação do robô, aplicada ao palete,

irá resultar numa orientação errônea para aquele objeto capturado, para efeito de

apresentação no vídeo. A solução ao problema para o caso de um palete capturado por um

robô consiste em:

i) obter as coordenadas de todos os vértices do palete e de todos os slots como

coordenadas do chão-de-fábrica, não mais relativas ao equipamento que originalmente o

continha (ex., um centro de usinagem);

ii) calcular tais coordenadas em função da atual matriz de transformação do PIP do

robô, ou seja, a garra;

iii) utilizar as novas coordenadas para plotagem do palete durante todo o processo de

captura, movimentação e soltura do palete pelo robô;

iv) ao depositar o palete sobre outro equipamento (ex., um AGV), utilizam-se

novamente as coordenadas locais do palete (onde (0, 0, 0) significa centro do palete),

aplicando-se a matriz de transformação do equipamento alvo (o AGV) para apresentar o

objeto em sua posição correta, encaixado no ponto de interação física.

A solução não foi implementada por três motivos: i) haviam prioridades mais sérias a

resolver no simulador; ii) a solução ao problema já está basicamente projetada, bastando

refiná-la e implementar; e iii) optou-se pela imprecisão de orientação em favor de menor

carga de processamento.

Entretanto, alguns detalhes importantes como a disponibilidade de variáveis para

armazenar as coordenadas calculadas no passo (ii) e o controle sobre quais coordenadas

usar para plotagem no passo (iii) já estão delineadas no código do simulador, simplificando

a tarefa de implementação se, futuramente, houver a necessidade de incluir o recurso.

Para a apresentação de peças não recomenda-se implementar toda esta solução; uma

vez que peças são apresentadas como simples paralelepípedos (não há detalhamento de sua

geometria), as mudanças instantâneas de orientação não vão representar um defeito sério

na visualização da animação. Uma alternativa de solução imediata é plotar um dodecaedro

ou outro sólido mais próximo de uma esfera no lugar das peças, o que não foi implementado

atualmente com o propósito de economizar esforço de processamento.

6.7 Tratamento de malhas de transporte

Cada veículo de transporte (como um carro sobre trilhos ou um AGV) deve estar

obrigatoriamente associado a uma malha de transporte. Ao carregar equipamentos

individualmente no simulador, exige-se para veículos de transporte que a malha a ser

128 Capítulo VI

utilizada já tenha sido carregada anteriormente. Isto pode acontecer de duas maneiras: i) o

usuário carrega a malha e posteriormente o equipamento, no caso de uma simulação de

equipamento individual; ou ii) o usuário carrega um arquivo de projeto de FMS, que garante

a ordem correta de leitura de dados. O arquivo de projeto atualmente implementado

contém:

• a identificação (nome) de cada equipamento,

• o caminho e nome do arquivo contendo o modelo comportamental (que

internamente contém referência ao arquivo com o modelo geométrico-

cinemático),

• o posicionamento e orientação do equipamento no chão-de-fábrica e

• o caminho e nome dos arquivos com as malhas de transporte.

A função do módulo de animação gráfica e ambiente físico em relação às malhas de

transporte, é fornecer aos veículos as informações necessárias para orientar sua

movimentação. Na verdade é simulado o processo físico de interação das rodas do veículo

com um trilho que lhe direciona. Os sistemas que utilizam cabos enterrados permitem a

criação de percursos virtuais: passando freqüências diferentes por cada cabo e programando

cada veículo para seguir uma freqüência é possível criar vários percursos diferentes.

6.7.1 Representação das malhas

As malhas são definidas em arquivos texto, com um formato interno simples que

permite a edição direta pelo usuário ou a geração a partir de um software de definição de

arranjo físico. O percurso é dividido em seções, formadas por: segmentos de reta; arcos de

circunferência; bifurcações; e pontos de parada, denominados sensores. O arquivo de

definição de malha deve conter ainda os seguintes dados:

• identificador (nome) da malha;

• número de elementos que formam a malha

• número de freqüências; determina o número de cabos utilizados em cada

segmento, limitando o número de diferentes caminhos que podem ser definidos

simultaneamente na malha; e

• cor da malha de transporte, para apresentação na animação gráfica.

Para explicar a composição de uma malha de transporte utilizaremos o exemplo

apresentado na Figura 6.6 a seguir.


Figura 6.6 - Diagrama esquemático de uma malha de transporte.

Os elementos com rótulo de prefixo r são definidos como segmentos de reta, sendo

fornecidas as coordenadas (x, y) de seus dois extremos. Os segmentos com rótulos c’s são

arcos de circunferência, definidos por: coordenadas do centro, raio, ângulo inicial e ângulo

final. O elemento s1 é um sensor ou ponto de parada, definido apenas pelas suas

coordenadas (x,y). Os elementos b1 a b4 são bifurcações e apenas fazem a relação lógica

entre os elementos que estão fisicamente ligados, para uso em algoritmos do ambiente

físico.

A bifurcação b1 permite a saída de um veículo, a partir do segmento r3, para os

segmentos c3 ou c2. No arquivo de definição da malha tais segmentos são ligados

diretamente ao segmento r3, sem utilizar o elemento b1. Isto acontece porque, do ponto de

vista de um veículo percorrendo o segmento c2 ou o segmento c3, não existe bifurcação na

junção com o segmento r3. A bifurcação b3 fornece ao segmento r5 as saídas r3 e r6. A

bifurcação b4 fornece ao segmento r6 as saídas r3 e r5. Finalmente, a bifurcação b2 fornece

ao segmento r3 as saídas r5 e r6. Seria possível simplificar a representação das ligações

entre os segmentos r3, r5 e r6 definindo um elemento de bifurcação todos-para-todos. Esse

tipo de elemento não foi criado, sendo necessário para isso preparar as estruturas de dados

e algoritmos dentro das rotinas

ReadAGVPath ()

CGAnimatorModule::GetWalkInfo ()

c3

c2

r4

r6

r5

r1

r3

b1

b3

c5

c7

c1

c4

s1 r2

b4

b2

130 Capítulo VI

6.7.2 Infomações fornecidas a veículos de transporte

Durante a execução do modelo comportamental, um veículo invoca a função

RetornaCaminhoAGV () para solicitar ao simulador informações para se movimentar (seção

5.4.1). Essa função é processada da seguinte maneira:

1- inicialmente, obtem-se as coordenadas x e y e ângulo (alpha) do veículo no chão-

de-fábrica, por meio de uma consulta ao respectivo objeto CEAnimator ;

2- determina-se o próximo segmento a ser percorrido, com base nas seguintes

informações:

• segmento em que está o veículo, contido na estrutura de dados struct

s_walk_info;

• movimentação à frente ou em marcha a ré, determinada por variável do modelo

comportamental;

• x, y e alpha, já obtidos; e

• freqüência de operação do veículo.

O parâmetro freqüência de operação é utilizado em bifurcações, para decidir qual

segmento de saída será utilizado.

3- localizado o próximo segmento a ser percorrido pelo equipamento, é preciso

atualizar os dados da estrutura struct s_walk_info . Feito isso encerra-se a execução da

rotina, retornando ao modelo comportamental do veículo que fez a chamada.

6.7.3 Colisões entre veículos

Os veículos de transporte podem sofrer colisões entre si ou com objetos no chão-de-

fábrica. Esse tipo de ocorrência pode ser devido a imperfeições no controle do FMS, ou mais

provavelmente face a situações imprevistas como uma falha de energia em um veículo que

em função disso se torna um obstáculo.

O método mais simples para tratar a colisão consiste em instalar interruptores nos

veículos. Quando ocorre um contato físico o equipamento interrompe sua movimentação,

geralmente reiniciando-a automaticamente instantes depois do contato ser desfeito.

Para implementar a detecção de colisão em objetos móveis a técnica comumente

utilizada em animação gráfica é o uso de bouding-boxes, que neste caso específico poderia

ser implementada em duas dimensões. Em linhas gerais a solução consiste em:

1) projetar a figura tridimensional do veículo no plano do chão-de-fábrica e obter um

retângulo que a circunscreve;


2) à cada atualização de posição de um veículo, processada na rotina

CGAnimatorModule::MoveEquip () , recalcula-se a posição do respectivo retângulo e

verifica-se se houve colisão com outro retângulo de outro equipamento;

3) se uma colisão foi detectada, um evento de aviso é gerado ao veículo que se

moveu.

O tratamento de colisões entre veículos não está implementado no simulador mas não

oferece grandes dificuldades. O retângulo para verificação de colisão pode ser facilmente

obtido, bastando:

1) preencher os valores das variáveis minx , miny , minz , maxx, maxy, maxz, presentes

na estrutura de cabeçalho da árvore cinemática (struct s_kheader ) durante a leitura de

um arquivo “.KKT”;

2) derivar as coordenadas do retângulo que circunscreve o equipamento.

Por fim, é preciso implementar:

1) uma lista de retângulos no módulo CGAnimatorModule ;

2) a detecção de colisões na rotina CGAnimatorModule::MoveEquip () ;

3) a geração de eventos de colisão e o respectivo tratamento no modelo

comportamental de um equipamento.

6.8 Tratamento de Topologia de Esteiras

Na seção 5.4.2 descreveu-se a implementação do modelo comportamental de esteiras

e sua dependência em relação ao formato físico de tais equipamentos. Durante o projeto do

modelo comportamental de esteiras procurou-se obter uma solução genérica que, ao mesmo

tempo, simplificasse a tarefa do programador de um novo equipamento e permitisse

representar o maior número de variantes de esteiras possível.

A solução projetada consiste em definir a topologia da esteira num arquivo ASCII

bastante semelhante ao arquivo de definição de malha de transporte. Tal arquivo consiste de

uma lista de segmentos e seus respectivos parâmetros tais como comprimento, no caso de

segmento de retas e diâmetro, no caso de arcos de circunferência. Tal arquivo será lido por

um módulo especializado, alimentando estruturas de dados utilizadas com dois propósitos:

- apresentar uma imagem tridimensional da esteira e

- informar o modelo comportamental sobre a topologia do equipamento, para que

este realize o agendamento de eventos e cálculo de atualização de posição de objetos

descrito na seção 5.4.2.

A Figura 6.7 a seguir ilustra essa implementação.

132 Capítulo VI

Figura 6.7 - Implementação de esteiras de topologia variável a partir

de um arquivo de definição.

Conforme se observa na Figura 6.7, no caso de esteiras não será utilizado um objeto

do tipo CEAnimator para realizar a animação gráfica. Isso acontece porque a estrutura de

dados utilizada neste caso é diferente da árvore cinemática apresentada na seção 6.3.3. A

estrutura neste caso será mais simples, estando mais adequada para tratamento pelo

modelo comportamental.

A mesma técnica foi utilizada para apresentar o percurso de uma malha de

transporte, ficando a cargo de uma rotina do simulador a tarefa de traduzir a estrutura de

dados de definição da topologia da malha para comandos OpenGL. No caso das malhas de

transporte, essa rotina é GL_lize_AGV_path () , definida no módulo “AGV_path.CPP”.

6.9 Conclusão

As funções de animação gráfica e simulação de ambiente físico foram distribuídas em

alguns componentes descritos neste capítulo:

• - CEAnimator: é o objeto que executa os comandos da biblioteca OpenGL que

apresentam um equipamento no monitor;

• - CKinematicsTree: é o objeto que efetua a gravação e leitura dos arquivos de

extensão “.KKT” que contêm os modelos geométrico-cinemáticos dos

equipamentos;

• - CPIPoint: propaga a mudança de posição geométrica de um ponto de interação

à uma peça ou palete. Realiza também parte do processamento de uma interação

física.

topologia de esteira

leitor de arquivo

CGAnimatorModule

CEquipamento

janela de animação gráfica


Outras funções do módulo de animação gráfica e ambiente físico são: fornecer a um

veículo informações sobre a malha de transporte em que ele trafega e apresentar as malhas

de transporte no monitor.

A implementação do animador gráfico do simulador como um módulo adicional, ao

invés de se utilizar um programa CAD, trouxe como vantagens:

i) simplificação da conexão entre o núcleo do simulador e o animador gráfico, o que

inclui as trocas de dados e também o controle do simulador sobre a execução da animação;

ii) permitiu acrescentar às funções de animação recursos para tratamento das

interações físicas entre equipamentos, como o cálculo de cinemática direta.

134 Capítulo VII

7

Conclusão

A primeira parte deste trabalho apresentou uma revisão bibliográfica em torno do

objetivo da pesquisa. O capítulo 1 tratou dos sistemas flexíveis de manufatura,

apresentando o ciclo de vida de FMS e a problemática de projeto e análise. O capítulo 2

discutiu as técnicas de simulação computacional e animação gráfica aplicáveis ao domínio de

FMS. No capítulo 3, a questão de implementação de um simulador foi discutida tendo como

referência o projeto ANALYTICE. Ao longo da primeira parte e em especial no primeiro

capítulo, colocou-se a demanda por ferramentas computacionais de auxílio a engenharia de

FMS, a ausência de pacotes completos no mercado e a baixa interoperabilidade entre os

softwares existentes nessa área.

Na segunda parte do trabalho, apresentou-se o desenvolvimento do projeto

propriamente dito. O capítulo quatro tratou dos requisitos do simulador a ser implementado.

Foram listados os requisitos funcionais e de arquitetura, levando em conta uma série de

características inerentes a FMS. O capítulo cinco apresentou a modelagem dos equipamentos

de manufatura. As características gerais, comuns a todos equipamentos, bem como

especificidades de veículos de transporte de materiais, foram discutidas. Finalmente, o

capítulo seis apresentou o módulo de animação gráfica e ambiente físico da simulação.

O projeto do software enfocou a simulação do comportamento de uma planta de

manufatura para obtenção de parâmetros quantitativos de funcionamento, utilizando

equipamentos como primitivas de modelagem. Um equipamento é definido pela agregação

de:

• um modelo comportamental, codificado em C++;

• um modelo geométrico, definido em um programa CAD; e

• um modelo cinemático, definido em um aplicativo especialmente implementado.

Equipamentos são derivados à partir de uma super-classe denominada CEquipamento ,

a qual provê uma API de diálogo com o simulador. O interesse em tornar o código de um

equipamento simples e ao mesmo tempo aproximar a simulação da realidade, levou a

implementação de um módulo para tratamento de interações físicas externo aos

equipamentos. Tal módulo é responsável por:

Conclusão 135

• oferecer aos equipamentos simulados todo tratamento envolvido com captura e

liberação de objetos (paletes e peças);

• simplificar a interação entre um veículo de transporte e o trilho que restringe e

define seu percurso na planta;

• oferecer serviços específicos para simulação de esteiras de transporte.

A apreensão ou liberação de uma peça por um robô se resume, no modelo

comportamental do equipamento, a chamadas de API de simulação dentro dos processos de

fechamento e abertura de garra. Isso foi implementado para eximir o código de um

equipamento de explicitar as interações físicas com outros equipamentos dispostos ao seu

redor. Para obter essa funcionalidade foi preciso implementar o cálculo automático de

cinemática direta, tornando a atualização do modelo geométrico dos equipamentos um

componente integrante da execução da simulação.

O módulo de ambiente físico e animação gráfica também é responsável por facilitar a

modelagem da interação que existe entre um veículo e a malha sobre a qual ele trafega. A

solução implementada traz como benefícios:

• flexibilidade: a malha pode ser modificada independemente do código dos

equipamentos e mesmo do controle, quando apenas a topologia for alterada (se

não são inseridos ou excluídos sensores);

• abstração e clareza de modelagem: a interação entre veículo e malha acontece

sem intervenção do controle além daquela existente na interface do

equipamento, por exemplo: comandos mover-se e parar.

A flexibilidade de definição de malha de transporte estendeu-se às esteiras, uma vez

que tais equipamentos têm uma topologia variável em função do arranjo físico. Dessa forma,

o módulo de ambiente físico e animação gráfica assumiu a função de carregar os dados de

configuração de esteira, apresentá-la na tela e disponibilizar ao respectivo modelo

comportamental os dados para sua execução.

O projeto da arquitetura do software revelou-se uma tarefa não-trivial. Diversas

características de organização e operação de sistemas flexíveis de manufatura tiveram de

ser levadas em conta, influindo sobre requisitos importantes do programa. São exemplos:

- modelar processos de equipamentos, enfatizando precisão de consumo de tempo,

facilidade de codificação pelo usuário e relacionamento do modelo comportamental com a

função de animação gráfica;

- incluir nos equipamentos simulados uma aproximação para programação NC,

suficientemente abrangente e de uso simples;

- separar o controle do FMS da parte operativa do sistema, garantindo independência

dos equipamentos (nos aspectos de funcionameno e interface) em relação ao controle;

136 Capítulo VII

- tornar transparentes a interação entre veículo e malha de transporte e os

mecanismos para interações de troca de objetos;

- implementar animação gráfica a partir de modelos geométricos gerados em um

software de CAD.

7.1 Trabalhos futuros

O simulador atualmente implementado é plenamente funcional; para simular um FMS

deve-se fornecer uma definição de planta, os modelos de equipamentos e codificar o

controle. Uma restrição atual é que tal controle deve ser reativo, implementado por exemplo

por meio de uma Rede de Petri. Para preencher alguns requisitos de usabilidade identificam-

se aqui algumas oportunidades de melhoria; são listados também alguns pontos

relacionados com eficiência da implementação. Finalmente, destacam-se algumas

oportunidades de pesquisa como continuação deste trabalho.

1) distribuição da simulação: conforme discutido a respeito do controle do FMS,

percebeu-se a necessidade de executar tal controle em um computador dedicado. Para isso é

preciso implementar mecanismos de comunicação com o simulador e de sincronia de tempo.

Os estudos a respeito da implementação do controle do FMS dessa forma e estudos sobre o

diagnóstico de falhas de FMS estão sendo realizados atualmente por pesquisadores do

projeto.

2) gargalos de processamento: identificam-se algumas oportunidades de

aperfeiçoamento que podem diminuir o “peso” da execução do simulador. Não se

estabeleceu uma aproximação para a carga de CPU envolvida em cada um dos casos abaixo,

mesmo porque não houveram experimentos com um modelo completo de FMS. As sugestões

são:

• a pesquisa por um ponto de interação vizinho é linear e portanto, ineficiente.

Sugere-se utilizar uma estrutura quadtree, mapeando-se os pontos de interação

para duas dimensões (ignorando a coordenada Z);

• implementar a lista de eventos em árvore balanceada; esta sugestão foi

encontrada mais tarde na literatura. Em testes, verificou-se que o uso intenso

das funções malloc () e free () consome tempo razoável de processamento no

sistema operacional Windows 98;

• substituir as chamadas intensivas a glVertex3d (), ao preencher display lists pela

utilização de glArrayElement (). Tanto implementações de OpenGL em software

Conclusão 137

como em hardware devem se beneficiar dessa alteração17. O código de

load_ktree, na classe CEAnimator, deverá ser modificado.

3) parametrização do FMS: a análise de FMS por simulação tem um inconveniente:

a obtenção de valores limite para métricas como índice de ociosidade de equipamentos

depende da configuração de um grande número de parâmetros de operação, exemplificados

por tamanho de lotes a fabricar e planos de processo a serem utilizados. Seria interessante

investigar técnicas de auxílio a determinação dos parâmetros operacionais. Uma

possibilidade seria implementar um ciclo de realimentação (feed-back), alterando

automaticamente os parâmetros operacionais em função de heurísticas a serem investigadas

e valores obtidos da monitoração do FMS.

4) monitoração: o módulo de monitoração implementado satisfaz o requisito de

apresentar o conteúdo das variáveis de um equipamento ao usuário da simulação. O módulo

pode ser aperfeiçoado pela definição de uma interface que leve em conta:

• a facilidade para configurar a obtenção de dados de todo o FMS, que envolve

escolha de equipamentos e suas variáveis;

• facilidade e adequabilidade de configuração de saída dos dados em gráficos,

relatórios ou arquivos;

• disparo de alarmes de monitoração, segundo regras determinadas por usuários

(avaliação de expressões em tempo de execução);

• adequabilidade para solução do problema de parametrização mencionado no ítem

(3) anterior.

17 Este resultado é completamente dependente da implementação de OpenGL sendo utilizada. Entretanto,

é altamente provável um ganho de performance.

138

Anexos

140

Anexo I

Definição de uma malha de transporte

Uma malha de transporte é armazenada em um arquivo específico, tendo sido

utilizada a extensão “.AGV” para designá-lo. Para definir uma malha a mesma deve ser

dividida em elementos dos seguintes tipos: segmento de reta, segmento de arco, bifurcações

e sensores. Cada um desses elementos é configurado por diferentes parâmetros,

sumarizados na tabela a seguir.

Tabela A1.1 - Parâmetros dos elementos que compõe um arquivo de

definição de malha de transporte.

nome do elemento

parâmetros exemplo

sensor - números dos dois elementos aos quais está ligado - nome do sensor - coordenadas x e y do sensor

SENSOR 0 2 -2000 0000 SensorX

segmento de reta - números dos dois elementos aos quais está ligado - coordenadas x e y das duas extremidades do segmento

LINE 1 3 -2000 0000 -1000 0000

arco de circunferência

- números dos dois elementos aos quais está ligado - coordenadas x e y do centro da circunferência - raio da circunferência - ângulo inicial, medido em relação ao eixo X do plano do chão-de- fábrica - ângulo final

CURVE 4 6 1000 1000 1000 90 0

bifurcação - coordenadas x e y da bifurcação - número do elemento de entrada - sequência de números de elementos de saída (até cinco)

FORK 1000 500 3 5 1

A sintaxe de definição de uma malha de transporte é bastante simples. Um exemplo é

apresentado com base na malha apresentada na Figura A1.1 a seguir. Todas as dimensões

estão em milímetros e devem ser medidas em relação a um ponto do chão-de-fábrica que

será utilizado como centro de coordenadas para toda a simulação.

141

Figura A1.1 - Diagrama esquemático de uma malha de transporte.

Conforme se observa na Figura A1.1, a malha neste caso é formada por elementos

numerados, que são:

• um sensor (1) na posição (0mm, -2000 mm);

• dois segmentos de reta (0, 2) ligados ao sensor;

• um segmento de reta (14) sobre o eixo y = -2000 mm;

• dois segmentos de reta verticais (6, 12);

• dez arcos de circunferência (3, 4, 5, 7, 8, 9, 11, 13, 15, 16). Cada arco, para

efeito de definição de uma malha, não pode ser maior do que 90 graus.

Na primeira linha do arquivo deve ser fornecido um identificador para a malha. Na

segunda linha deve ser indicado o número de segmentos que estão listados no arquivo; essa

informação é utilizada para alocar dinamicamente uma estrutura de dados. Em seguida, na

mesma linha, é fornecido um número que representa o número de caminhos virtuais que

podem ser definidos sobre a malha de transporte, conforme comentado na seção 4.1.2. Por

fim pode aparecer uma sequência de três inteiros na faixa [0..255] (três bytes) que indicam

os componentes R,G,B (red, green e blue) da cor a ser utilizada para mostrar o percurso da

malha no chão-de-fábrica.

Na sequência aparece a definição dos elementos que compõe a malha, sendo um por

linha. Linhas em branco em qualquer posição do arquivo são desprezadas. Comentários são

permitidos, utilizando-se a mesma sintaxe de C++, ou seja: o comentário inicia por duas

barras, // , e segue até o final da linha.

A listagem a seguir apresenta o arquivo de definição da malha apresentada na

Figura A1.1.

0 1 2 3

4 5

6

7 8

9

10 11

12

13 14 15

16

142

Minhocódromo 17 4 255 255 255 LINE 16 1 -3000.0 0000.0 -2000.0 0000.0 SENSOR 0 2 -2000.0 0000.0 SENSOR LINE 1 3 -2000.0 0000.0 -1000.0 0000.0 CURVE 2 4 -1000.0 1000.0 1000.0 270.0 360 .0 CURVE 3 5 1000.0 1000.0 1000.0 180.0 90 .0 CURVE 4 6 1000.0 1000.0 1000.0 90.0 0 .0 LINE 5 7 2000.0 1000.0 2000.0 0000.0 CURVE 6 8 1000.0 0000.0 1000.0 360.0 270 .0 CURVE 7 9 1000.0 0000.0 1000.0 270.0 180 .0 CURVE 8 10 1000.0 0000.0 1000.0 180.0 90 .0 LINE 9 11 1000.0 1000.0 3000.0 1000.0 CURVE 10 12 3000.0 0000.0 1000.0 90.0 0 .0 LINE 11 13 4000.0 0000.0 4000.0 -1000.0 CURVE 12 14 3000.0 -1000.0 1000.0 360.0 270 .0 LINE 13 15 3000.0 -2000.0 -3000.0 -2000.0 CURVE 14 16 -3000.0 -1000.0 1000.0 270.0 180 .0 CURVE 15 0 -3000.0 -1000.0 1000.0 180.0 90 .0

O primeiro arco de circunferência e que liga os pontos (-1000mm, 0mm) e

(0mm, 1000mm) é definido como estando limitado pelos ângulos de 270o e 360o. Todo

ângulo é definido em relação ao eixo x do plano cartesiano da figura. O limite de 90o para o

tamanho de um arco e os números utilizados neste caso - 270 e 360 - servem para evitar a

ambigüidade que aconteceria utilizando os ângulos 0o e 270o para definir o arco. Neste

segundo caso seria impossível determinar se o arco de circunferência deveria ter 270o ou

apenas 90o.

Os demais segmentos de arco são definidos segundo a mesma lógica. A malha

definida neste exemplo pode ser vista parcialmente na Figura 5.3.

144

Anexo II

Definição do modelo comportamental de um AGV

Neste anexo apresentaremos o código do modelo comportamental de um veículo de

transporte, ilustrando diretamente como é realizada a modelagem do mesmo.

O fonte em C++ e o arquivo header (de cabeçalho) serão apresentados na íntegra,

sendo inseridos comentários ao longo do mesmo explicando a implementação. Os arquivos

auxiliares exigidos para compilação da DLL (como DLL.DEF) não estão incluídos.

Arquivo: “demo_agv.h”

//************************************************* ********* // Implementação do equipamento Veículo auto guiado demonstração // Características : [CARACTERISTICAS] //************************************************* ********* #ifndef _demo_AGV_H_ #define _demo_AGV_H_ #include "Equipamento.h" //Comandos, respostas, processos e pontos de acesso #define COMANDOS 5 #define PROCESSOS 2 #define RESPOSTAS 1 #define PONTOS_ACESSO 0 //Sinais de comando #define MOVER 0 #define PARAR 1 #define CNC 2 #define INVERTER 3 #define PALETIAR 4 //Sinais de resposta #define F_CNC 0 //Processos #define MOVENDO 0 #define MANUTENCAO 1 //Eventos internos #define E_MTBF 0 #define E_FIM_MANUTENCAO 1 #define E_FIM_MOVENDO 2

As constantes definidas até aqui são utilizadas para identificar eventos e comandos

tratados pelo modelo comportamental. Os mesmos códigos deverão ser utilizados pelo

controle simulado do FMS para dialogar com o equipamento.

145

//Pontos de acesso //Definição da classe class CDemo_agv : public CEquipamento { //Parametros operacionais double mtbf; double mttr; double reference_frame[3]; double lim_velocidade[2]; //variaveis de procedimento double velocidade; //variaveis de estado struct s_walk_info posicao; double pos_x; double pos_y; double pos_z; double orientacao; int reverse; double x0, y0, x1, y1, angle0, angle1, x, y, angle_orient, angle, comprimento, comprim ento_andado, tempo_total, sinal; void mover ( CParametros *p ); void parar ( CParametros *p ); void cnc ( CParametros *p ); void inverter ( CParametros *p ); void paletizar ( CParametros *p ); void processo_movendo( unsigned nFlag ); void processo_manutencao( unsigned nFlag ); void proximo_segmento();

Até este ponto estão definidos componentes internos do modelo comportamental, na

seção private do objeto C++. Foram definidas variáveis para manter o posicionamento do

equipamento e para dialogar com o ambiente físico, para obter dados sobre a malha de

transporte - struct s_walk_info posicao .

Variáveis internas utilizadas para cálculo de movimentação e as declarações das

rotinas internas aparecem neste trecho.

public: CDemo_agv( CFMS *sim, CConsole *console ); ~CDemo_agv(); //FUNÇÕES PARA O ANIMADOR GRÁFICO virtual void *MapeiaPrimitivaToVariavel ( const char* primitiva ); virtual const char *ArquivoGeometria( void ); //FUNÇÃO DE INVOCAÇÃO virtual void mc ( CEvento *ev ); //FUNÇÃO DE CONFIGURAÇÃO DO ESTADO INICIAL DO EQ UIPAMENTO void estado_inicial(); }; #define INTERPRETADOR 1 #endif

146

A interface pública do equipamento aparece no trecho anterior. A rotina

ArquivoGeometria () retorna o caminho e nome do arquivo que contém os modelos

geométrico e cinemático do AGV.

Arquivo: “demo_agv.cpp”

//******************************************* // Implementação do equipamento Veículo auto guiado demonstração #include <math.h> #include "demo_AGV.h" #include "ListaEventos.h" //****************** Construtor ***************** CDemo_agv::CDemo_agv( CFMS *sim, CConsole *console ) : CEquipamento ( sim, console ) { //Inicialização dos comandos _numero_de_comandos = COMANDOS; comandos = (_Comandos *) malloc ( _numero_de_com andos * sizeof(_Comandos) ); strcpy(comandos[0].nome, "mover"); comandos[0]._numero_de_parametros = 1; comandos[0].parametros = (_Parametros *) malloc( 1 * sizeof(_Parametros) ); strcpy(comandos[0].parametros[0].nome, "velocida de"); comandos[0].parametros[0].tipo = DOUBLE; comandos[0].pProc = (void (CEquipamento::*)(clas s CParametros *)) mover; strcpy(comandos[1].nome, "parar"); comandos[1]._numero_de_parametros = 0; comandos[1].parametros = NULL; comandos[1].pProc = (void (CEquipamento::*)(clas s CParametros *)) parar; strcpy(comandos[2].nome, "cnc"); comandos[2]._numero_de_parametros = 1; comandos[2].parametros = (_Parametros *) malloc( 1 * sizeof(_Parametros) ); strcpy(comandos[2].parametros[0].nome, "Programa "); comandos[2].parametros[0].tipo = STRING; comandos[2].pProc = (void (CEquipamento::*)(clas s CParametros *)) cnc; strcpy(comandos[3].nome, "inverter"); comandos[3]._numero_de_parametros = 1; comandos[3].parametros = (_Parametros *) malloc( 1 * sizeof(_Parametros) ); strcpy(comandos[3].parametros[0].nome, "Inverter ? 1/0"); comandos[3].parametros[0].tipo = INTEGER; comandos[3].pProc = (void (CEquipamento::*)(clas s CParametros *)) inverter; strcpy(comandos[4].nome, "Pallet"); comandos[4]._numero_de_parametros = 0; comandos[4].parametros = NULL; comandos[4].pProc = (void (CEquipamento::*)(clas s CParametros *)) paletiar;

Nesta seção inicial do construtor do equipamento são preenchidos arrays internos

contendo os nomes dos comandos a que o AGV responde e os parâmetros utilizados em cada

um deles. Estes arrays são consultados para apresentar a interface do equipamento com o

usuário da simulação.

//Inicialização dos processos _numero_de_processos = PROCESSOS; processo = (_Processos *) malloc( _numero_de_pro cessos * sizeof(_Processos) ); strcpy(processo[0].nome, "movendo"); strcpy(processo[1].nome, "manutencao");

147

No trecho anterior são inicializadas estruturas de dados que publicam o nome dos

processos realizados pelo equipamento. Servem também para apresentação da interface do

equipamento com o usuário da simulação.

//Inicialização das respostas _numero_de_respostas = RESPOSTAS; resposta = (_Respostas *) malloc( _numero_de_res postas * sizeof(_Respostas) ); strcpy( resposta[0].nome, "f_cnc"); //Inicialização dos pontos de acesso _numero_de_pontos_de_acesso = 1; ponto_de_acesso = (_Pontos_de_Acesso *) malloc(_ numero_de_pontos_de_acesso * sizeof(_Pontos_de_Acesso)); strcpy( ponto_de_acesso[0].nome, "PA01" ); ponto_de_acesso[0].ponto = new CPIPoint(); //Inicializacao do interpretador pInterpretador = new CInterpretador( this ); //Define o frame de referencia (base) do equipam ento reference_frame[0] = 0.0; reference_frame[1] = 0.0; reference_frame[2] = 0.0; }

Por fim é inicializado o array com informações sobre as respostas e variáveis do

modelo. É criado o único ponto de interação (ou ponto de acesso, como foi chamado

algumas vezes durante o desenvolvimento do projeto). Um objeto interpretador NC é

também criado e inicializado.

//********************** Destrutor ************** CDemo_agv::~CDemo_agv() { ; } //***************** Retorna as informacoes de geome tria ********************* const char *CDemo_agv::ArquivoGeometria( void ) { return "demo_AGV.KKT"; }

No trecho acima aparecem funções utilizadas na destruição do objeto em memória e

carga do equipamento.

148

//************* FUNÇÃO QUE CONFIGURA O ESTADO INICI AL void CDemo_agv::estado_inicial() { CEquipamento::estado_inicial(); mtbf = 0.0; mttr = 0.0; lim_velocidade[0] = 100.0; lim_velocidade[1] = 5000.0; velocidade = 0; //Para o simulador posicionar o equipamento memset( &posicao, '0', sizeof(struct s_walk_info ) ); //Yckes! 0x0000 devia ser NULL, porém não parece bem o caso com a microsoft... posicao.path = NULL; if ( !RetornaCaminhoAGV (&posicao, reverse = FAL SE, 0) ) { EscreveNoConsole("Yckes!!! O Agv não foi posi cionado em nenhum lugar do trilho!" ); EscreveNoConsole("Não inicie a simulação sobr e risco do programa ficar completamente perdido..."); } //Pega a posição atual do equipamento pos_x = 0.0; pos_y = 0.0; pos_z = 0.0; orientacao = posicao.angle0; if ( mtbf != 0.00 ) AdicionaEvento ( E_MTBF, mtbf ); }

O posicionamento do AGV será obtido mais tarde. No trecho de código acima, na

rotina estado_inicial () é realizada uma inicialização arbitrária de variáveis.

A próxima rotina é invocada pelo núcleo do simulador, sendo “enxergada” por este

como sendo o modelo comportamental do equipamento. Na verdade, a execução do

equipamento, seus comandos e processos estão distribuídos em diversas rotinas deste

módulo C++.

//************ FUNÇÃO DE INVOCAÇÃO void CDemo_agv::mc ( CEvento *ev ) { _delta_hora = ev->hora - _hora; _hora = ev->hora; //Atualização geométrica para todos os processo ativos BOOL bInativo = TRUE; for (unsigned i = 0; i < _numero_de_processos; i ++) { if (processo[i].ativo) { switch (i) { case MOVENDO : bInativo = FALSE; processo_movendo( ATUALIZACAO_GEOMETRICA ); break; case MANUTENCAO : bInativo = FALSE; processo_manutencao( ATUALIZACAO_GEOMETR ICA ); break; } } } //Acumula o tempo inativo if (bInativo) _total_tempo_inativo += _delta_hora;

149

O código até aqui realiza um tratamento geral que consiste em atualizar variáveis

internas e disparar as rotinas de atualização geométrica para os processos ativos.

O comando switch a seguir realiza o despacho de eventos dentro do modelo

comportamental.

//Switch Principal switch (ev->tipo) { case TIME_SLICE : break; case INTERFACE : switch (ev->evento) { case MOVER : mover (ev->parametros ); break; case PARAR : parar (ev->parametros ); break; case CNC : cnc (ev->parametros ); break; case INVERTER: inverter (ev->parametros ); break; case PALETIAR: paletiar (ev->parametros ); break; } break; case EQUIPAMENTO : switch (ev->evento) { case E_MTBF: processo_manutencao( INICI O ); break; case E_FIM_MOVENDO: processo_movendo( F IM ); break; case E_FIM_MANUTENCAO: processo_manuten cao( FIM ); break; } break; case INTERACAO : switch (ev->evento) { case ADICIONAR_PECA : break; case REMOVER_PECA : break; case FALHA : break; } break; } //Libera os parâmetros da memória if (ev->parametros != NULL) delete ev->parametros; #if INTERPRETADOR //Verifica se o interpretador nao esta ativo e resume sua operacao if ( pInterpretador->Executando() ) { if (pInterpretador->Interpreta() != ERR_OK ) EscreveNoConsole("O interpretador saiu com erro."); if ( !pInterpretador->Executando() ) AdicionaResposta( F_CNC ); } #endif }

A próxima rotina retorna dados para monitoração e para realização das interações

físicas (retorna o endereço da variável contendo o ponto de interação do AGV). //************ Mapeia primitiva geométrica para var iável ***************** void *CDemo_agv::MapeiaPrimitivaToVariavel (const c har* primitiva) { if (strcmp(primitiva, "BASE") == 0) return &reference_frame[0]; if (strcmp(primitiva,"VELOCIDADE") == 0) return &velocidade; if (strcmp (primitiva, "PA01") == 0) { EscreveNoConsole ("Procurado Pa01"); return ponto_de_acesso[0].ponto; } return NULL;

150

} //*************************** comando mover void CDemo_agv::mover( CParametros *p ) { unsigned tipo; if ( (processo[MANUTENCAO].ativo) || (processo[M OVENDO].ativo) ) return; //TODO: Verifique se os parâmetros estão sendo r emovidos corretamente double *param0 = (double *) p->Parametro( 0, &ti po ); if ( tipo != DOUBLE ) return; if ((*param0 < lim_velocidade[0]) || (*param0 > lim_velocidade[1])) { EscreveNoConsole("Parâmetro excede os parâmet ros do equipamento <%f> [%f,%f]", *param0, lim_velocidade[0], lim_velocidade[1] ); return; } velocidade = *param0; proximo_segmento (); }

A rotina mover () “responde” a um comando externo examinando os parâmetros,

verificando se o estado do equipamento permite a execução do comando e disparando a

execução do processo respectivo.

No caso específico deste equipamento o disparo do processo acontecerá após a

chamada à rotina proximo_segmento () .

As rotinas a seguir dispensam maiores comentários.

//*************************** comando parar void CDemo_agv::parar( CParametros *p ) { if (processo[MANUTENCAO].ativo) return; processo_movendo( FIM ); } //*************************** comando cnc void CDemo_agv::cnc( CParametros *p ) { unsigned tipo; if (processo[MANUTENCAO].ativo) return; char *programa = (char *) p->Parametro (0, &tipo ); if ( tipo != STRING ) { EscreveNoConsole("cnc - Nome do programa é inv álido"); return; } if ( pInterpretador->Carrega(programa) ) { EscreveNoConsole( "Programa carregado na memor ia do interpretador" ); if (pInterpretador->Interpreta() != ERR_OK) EscreveNoConsole("O interpretador saiu com erro."); if ( !pInterpretador->Executando() ) AdicionaResposta( F_CNC ); } else EscreveNoConsole( pInterpretador->MensagemStat us() ); }

A próxima rotina trata o comando “inverter” do AGV. O parâmetro lógico que é

fornecido indica se o AGV deve se deslocar em sentido normal ou em “marcha-a-ré”.

151

//*************************** comando inverter void CDemo_agv::inverter (CParametros *p) { unsigned tipo; if ( (processo[MANUTENCAO].ativo) || (processo[M OVENDO].ativo) ) return; //TODO: Verifique se os parâmetros estão sendo r emovidos corretamente int *param0 = (int *) p->Parametro( 0, &tipo ); if (tipo != INTEGER) return; if ((*param0 < 0) || (*param0 > 1)) { EscreveNoConsole ("É zero ou um, meu!"); return; } reverse = *param0; }

A rotina a seguir foi construída para testar o AGV recebendo diretamente uma peça,

ou recebendo um Pallet sobre o qual podem haver até três peças.

//*************************** comando inverter void CDemo_agv::paletizar (CParametros *p) { CPallet *pallet; CPart *part; #define VAIPALLET 1 #ifdef VAIPALLET pallet = new CPallet (250., 350., 40.); pallet->AddSlot (0., 150., 30.); pallet->AddSlot (0., 0., 30.); pallet->AddSlot (0.,-150., 30.); //---------------------------------- part = new CPart (120., 120., 120.); part->Color (RED); pallet->ReceivePartAt (0, part); //---------------------------------- part = new CPart (120, 120, 120); part->Color (GREEN); pallet->ReceivePartAt (2, part); //---------------------------------- *(ponto_de_acesso[0].ponto) = pallet; #else part = new CPart (160., 160., 160.); part->Color (GREEN); *(ponto_de_acesso[0].ponto) = part; #endif }

152

Em seguida é apresentado o processo responsável pelos cálculos de movimentação do

AGV. Esta rotina é invocada pela rotina proximo_segmento () definida mais abaixo. Tal

rotina já terá preenchido a variável posicao com os dados necessários aqui.

//*************************** processo_movendo void CDemo_agv::processo_movendo( unsigned nFlag ) { switch (nFlag) { case INICIO :

Na inicialização o AGV deve calcular o tempo que será despendido para percorrer o

próximo segmento e agendar o evento respectivo. //Característisticas do segmento switch ( posicao.type ) { case e_agv_SENSOR: EscreveNoConsole ("[SENSOR]"); break;

No caso de um sensor, não há nada a fazer. case e_agv_LINE: x = x0 = posicao.x0; y = y0 = posicao.y0; x1 = posicao.x1; y1 = posicao.y1; comprimento = posicao.length; tempo_total = comprimento / velocidade; // Tanto faz angle0 ou angle1, já que o ân gulo de entrada e de seída /// em um segmento, conforme retornado po r GAnimatorModule, é igual. angle_orient = posicao.angle1; if (reverse) { angle_orient = angle_orient + 180; if (angle_orient >= 360) angle_orient = angle_orient - 360; } AdicionaEvento (E_FIM_MOVENDO, _hora + (co mprimento / velocidade)); break;

No caso de um segmento de reta o cálculo de tempo é realizado na linha em negrito.

O simulador fornece o comprimento a ser percorrido.

case e_agv_CURVE: //Calcula o tempo que vai demorar para and ar //AdicionaEvento( E_FIM_MOVENDO, _hora + . .. ); x = x0 = posicao.x0; y = y0 = posicao.y0; x1 = posicao.x1; y1 = posicao.y1; // Ângulos de início e fim para plotar o A GV caminhando. angle = posicao.alpha0; angle0 = posicao.alpha0; angle1 = posicao.alpha1; comprimento = posicao.length; tempo_total = comprimento / velocidade; // angle0 = ângulo inicial de orientaçào d o AGV.

153

angle_orient = posicao.angle0; if (reverse) { angle_orient = angle_orient + 180; if (angle_orient >= 360) angle_orient = angle_orient - 360; } AdicionaEvento (E_FIM_MOVENDO, _hora + (co mprimento / velocidade)); break;

No caso de arcos de circunferência o cálculo a ser realizado é o mesmo utilziado para

segmentos de reta. O módulo de ambiente físico novamente fornece ao equipamento o

compriemento a ser percorrido.

default: EscreveNoConsole("Tipo de trilho desconhec ido %d", posicao.type); break; }; processo[MOVENDO].ativo = TRUE; break;

Após um tratamento clássico de possíveis erros de execução, segue a seção do

processo “movendo” responsável pelo tratamento do evento time-slice.

Em cada caso deve ser calculado o espaço percorrido pelo equipamento, desde o início

do movimento até a hora atual. Para isso são utilizadas como informação as variáveis:

- tipo de segmento (reta/arco);

- delta_hora , que fornece o tempo decorrido desde a última ativação do modelo

comportamental;

- tempo_total , que fornece o tempo necessário para completar o movimento; e

- velocidade . case ATUALIZACAO_GEOMETRICA : switch (posicao.type) { case e_agv_LINE: processo[MOVENDO].tempo_ativo += _delta_ho ra; x = x + ((x1 - x0) * (_delta_hora / tempo_ total)); y = y + ((y1 - y0) * (_delta_hora / tempo_ total)); break; case e_agv_CURVE: double aux = ((angle1 - angle0) * (_delta_ hora / tempo_total)); angle = angle + aux; angle_orient = angle_orient + aux; x = posicao.xc + (posicao.radius * cos (3. 1415 * angle / 180)); y = posicao.yc + (posicao.radius * sin (3. 1415 * angle / 180)); break; } DefinePosicao (x, y, 0, angle_orient); break;

154

A seção a seguir corresponde ao final da rotina movendo () e trata o término do

respectivo processo. case FIM : processo[MOVENDO].ativo = FALSE; DefinePosicao (posicao.x1, posicao.y1, posica o.z1, angle_orient); proximo_segmento (); break; } }

O processo de manutenção foi modelado como simplesmente gastando tempo de

simulação. void CDemo_agv::processo_manutencao( unsigned nFlag ) { unsigned i = 0; switch (nFlag) { case INICIO : RemoveTodosEventos(); AdicionaEvento ( E_FIM_MANUTENCAO, _hora + mtt r ); for ( ; i < _numero_de_processos; i ++) processo[i].ativo = FALSE; processo[MANUTENCAO].ativo = TRUE; break; case ATUALIZACAO_GEOMETRICA : processo[MANUTENCAO].tempo_ativo += _delta_hor a; break; case FIM : if ( mtbf != 0.00 ) AdicionaEvento (E_MTBF, _hora + mtbf); processo[MANUTENCAO].ativo = FALSE; break; } }

Finalmente, a rotina proximo_segmento () é responsável por:

- solicitar ao simulador as informações sobre o próximo segmento da malha a ser

percorrido;

- tratar erros básicos nesta fase e

- iniciar o processo “movendo”.

void CDemo_agv::proximo_segmento() { if ( !RetornaCaminhoAGV (&posicao, reverse, 0) ) { // Frequência default = 0. EscreveNoConsole("Yckes!!! O Agv não foi posic ionado em nenhum lugar do trilho!" ); EscreveNoConsole("Não inicie a simulação sob r isco de crash..."); return; } if (posicao.type != e_agv_SENSOR) { processo_movendo (INICIO); } }

156

Anexo III

Definição do modelo geométrico

e cinemático de um AGV

Neste anexo apresentaremos um caso prático de realização do modelo geométrico e

cinemático de um AGV.

Inicialmente o modelo geométrico é criado em um CAD, a partir de medidas obtidas

do equipamento ou a partir de diagramas esquemáticos fornecidos pelo fabricante.

A Figura A3.1 a seguir apresenta o modelo geométrico de um AGV apresentado na janela de

renderização do software 3D Studio.

Figura A3.1 - modelo geométrico de um AGV, com segmentos de reta

de orientação, escala e definição de ponto de interação.

Na Figura A3.1 pode-se observar, além do equipamento AGV, quatro segmentos de

reta em cor branca. Tais segmentos de reta ou linhas são utilizadas no software de definição

de cinemática, conforme comentado na seção 4.3.1. Tais linhas definem as seguintes

informações:

157

• eixo Z: linha que atravessa verticalmente o AGV; e

• eixo X: linha que aparece na parte frontal do AGV.

As linhas correspondendo aos eixos Z e X tem um vértice comum na parte inferior do

AGV. Este ponto de intersecção é utilizado pelo animador gráfico para estabelecer a posição

ou altura em que o plano do chão-de-fábrica passa em relação ao modelo geométrico de um

equipamento.

No modelo aparecem ainda:

• eixo de escala: linha posicionada paralelamente ao AGV;

• ponto de interação: linha colocada na parte superior do AGV; e

• luzes de aviso: os três sólidos que sobressaem na parte posterior do

equipamento.

Todos os sólidos e retas que fazem parte do modelo geométrico recebem

identificadores. O modelo geométrico deve ser exportado no formato “.3DS” e em seguida

carregado no software de definição de cinemática. A Figura A3.2 a seguir apresenta a tela do

programa durante a criação da árvore cinemática do AGV.

Figura A3.2 - Tela do software de definição de cinemática.

158

Obviamente o AGV neste caso, por não possuir partes móveis, é formado por um

único nó cinemático que agrega todos os sólidos que o compõe. Ao eixo de escala

representado pela reta “EixoEscala” foi atribuído um tamanho de 2000 milímetros que deve

corresponder ao comprimento do equipamento real. Os segmentos de reta de nomes “EixoX”

e “EixoZ” são usados para representar os respectivos eixos. O eixo z é posicionado

verticalmente em relação ao plano do chão-de-fábrica pelo objeto de animação. O eixo x é

utilizado para orientar o equipamento em relação ao eixo x do mesmo plano.

O segmento de reta que representa o ponto de interação recebeu o nome, ainda no

programa 3D Studio, de “PA01”. Esse segmento de reta é incluído no nó cinemático e

marcado como ponto de interação.

As luzes de aviso podem apresentar cores diferentes durante a simulação. Para isso

basta alterar a rotina MapeiaPrimitivaToVariavel () , apresentada no Anexo II, incluindo

nela as seguintes linhas:

void *CDemo_agv::MapeiaPrimitivaToVariavel (const c har* primitiva) { ... if (!strcmp (primitiva, “LuzFrente”)) return &LuzFrente[0]; if (!strcmp (primitiva, “LuzTraz”)) return &LuzTraz[0]; ...

as variáveis LuzFrente e LuzTraz devem ser declaradas da seguinte maneira:

unsigned char LuzFrente[3], LuzTraz [3];

A partir daí alterações dos componentes R,G,B das cores (os três bytes) no modelo

comportamental, resultarão em alteração automática de cor dos sólidos que representam as

lâmpadas na animação do equipamento.

No caso de um equipamento que contém partes móveis, basta criar a árvore de nós

cinemáticos e, em cada nó colocar: i) os sólidos que formam a parte móvel do equipamento

e ii) a reta que representa o eixos de transformação. Cada eixo de transformação pode ser

configurado como eixo prismático ou de revolução (Figura 6.4).

Na tela de “parâmetros de animação” (vide parte superior da Figura A3.2) são

fornecidos, para cada eixo de transformação:

- nome da variável geométrica do modelo comportamental;

- limites inferior e superior de movimentação.

Finalmente, a tela de “cores” permite especificar as cores dos sólidos que formam o

equipamento. Esta informação não é exportada nos arquivos “.3DS” pelo software 3D Studio.

159

INTRODUÇÃO ...............................................................................................................1

I PARTE - PROBLEMÁTICA E REVISÃO BIBLIOGRÁFICA................................................................5

1 - CONTEXTO E OBJETIVOS DO TRABALHO

1.1 Introdução ..............................................................................................7

1.2 Tipologia dos sistemas de produção............................................................9

1.3 Sistemas Flexíveis de Manufatura ............................................................11

1.4 Ciclo de vida de FMS ..............................................................................15

1.4.1 Nível 0 - Ciclo de Vida..........................................................................15

1.4.2 Nível 1 - Projeto de FMS.......................................................................16

1.4.2 Nível 2 - Desenvolvimento de soluções ..................................................17

1.5 Problemas ligados ao projeto de FMS........................................................18

1.6 Medidas de desempenho de FMS..............................................................20

1.7 Análise de FMS ......................................................................................22

1.8 Conclusão .............................................................................................24

2 - SIMULAÇÃO E ANIMAÇÃO GRÁFICA DE FMS

2.1 Simulação Computacional .......................................................................28

2.1.1 Introdução .........................................................................................28

2.1.2 Simulação aplicada a FMS ....................................................................29

2.1.3 Simulação a Eventos Discretos..............................................................32

2.1.5 Modelagem de FMS para Simulação.......................................................34

2.2 Animação..............................................................................................36

2.2.1 Introdução .........................................................................................36

2.2.2 Técnicas de animação..........................................................................37

2.2.3 Modelagem geométrica ........................................................................38

2.2.4 Modelagem Cinemática ........................................................................40

2.2.5 CAD e padrões de intercâmbio de dados.................................................43

2.3 Simuladores aplicados em FMS................................................................46

2.4 Conclusão .............................................................................................50

160

3 - ANTECEDENTES: ANALYTICE

3.1 Introdução ............................................................................................52

3.2 Características Gerais.............................................................................52

3.3 Modelagem de Equipamentos ..................................................................53

3.3.1 Dados para modelagem de equipamentos ..............................................53

3.3.2 Equipamentos de manuseio de materiais................................................57

3.3.3 Controle NC........................................................................................58

3.4 Execução do simulador em ANALYTICE .....................................................59

3.4.1 Controle de tempo ..............................................................................60

3.4.2 Atividade de Geração de Eventos ..........................................................60

3.5 Controle do FMS ....................................................................................61

3.6 Modelagem de FMS ................................................................................62

3.7 Conclusão .............................................................................................62

II PARTE - DESENVOLVIMENTO DO TRABALHO

4 - REQUISITOS DA ARQUITETURA

4.1 Ferramenta de projeto e análise de FMS ...................................................66

4.1.1 Visão Geral do FMS simulado................................................................66

4.1.2 Interface do simulador com outros módulos ...........................................68

4.2 Requisitos do simulador..........................................................................71

4.2.1 Características gerais ..........................................................................71

4.2.3 Controle do FMS .................................................................................73

4.2.4 Equipamentos.....................................................................................74

4.2.5 Interface com Usuário..........................................................................78

4.3 Requisitos de Animação Gráfica ...............................................................79

4.3.1 Modelos Geométrico e Cinemático .........................................................79

4.3.2 Geração de eventos para animação gráfica.............................................82

4.4 Arquitetura de Simulação........................................................................84

4.4.1 Modelo da Arquitetura .........................................................................84

4.4.2 Módulos Internos do Simulador.............................................................86

4.5 Conclusão .............................................................................................88

161

5 - IMPLEMENTAÇÃO DA SIMULAÇÃO

5.1 Conceitos..............................................................................................89

5.2 O Modelo Comportamental dos equipamentos............................................91

5.2.1 Eventos pré-definidos ..........................................................................95

5.3 Peças e Paletes......................................................................................98

5.4 Equipamentos de transporte.................................................................. 100

5.4.1 Veículos de transporte ....................................................................... 100

5.4.2 Esteiras ........................................................................................... 103

5.5 Interface de equipamentos com controle................................................. 105

5.6 Conclusão ........................................................................................... 106

6 - IMPLEMENTAÇÃO DO ANIMADOR GRÁFICO E AMBIENTE FÍSICO

6.1 CAD e Animação Gráfica ....................................................................... 109

6.2 Bibliotecas de implementação de animação gráfica................................... 112

6.2.1 Bibliotecas para jogos........................................................................ 112

6.2.2 Direct3D – Microsoft .......................................................................... 113

6.2.3 OpenGL – Silicon Graphics ................................................................. 114

6.3 Modelagem geométrica e cinemática ..................................................... 117

6.3.1 Modelo Geométrico............................................................................ 117

6.3.2 Representação de pontos de interação física ......................................... 119

6.3.3 Modelo Cinemático ............................................................................ 121

6.3.4 Software de auxílio a definição de cinemática ....................................... 122

6.4 Organização do módulo de animação gráfica e ambiente físico............... 124

6.5 Objetos de animação............................................................................ 125

6.5.1 Inicialização ..................................................................................... 125

6.5.2 Operação ......................................................................................... 126

6.6 Tratamento de interações físicas ............................................................ 127

6.6.1 Cálculo de cinemática direta ............................................................... 127

6.6.2 Processamento das interações ............................................................ 128

6.6.3 Posicionamento de peças e paletes ...................................................... 130

6.7 Tratamento de malhas de transporte ..................................................... 131

6.7.1 Representação das malhas ................................................................. 132

6.7.2 Infomações fornecidas a veículos de transporte..................................... 134

6.7.3 Colisões entre veículos....................................................................... 134

6.8 Tratamento de Topologia de Esteiras ...................................................... 135

6.9 Conclusão ........................................................................................... 136

162

7 - CONCLUSÃO

7.1 Trabalhos futuros................................................................................. 140

ANEXOS ................................................................................................................. 142

Anexo I - Definição de uma malha de transporte ........................................... 144

Anexo II - Definição do modelo comportamental de um AGV........................... 148

Anexo III - Definição do modelo geométrico e cinemático de um AGV .............. 160

SUMÁRIO ÍNDICE DE FIGURAS

FIGURA 1.1 – TIPOLOGIA DOS SISTEMAS DE PRODUÇÃO. .......................................................10

FIGURA 1.2 – CICLO DE VIDA DE FMS; NÍVEL 0 EM DIAGRAMA SADT. ......................................15

FIGURA 1.3 – ETAPA DE PROJETO DO CICLO DE VIDA DE FMS..................................................16

FIGURA 1.4 – ETAPA DE DESENVOLVIMENTO DE SOLUÇÕES DO CICLO DE VIDA DE FMS....................18

FIGURA 1.5 – ESTRUTURA DA RDP PARA CONTROLE DE UMA ESTAÇÃO. .......................................35

FIGURA 2.1 - CONSTRUÇÕES MECÂNICAS DE UM ROBÔ ..........................................................41

FIGURA 2.2 – FOTO, MODELO GEOMÉTRICO E ÁRVORE CINEMÁTICA DE UM ROBÔ MOTOMAN SK150.....42

FIGURA 2.3 – JANELA DO SOFTWARE A-SIM......................................................................47

FIGURA 2.4 – JANELA DO SOFTWARE TAYLOR. ....................................................................49

FIGURA 3.1 – EXEMPLO DE INTERFACE EM REDE DE PETRI ENTRE EQUIPAMENTO E USUÁRIO ..............55

FIGURA 3.2 – JANELA DE DEFINIÇÃO DE MODELO GEOMÉTRICO. ...............................................56

FIGURA 3.3 – AMBIENTE DE MODELAGEM CINEMÁTICA...........................................................57

FIGURA 3.4 –SEQÜÊNCIA DE PROJETO DE FMS...................................................................62

FIGURA 4.1 – IMPLEMENTAÇÃO DE DIFERENTES NÍVEIS HIERÁRQUICOS DE UM FMS NO SIMULADOR. ....67

FIGURA 4.2 - DFD EM NÍVEL 0 DO SIMULADOR ..................................................................69

FIGURA 4.3 – COMUNICAÇÃO HORIZONTAL ENTRE EQUIPAMENTOS, REALIZADA PELO CONTROLE DO FMS.77

FIGURA 4.4 – EXEMPLO DE MODELO GEOMÉTRICO -“JIPE LUNAR” .............................................80

FIGURA 4.5 – O PROBLEMA DE SINCRONIA DE TEMPO DE SIMULAÇÃO. ........................................83

FIGURA 4.6 – SOLUÇÃO PARA SINCRONIA DE TEMPO DE SIMULAÇÃO. .........................................83

FIGURA 4.7 – ATRASO NO PROCESSAMENTO DE EVENTOS. ......................................................84

FIGURA 4.8 - REDE DE PETRI DA ARQUITETURA DE SIMULAÇÃO ................................................85

FIGURA 4.9 – DIAGRAMA DE CLASSES DO SIMULADOR. .........................................................87

FIGURA 5.1 – USO DE BOUDING-BOX PARA DETERMINAR SE INTERAÇÃO FÍSICA PODE OCORRER. .........97

163

FIGURA 5.2 – PALETE COM DUAS PEÇAS E BRAÇO ROBOTIZADO. ............................................. 100

FIGURA 5.3 – AGV EM MOVIMENTO SOBRE UMA MALHA DE TRANSPORTE. .................................. 101

FIGURA 6.1 – INTERFACE ENTRE SIMULADOR E PROGRAMA CAD. ............................................ 110

TABELA 6.1 - COMPARAÇÃO ENTRE CÓDIGO OPENGL E DIRECT3D. ......................................... 115

FIGURA 6.2 - ESTRUTURA DE DADOS DE ARMAZENAMENTO DE SÓLIDOS. ................................... 119

FIGURA 6.3A – DEFINIÇÃO DE PONTO DE INTERAÇÃO FÍSICA PARA PEÇA.................................... 120

FIGURA 6.3B – DEFINIÇÃO DE PONTO DE INTERAÇÃO FÍSICA E ORIENTAÇÃO PARA PALETE. .............. 120

FIGURA 6.4 – JANELA DO SOFTWARE DE DEFINIÇÃO DE MODELO CINEMÁTICO............................. 123

FIGURA 6.5 – DIAGRAMA DE CLASSES DO MÓDULO DE ANIMAÇÃO GRÁFICA E AMBIENTE FÍSICO ........ 124

FIGURA 6.6 - DIAGRAMA ESQUEMÁTICO DE UMA MALHA DE TRANSPORTE. .................................. 133

FIGURA 6.7 - IMPLEMENTAÇÃO DE ESTEIRAS DE TOPOLOGIA VARIÁVEL A PARTIR DE UM ARQUIVO DE DEFINIÇÃO. ............................................................................................................. 136

FIGURA A1.1 - DIAGRAMA ESQUEMÁTICO DE UMA MALHA DE TRANSPORTE. ................................ 145

FIGURA A3.1 - MODELO GEOMÉTRICO DE UM AGV ............................................................. 160

FIGURA A3.2 - TELA DO SOFTWARE DE DEFINIÇÃO DE CINEMÁTICA.......................................... 161

ÍNDICE DE TABELAS

TABELA 1 - TIPOS DE FLEXIBILIDADE EM FMS. ....................................................................22

TABELA 5.1: INFORMAÇÕES RETORNADAS PELA ROTINA MAPEIAPRIMITIVA TOVARIAVEL (). ................95

TABELA 6.1 - COMPARAÇÃO ENTRE CÓDIGO OPENGL E DIRECT3D. ......................................... 115

Tabela A1.1 - Parâmetros dos elementos que compõe um arquivo de definição de malha de

transporte. 144

introduçãojeansimao/siteanalytice/analytice-final/... · interoperabilidade entre as ferramentas...

Documents