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
6
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.
Contexto e Objetivos do Trabalho 9
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
Contexto e Objetivos do Trabalho 11
• 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.
Contexto e Objetivos do Trabalho 13
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
Contexto e Objetivos do Trabalho 15
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
necessidades e objetivos
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
Contexto e Objetivos do Trabalho 17
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
necessidades e objetivos
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;
Contexto e Objetivos do Trabalho 19
• 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
Contexto e Objetivos do Trabalho 21
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;
Contexto e Objetivos do Trabalho 23
• 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.
Contexto e Objetivos do Trabalho 25
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;
Simulação e Animação Gráfica de FMS 29
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.
Simulação e Animação Gráfica de FMS 31
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
Simulação e Animação Gráfica de FMS 33
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
Simulação e Animação Gráfica de FMS 35
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.
Simulação e Animação Gráfica de FMS 37
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.
Simulação e Animação Gráfica de FMS 39
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
Simulação e Animação Gráfica de FMS 41
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.
Simulação e Animação Gráfica de FMS 43
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
Simulação e Animação Gráfica de FMS 45
• 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.
Simulação e Animação Gráfica de FMS 47
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.
Antecedentes: ANALYTICE 51
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
Antecedentes: ANALYTICE 53
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
Antecedentes: ANALYTICE 55
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;
Antecedentes: ANALYTICE 57
• 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,
Antecedentes: ANALYTICE 59
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
62
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
Requisitos da Arquitetura 65
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
Requisitos da Arquitetura 67
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;
Requisitos da Arquitetura 69
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.
Requisitos da Arquitetura 71
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
Requisitos da Arquitetura 73
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
Requisitos da Arquitetura 75
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
Requisitos da Arquitetura 77
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
Requisitos da Arquitetura 79
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
Requisitos da Arquitetura 81
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
Requisitos da Arquitetura 83
• 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
*
Requisitos da Arquitetura 85
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.
Implementação da Simulação 89
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)
Implementação da Simulação 91
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);
Implementação da Simulação 93
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.
Implementação da Simulação 95
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.
Implementação da Simulação 97
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 };
Implementação da Simulação 99
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
Implementação da Simulação 101
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:
Implementação da Simulação 103
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
Implementação do Animador Gráfico e Ambiente Físico 107
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.
Implementação do Animador Gráfico e Ambiente Físico 109
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,
Implementação do Animador Gráfico e Ambiente Físico 111
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.
Implementação do Animador Gráfico e Ambiente Físico 113
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.
Implementação do Animador Gráfico e Ambiente Físico 115
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
Implementação do Animador Gráfico e Ambiente Físico 117
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;
Implementação do Animador Gráfico e Ambiente Físico 119
• 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
Implementação do Animador Gráfico e Ambiente Físico 121
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.
Implementação do Animador Gráfico e Ambiente Físico 123
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
Implementação do Animador Gráfico e Ambiente Físico 125
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
Implementação do Animador Gráfico e Ambiente Físico 127
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.
Implementação do Animador Gráfico e Ambiente Físico 129
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;
Implementação do Animador Gráfico e Ambiente Físico 131
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
Implementação do Animador Gráfico e Ambiente Físico 133
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
139
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.
143
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); } }
155
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
Top Related