M0514 by Fainor

FACULDADE INDEPENDENTE DO NORDESTE CURSO DE ENGENHARIA DA COMPUTAÇÃO

ROGÉRIO HENRIQUE CORRÊA DE ARAÚJO

OPENGL COMO INTERFACE EM SISTEMAS AUTOMATIZADOS

VITÓRIA DA CONQUISTA - BA JULHO - 2008

ROGÉRIO HENRIQUE CORRÊA DE ARAÚJO

OPENGL COMO INTERFACE EM SISTEMAS AUTOMATIZADOS

Monografia apresentada no curso de graduação da Faculdade Independente do Nordeste (FAINOR), como requisito parcial para a obtenção do título de Bacharel em Engenharia da Computação. Orientador: Prof. M. Sc. Wilton Lacerda Silva Co-Orientador: Prof. M. Sc. Francisco Carvalho

VITÓRIA DA CONQUISTA – BA JULHO - 2008

iii

ROGÉRIO HENRIQUE CORRÊA DE ARAÚJO

OPENGL COMO INTERFACE EM SISTEMAS AUTOMATIZADOS

Aprovada em ___/___/___

___________________________________________________________________ M.Sc. Wilton Lacerda Silva Coordenador de Engenharia da Computação

BANCA EXAMINADORA / COMISSÃO AVALIADORA

M. Sc. Wilton Lacerda Silva Fainor – Faculdade Independente do Nordeste

M. Sc. Marcelo Barbosa de Almeida Fainor – Faculdade Independente do Nordeste

D. Sc. Carlos Takiya Fainor – Faculdade Independente do Nordeste

Dedico esta monografia primeiramente a Deus, essência da minha vida; aos meus pais,

João

Amélia,

minha

irmã,

Ludymille e minha tia, Roseneide, que estão sempre ao meu lado, me apoiando com amor e carinho, me ajudando a crescer cada vez mais.

AGRADECIMENTOS

Primeiramente, agradeço a Deus, por ter me guiado até esta vitória, sempre estando comigo e me iluminando tanto nos momentos difíceis como nos momentos prósperos. Sem Ele, não conseguiria alcançar a concretização desta etapa da minha vida e outras que virão; À meus pais, João e Amélia, minha irmã Ludymille, minha tia Roseneide, pela confiança, companheirismo, esforço, apoio e amor que se dedicam a mim, estando presentes em todos os momentos da minha vida; Ao meu orientador Prof. Wilton Lacerda pela atenção, incentivo e confiança. Aos meus co-orientadores Prof. Francisco Carvalho e Gina Pinheiro pelo apoio, atenção e disponibilidade; A todos meus amigos do Curso de Engenharia da Computação, em especial Mayone dos S. Oliveira, Ricardo Lins Motta e Uray Oliveria de A. Santos pelo companheirismo e amizade durante e depois do curso; Ao colega Frederico D. A. de S. Pereira, pelo grande apoio com o desenvolvimento do hardware; Aos meus professores do Curso de Engenharia da Computação, pela transmissão dos seus conhecimentos, que contribuíram para meu crescimento.

"É melhor tentar e falhar, que preocupar-se e ver a vida passar; é melhor tentar, ainda que em vão, que sentar-se fazendo nada até o final. Eu prefiro na chuva caminhar, que em dias tristes em casa me esconder. Prefiro ser feliz, embora louco, que em conformidade viver..." Martin Luther King

vii

RESUMO

ARAÚJO, Rogério Henrique Corrêa de. OpenGL como interface em processos automatizados. Monografia (Bacharel em Engenharia da Computação) FAINOR Faculdade Independente do Nordeste (FAINOR), Vitória da Conquista, Bahia, 2008.

Este trabalho apresenta o OpenGL, uma biblioteca de rotinas gráficas bi e tridimensionais amplamente utilizado em jogos, e sua aplicação na área de automação industrial. O objetivo deste é o estudo da utilização desta biblioteca como ferramenta gráfica na criação de sistemas supervisórios, com visualização tridimensional. Esta pesquisa é classificada como qualitativa, descritiva, experimental e exploratória. Através do desenvolvimento do software e hardware, concluiu-se que o OpenGL mostrou-se viável e eficaz quando utilizado em sistemas automatizados. Palavras-chave: supervisórios.

OpenGL,

automação,

visualização

tridimensional,

sistemas

viii

ABSTRACT

ARAÚJO, Rogério Henrique Corrêa de. OpenGL as interface in automated processes. Monograph (Bachelor´s degree in Computer Engineering) FAINOR Faculdade Independente do Nordeste (FAINOR), Vitória da Conquista, Bahia, 2008 This work presents the OpenGL, a two and three-dimensional graphics routine library widely used in games, and its application in industrial autom ation area. Its objective is the studying of this library’s use as graphic tool in the creation of supervisory systems, with three-dimensional visualization. This research is classified as qualitative, descriptive, experimental and exploratory. Through the development of software and the hardware, one concluded that the OpenGL revealed viable and efficient when used in automated systems.

Keywords: systems.

OpenGL,

automation,

three-dimensional visualization, supervisory

LISTA DE FIGURAS

Figura 1 - Celular com renderização OpenGL ES .....................................................23 Figura 2 – Exemplo de renderização.........................................................................23 Figura 3 – Simulador do Sistema Solar, da Software Bisque....................................24 Figura 4 – Cena do jogo Doom 3 ..............................................................................24 Figura 5 – Local do OpenGL num típico programa ...................................................27 Figura 6 – Local do OpenGL de aceleração de hardware num programa típico .......27 Figura 7 – Versão Simplificada do pipeline do OpenGL............................................28 Figura 8 – Uma função do OpenGL dissecada .........................................................30 Figura 9 – Sintaxe de comandos OpenGL ................................................................31 Figura 10 - Estrutura básica de um programa OpenGL.............................................32 Figura 11.A – Primeira parte do programa exemplo 1 – desenha cubo vermelho.....34 Figura 11.B – Continuação do programa exemplo 1 – desenha cubo vermelho.......34 Figura 12 - Execução do Exemplo 1 .........................................................................35 Figura 13 – Sistema com painel e sensores..............................................................42 Figura 14 – Utilização de CLPs .................................................................................42 Figura 15 – Sistema de supervisão e controle ..........................................................43 Figura 16 – Aplicação de exemplo do E3: dosagem de substâncias ........................45 Figura 17 – Edição de telas no E3 Studio, Aplicação de tratamento térmico de chapas.......................................................................................................................45 Figura 18 – Interface do iFIX 3.0 ...............................................................................46 Figura 19 – Objetos com medidas bi e tridimensionais .............................................49 Figura 20 – Vendo em três dimensões......................................................................50 Figura 21 – Etapa 1 do processo ..............................................................................54 Figura 22 – Etapa 2 do processo ..............................................................................54 Figura 23 – Etapa 3 do processo ..............................................................................55 Figura 24 – Etapa 4 do processo ..............................................................................55 Figura 25 – Etapa 5 do processo ..............................................................................55 Figura 26 – Etapa 6 do processo ..............................................................................56 Figura 27 – Etapa 6 do processo .............................................................................56 Figura 28 – Etapa 7 do processo ..............................................................................56 Figura 29 – Visão superior do projeto do hardware...................................................57

Figura 30.A – Visão em perspectiva do projeto e dimensões ...................................... 58 Figura 30.B – Hardware construído...........................................................................57 Figura 31 – Aspecto físico de alguns tipos de LED infravermelho ............................59 Figura 32– Características do comparador LM339 ...................................................59 Figura 33 – Esquema do circuito dos sensores.........................................................60 Figura 34 – Circuito elétrico dos sensores ................................................................61 Figura 35A – Um potenciômetro de uma volta. .........................................................61 Figura 35.B – Símbolo esquemático de um potenciômetro........................................61 Figura 36 – Cálculo da resolução do ADC0804 ........................................................62 Figura 37 – Características do conversor ADC0804 .................................................62 Figura 38 – Esquema do circuito conversor analógico-digital ..................................63 Figura 39 – Circuito elétrico conversor analógico-digital ...........................................64 Figura 40 – Desenho ilustrativo de um relé e a configuração mais comum dos contatos dos relés .....................................................................................................65 Figura 41– Modelos de relés vendidos comercialmente............................................65 Figura 42 – Esquema do circuito de controle dos motores........................................66 Figura 43 – Circuito elétrico de controle dos motores ...............................................67 Figura 44 – Esquema do circuito USB.......................................................................68 Figura 45 – Diagrama de Caso de Uso .....................................................................76 Figura 46 – Diagrama de Classes .............................................................................77 Figura 47 – Diagrama de Seqüência........................................................................83 Figura 48 – Declaração das bibliotecas do programa ...............................................84 Figura 49 – Configuração inicial da porta USB..........................................................85 Figura 50 – Definição do empurrador (função Desenha) ..........................................86 Figura 51 – Definição dos valores que serão recebidos dos sensores e medidor.....86 Figura 52 – Definições para a porta USB..................................................................87 Figura 53 – Função compara_tamanho.....................................................................88 Figura 54 – Tela inicial do programa .........................................................................89 Figura 55.A – Processo iniciado (virtual)...................................................................89 Figura 55.B – Processo iniciado (real)....................................................................... 89 Figura 56.A - Objeto virtual sendo medido........... .....................................................90 Figura 56.B – Objeto real sendo medido....................................................................90 Figura 57.A – Objeto virtual empurrado para a segunda esteira...............................90 Figura 57.B – Objeto real empurrado.........................................................................90

Figura 58.A – Objeto virtual rejeitado pelo sistema ...................................................91 Figura 58.B – Objeto real rejeitado pelo sistema.......................................................91 Figura 59.A – Objeto virtual aceito pelo sistema .......................................................91 Figura 59.B – Objeto real aceito pelo sistema............................................................91 Figura 60 – Detecção de erros no sistema................................................................93 Figura 61.A – Clique na área para “zoom” ................................................................93 Figura 61.B – Área aproximada..................................................................................93 Figura 62.A – Motor do empurrador ..........................................................................94 Figura 62.B – Visualização das engrenagens do motor.............................................94

xii

LISTA DE QUADROS

Quadro 1 – Versões do OpenGL...............................................................................25 Quadro 2 – Sufixos de comandos e tipos de dados ..................................................31 Quadro 3 – Vantagens da Automação ......................................................................41 Quadro 4 – Componentes do circuito dos sensores..................................................60 Quadro 5 – Tabela de conversão do ADC0804.........................................................62 Quadro 6 – Componentes do circuito conversor analógico-digital ...........................63 Quadro 7 – Componente do circuito dos motores .....................................................66

xiii

LISTA DE ABREVIATURAS ARB - Architecture Review Board CAD - Computer Aided Design ou desenho auxiliado por computador CLP - Controlador L贸gico Program谩vel OpenGL - Open Graphics Library

xiv

SUMÁRIO

1 INTRODUÇÃO .......................................................................................................16 1.1 PROBLEMA.............................................................................................................. 17 1.2 OBJETIVOS ............................................................................................................. 17 1.2.1 Objetivo geral .........................................................................................17 1.2.2 Objetivos específicos.............................................................................17 1.3 HIPÓTESE................................................................................................................ 18 1.4 MOTIVAÇÃO ............................................................................................................ 18 1.5 JUSTIFICATIVA ....................................................................................................... 18 2 REVISÃO DE LITERATURA .................................................................................20 2.1 OPEN GRAPHICS LIBRARY ................................................................................. 20 2.1.1 Conceito e aplicabilidade ......................................................................20 2.1.2 Funcionamento e estrutura do OpenGL...............................................26 2.2 A AUTOMAÇÃO E A TECNOLOGIA COMPUTACIONAL .................................. 36 2.2.1 Áreas de aplicação.................................................................................39 2.2.2 A Importância da Automação................................................................40 2.3 SISTEMAS SUPERVISÓRIOS............................................................................... 41 2.4 VISUALIZAÇÃO E INTERFACE GRÁFICA .......................................................... 46 2.4.1 Visualização em sistemas supervisórios .............................................48 3 METODOLOGIA ....................................................................................................51 4 DESENVOLVIMENTO DO PROJETO ...................................................................53 4.1 ANÁLISE DE REQUISITOS DO PROJETO ......................................................... 53 4.1.1 Descrição do processo ..........................................................................54 4.2 ESPECIFICAÇÃO.................................................................................................... 57 4.3 ARQUITETURA DO HARDWARE ......................................................................... 58 5 PROJETO DO SOFTWARE .................................................................................69 5.1 ANÁLISE DE REQUISITOS DO SOFTWARE...................................................... 69 5.1.1 Requisitos funcionais ............................................................................69

5.1.2 Requisitos não-funcionais.....................................................................75 5.2 MODELAGEM DA APLICAÇÃO ............................................................................ 76 5.2.1 Diagrama de Caso de Uso .....................................................................76 5.2.2 Diagrama de Classes .............................................................................77 5.2.3 Diagrama de Seqüência.........................................................................82 5.3 FUNCIONAMENTO DO SOFTWARE ................................................................... 83 6 ALGUMAS POSSIBILIDADES DA UTILIZAÇÃO DO OPENGL EM SISTEMAS SUPERVISÓRIOS.....................................................................................................92 7 CONSIDERAÇÕES FINAIS ...................................................................................95 REFERÊNCIAS.........................................................................................................99

1 INTRODUÇÃO O OpenGL (Open Graphics Library), uma interface de programação que utiliza as suas funcionalidades em programas aplicativos é capaz de produzir gráficos computacionais bidimensionais e tridimensionais. Sendo um dos padrões mais adotados na indústria de hardware e renderização 3D, ele proporciona uma aceleração de hardware em 3D, manipulando uma quantidade de dados em tempo real. O OpenGL é bastante utilizada em ferramentas CAD (Computer Aided Design ou desenho auxiliado por computador), realidade vritual, simulações e visualizações científicas e desenvolvimento na área de videogames. A automação industrial, que a cada dia vem substituindo a mão-de-obra humana em determinadas tarefas e até realizando outras antes impossíveis de ser realizadas pelo ser humano, vem sendo amplamente aplicada em inúmeras áreas de produção industrial, sempre visando a produtividade, qualidade e segurança em um processo. Além da realização das atividades de forma automatizada, é também de grande importância um sistema de supervisão e controle para permitir uma melhor confiabilidade, agilidade e visualização do processo em andamento. Em um sistema típico, que consiste em vários sensores e atuadores, é necessário a coleta de informações dos sensores para que se possa tomar decisões de controle no processo e tal coleta de informações requer um computador integrado ao sistema. Para se ter um controle dos dados referentes aos processos, é necessário uma interface com o usuário, permitindo uma visualização detalhada do sistema. Com um sistema de visualização bem definido, as tarefas de controle e tomadas de decisões tornam-se mais fáceis. Para um melhor controle e visualização do processo industrial, acha-se necessário a utilização de uma interface amigável e de fácil compreensão para o operador. Com a utilização do OpenGL como interface em sistemas supervisórios, o usuário terá uma sensação de estar de fato vendo o processo em tempo real, já que o mesmo traz uma aceleração de hardware em 3D, manipulando quantidades consideráveis de dados em tempo real, trabalhando com recursos geométricos, transformações, renderização, efeitos de movimento, transparência e reflexos. Com uma visualização tridimensional do processo, a visão será mais abrangente, detalhada, realista e em tempo real.

Este estudo tem a pretenção de apresentar um programa supervisório de automação com OpenGL, o qual permitirá uma visualização tridimensional do projeto. Sendo relevante à classe industrial e à area de Engenharia da Computação. Para tanto, foi desenvolvido um hardware que é controlado por um software supervisor, capaz de transmitir ao usuário cada etapa do processo em 3D. 1.1 PROBLEMA É observado que a maioria dos sistemas supervisórios utilizados atualmente possuem como interface gráfica a visualização bidimensional. Contudo, sabe-se que a visualização em 2D não apresenta uma interface totalmente fiel ao processo observado, pelo fato de que uma imagem bidimensional só oferece altura e largura. Entretanto sabe-se que uma imagem tridimensional proporciona uma observação de altura, largura e profundidade, o que representa uma grande diferença acerca da representação fiel do sistema. Com a visualização tridimensional, pode-se ter melhor representação das informações e ângulos de visões diferentes para visualizar o processo. Tal recurso é oferecido pelo OpenGL. Assim uma questão é levantada: Será que a utilização do OpenGL como ferramenta gráfica na criação de sistemas supervisórios é conveniente e satisfatório?

1.2 OBJETIVOS 1.2.1 Objetivo geral Estudar a utilização do OpenGL como ferramenta gráfica na criação de sistemas supervisórios. 1.2.2 Objetivos específicos •

Criar um hardware adequado com sensores (infravermelhos) e atuadores (motores), o qual será ligado posteriormente ao computador;

•

Projetar e desenvolver um protótipo em forma de maquete, que será controlado pelo computador para utilização do sistema supervisório;

•

Apresentar melhor solução de visualização de sistemas na área de automação industrial;

•

Verificar viabilidade da utilização do OpenGL em sistemas supervisórios.

1.3 HIPÓTESE A visualização 3D do processo industrial possibilita uma maior supervisão acerca dos processos, possibilitando uma melhor observação e controle. 1.4 MOTIVAÇÃO Durante as aulas da disciplina Automação Industrial, foi desenvolvido um projeto em que era necessária uma interface para controlá-lo. Foi observado que as interfaces até então utilizadas para este fim eram limitadas e bidimensionais, não oferecendo realismo e detalhamento do processo controlado. Foi desenvolvida uma interface bidimensional para o projeto da disciplina, o que incentivou o pesquisador a desenvolver interfaces cada vez mais detalhadas, informativas e realistas dos processos. Surgiu então a oportunidade de estudar uma ferramenta nova, mais moderna e poderosa, a qual traz a possibilidade de criar figuras tridimensionais realistas, criando uma perspectiva de implantação de recursos 3D em sistemas de supervisão em sistemas automatizados. 1.5 JUSTIFICATIVA Todos os elementos que fazem parte deste mundo real possuem três dimensões: altura, largura e profundidade. Assim como em aplicações gráficas e jogos, os objetos do mundo real possuem essas três medidas. Até mesmo uma folha de papel, que parece ser fina demais, também é medida em três dimensões. Em duas dimensões, têm-se duas coordenadas, chamadas de x e y. Em que a coordenada x direciona horizontalmente e a coordenada y direciona verticalmente. Muitas aplicações e jogos que foram lançados em programação 2D, só era possível a movimentação e visualização para frente/trás e para cima/baixo. Adicionando-se uma nova coordenada, a z, é dada perspectiva à visualização, em que se ganha profundidade, maior detalhamento e sensação de estar num mundo virtual. O OpenGL, que é amplamente utilizado para a criação de gráficos tridimensionais na indústria de jogos para PC, possui um grande potencial como ferramenta construtora de interface em sistemas supervisórios, possibilitando uma melhor visualização e controle mais efetivo. Frente ao apresentado, justifica-se a

pretensão deste trabalho, sendo que o mesmo possibilitará o conhecimento e aplicação desta ferramenta na área de automação industrial.

2 REVISÃO DE LITERATURA Este capítulo apresenta

revisão

bibliográfica

utilizada

para

desenvolvimento do projeto, a qual traz a apresentação do OpenGL, também são brevemente discutidos a Automação e a tecnologia computacional, bem como Sistemas Supervisórios e sua aplicabilidade, e por fim são apresentados a Visualização e Interface gráfica.

2.1 OPEN GRAPHICS LIBRARY 2.1.1 Conceito e aplicabilidade OpenGL segundo Tufte (1983) define uma API (Application Programming Interface ou Interface de Programação de Aplicativos), isto é, uma interface multiplataforma e multilinguagem para a criação de aplicações que produzem gráficos computacionais tanto em duas dimensões (2D) como em três dimensões (3D). Trata-se uma especificação aberta e multiplataforma de uma biblioteca de rotinas gráficas e de modelagem, ou API utilizada para o desenvolvimento de aplicações de Computação Gráfica, tais como jogos e sistemas de visualização oferecendo um controle simples e direto sobre um conjunto de rotinas, permitindo ao programador a especificação de objetos e as operações necessárias para a criação de imagens gráficas de alta qualidade (TUFTE, 1983). De acordo com Stasko; Brown; Price (1997), a interface gráfica OpenGL é aberta

para

desenvolvimento

programas

gráficos

bidimensionais

tridimensionais e pode ser incorporada a qualquer sistema de janelas (MS Windows, X Window, etc). Possuindo cerca de 250 funções distintas que podem ser aplicadas na construção gráfica de cenas tridimensionais complexas funcionando como uma máquina de estados, nesta interface o controle dos atributos é feito através de um conjunto de variáveis de estado de valores iniciais default, que podem ser alterados se necessário. Como por exemplo, a criação de objetos de mesma cor até que seja definido um novo valor para esta variável. O OpenGL foi desenvolvido pela Silicon Graphics Inc. (SGI), que no fim dos anos 80, havia lançado uma API anterior chamada de IRIS GL, cuja intenção original era desenvolver aplicações gráficas como animações e CAD. A IRIS GL permitia ao

programador desenhar objetos em 3D e criar um sistema de janelas inteiro para desenhar e manipular dados na tela. Mais de 1.500 aplicações utilizaram a plataforma IRIS GL para renderizar seus gráficos (SEDDON, 2005). A desvantagem do IRIS GL, segundo o autor, era a baixa portabilidade, pois necessitavam de hardware especialmente otimizado para a exibição de gráficos sofisticados. Quando a SGI tentou levar a IRIS GL a outras platarformas de hardware, ocorreram problemas. Em 1992, a SGI lançou uma nova API 3D chamada de Open Graphics Library,

mais

conhecido

como

OpenGL.

palavra

“Open”

indica

maior

adaptabilidade a outras plataformas de hardware e sistemas operacionais. Esta API utiliza uma convenção própria de nomes, em que todos os comandos precedem com as letras “gl” em minúsculas (por exemplo, glColor). Os tipos de dados no OpenGL também possuem uma convenção própria de nomes, em que precedem com as letras “GL” em maiúsculas (SEDDON, 2005; STASKO; BROWN; PRICE, 1997). Por muitos anos, a indústria de gráficos o utilizou, enquanto a indústria de jogos para PC ainda utilizava o hardware não-acelerado do DOS. A SGI criou uma equipe para controlar a progressão desta API. Esta equipe chamada de OpenGL Architecture Review Board (ARB), inclui companhias como a SGI, nVIDIA, ATI, Matrox, 3Dlabs e outras. Os membros reuniam-se várias vezes por ano para discutir as inovações a serem aplicadas com esta API. No meio dos anos 90, os preços dos hardwares de aceleração começaram a baixar de preço (TUFTE, 1983). Placas de vídeo começaram a ser vendidas com capacidades especiais que antes somente os proprietários das bibliotecas gráficas tinham acesso. O Windows 95 e NT4 incluíram em seus sistemas o suporte de renderização para OpenGL, garantindo uma compatibilidade completa com todas as máquinas que rodavam esses sistemas operacionais (WRIGHT JR.; LIPCHAK; HAEMEL, 2007; SEDDON, 2005; STASKO; BROWN; PRICE, 1997). Quando as placas gráficas 3D de custo baixo começaram a ser lançadas para PC, muitos distribuidores de hardware e jogos integraram-se ao OpenGL devido a sua facilidade de uso comparada com o Direct3D da Microsoft. A própria Microsoft encorajou o uso dos drivers para OpenGL em todas as placas gráficas para PC, no Windows 98. Em 1997 surgiu uma questão política quanto ao OpenGL devido à sua grande atenção. Antes do Windows 98 ser lançado, a Microsoft anunciou que não

estenderia mais a licença do código do mesmo na versão beta do Windows 98 e os distribuidores de hardware estariam proibidos de lançarem seus drivers (WRIGHT; LIPCHAK; HAEMEL, 2007). Para complicar a situação, a SGI, com esforço, anunciou que não continuaria mais a promover aplicações de OpenGL para consumidores, e que passaria a trabalhar com a Microsoft numa nova API chamada Fahrenheit, trazendo o quase “fim” do OpenGL. Algo extraordinário aconteceu, o OpenGL começou a ganhar vida própria. Distribuidores de hardware com ajuda da SGI (pré-Fahrenheit) continuaram a dar suporte ao OpenGL com novos drivers. Pois o mesmo não era somente eficiente em jogos, como também em outros tipos de aplicações, trazendo o desejo dos desenvolvedores de terem seus softwares rodando em versões comerciais do Microsoft Windows. Quando o OpenGL tornou-se novamente disponível para o hardware dos consumidores, os desenvolvedores não precisavam mais da SGI, pois era fácil de ser implementada e já estava em uso há anos. Havia uma grande abundância de documentações sobre a utilização do OpenGL, bem como vários programas prontos, trazendo então, o reflorescimento do mesmo. Com o passar do tempo, a Microsoft parou o desenvolvimento do Fahrenheit. Em 1998, a Microsoft lançou sua própria API chamada de Direct3D, que incluía seu próprio componente multimídia, passando a incluir as características do OpenGL, tornando-se mais fácil de usar. Hoje em dia, cerca de dez anos depois, o Direct3D de hoje carrega semelhanças da API antecedente Contanto, a popularidade do OpenGL continuou a crescer como tecnologia de renderização alternativa para o Microsoft Windows e aumentando sua portabilidade com quase todos os sistemas operacionais e dispositivos de hardware (WRIGHT; LIPCHAK; HAEMEL, 2007; SEDDON, 2005; STASKO; BROWN; PRICE, 1997). Até celulares com tecnologia de gráficos 3D estão suportando um subconjunto do OpenGL, chamado OpenGL ES, como observado na figura 1, a seguir, bem como outros exemplos gráficos da aplicação do OpenGL.

Figura 1 - Celular com renderização OpenGL ES Fonte: (WRIGHT; LIPCHAK; HAEMEL, 2007).

O OpenGL traz recursos poderosos de renderização, sendo eles em tempo real, o qual requer maior capacidade de processamento do que a renderização normal, a qual não requer tanto poder de processamento, um exemplo é apresentado na figura 2.

Figura 2 – Exemplo de renderização Fonte: (WRIGHT; LIPCHAK; HAEMEL, 2007).

Ele é muito utilizado também em aplicações de simulação, tal como o Simulador do Sistema Solar, da empresa Software Bisque, que simula todo o ambiente espacial, bem como todos os movimentos dos planetas e objetos no espaço, figura 3.

Figura 3 – Simulador do Sistema Solar, da Software Bisque Fonte: (WRIGHT; LIPCHAK; HAEMEL, 2007).

Amplamente utilizado na indústria dos videogames, o OpenGL foi utilizado na criação do famoso jogo para computador DOOM 3, em que todos os recursos deste são utilizados, tais como neblina em tempo real, anti-aliasing (suaviza as bordas de uma imagem), sombras volumosas, mapeamento de imagens, efeitos de movimento, transparência, reflexos, texturas em 3D.

Figura 4 – Cena do jogo Doom 3 Fonte: Open GL (2007)

Atualmente, todas as placas de aceleração gráfica 3D para PC funcionam tanto com os drivers do OpenGL quanto os do Direct3D. Com o OpenGL também foram desenvolvidas aplicações de aceleração do processamento de imagem e vídeo. Muitos desenvolvedores preferem o OpenGL, que agora é extensamente reconhecida e aceita como a API de padrão industrial para gráficos de tempo real em 3D e 2D. O OpenGL, que tem um futuro promissor como a API preferencial de

uma variedade de aplicativos e plataformas de hardware, está bem posicionada com a vantagem das futuras inovações de gráficos tridimensionais.Com o mecanismo de extensão do OpenGL, os distribuidores podem constatar as características de seus novos hardwares sem a necessidade de esperar pela Microsoft lançar drivers atualizados. Sendo assim, aplicado a uma enorme variedade de linguagens de programação tais como C/C++, Java e Visual Basic, até novas linguagens como o C# estão sendo utilizadas para criar jogos para PC e aplicativos usando o OpenGL. O OpenGL pode aproveitar-se dos recursos fornecidos pelos diversos hardwares gráficos segundo Wright; Lipchak; Haemel (2007), já que é um padrão destinado à renderização, a mesma pode ser utilizada em qualquer sistemas de janelas, tais como XWindow System ou MSWindows (SEGAL, 1996). Esta interface é extremamente eficiente, pois muitos dos seus algoritmos são implementados em hardware nas placas gráficas mais modernas, sem comprometer o desempenho do hardware nem perder o controle sobre as operações de hardware (WRIGHT; LIPCHAK; HAEMEL, 2007). Entretanto, segundo os autores, mesmo o OpenGL apresentando uma vantagem pela independência de sistemas de janelas, ela

torna-se um fator

limitante, já que por conta disto, não oferece a possibilidade de gerenciamento de janelas de manipulação de eventos. Para resolver esta e outras disfuncionalidades do OpenGL, surgiu a Open Inventor, que é uma toolkit orientada a objetos, a qual concentra-se na construção e estruturação de cenas 3D, utilizando o OpenGL para a renderização das cenas. Atualmente, a versão mais utilizada do OpenGL é a 2.1, sendo que a versão 3 foi anunciada em agosto de 2007. As versões iniciais e atual estão indicadas no quadro 1 a seguir, em que também é mostrado o ano em que foram lançadas. OpenGL versões – Ano de lançamento Versão 1.0 – Junho de 1992 Versão 1.1 – Dezembro de 1995 Versão 1.2 – Março de 1998 Versão 1.2.1 – Outubro de 1998 Versão 1.3 – Agosto de 2001 Versão 1.4 – Julho de 2002 Versão 1.5 – Julho de 2003 Versão 2.0 – Setembro de 2004 Versão 2.1 – Agosto 2006 Versão 3.0 – Agosto de 2007 Quadro 1 – Versões do OpenGL Fonte: Segal e Akeley (2007)

2.1.2 Funcionamento e estrutura do OpenGL O OpenGL é uma API mais de procedimentos gráficos do que descritiva. Ao invés de descrever a cena e como ela deve aparecer, o programador indica os passos necessários para criar uma aparência ou efeito. Estes “passos” envolvem chamadas dos vários comandos do OpenGL. Estes comandos desenham gráficos primitivos como pontos, linhas e polígonos em três dimensões. Além do mais, o OpenGL suporta iluminação e sombreamento, mapeamento de textura, blending, transparência, animação e muitos outros efeitos especiais. Cada sistema que irá rodá-lo (por exemplo, Mac OS X ou o Microsoft Windows) já possui suas próprias funções para este propósito e é responsável pelo “manuseio” dos controles de desenho de uma janela do mesmo. Não existe arquivo específico do OpenGL, os programadores devem implementar de acordo com suas necessidades de alto nível usando os comandos de baixo nível do mesmo. Implementações genéricas são descritas como implementações de software, já as implementações de hardware são criadas para um dispositivo específico de hardware, tais como placas gráficas ou console de vídeo game. Uma implementação genérica pode, tecnicamente, rodar em qualquer dispositivo desde que o sistema possa mostrar a imagem gerada. A figura a seguir mostra o local típico que o OpenGL e a implementação genérica ocupam quando uma aplicação do Windows está rodando. O programa típico chama muitas funções, algumas que o programador cria e outras que são fornecidas pelo sistema operacional ou pelas bibliotecas da linguagem de programação. Aplicações do Windows que criam saída na tela chamam uma API do Windows chamada de GDI (graphics device interface ou “interface de dispositivo gráfico”), a qual contém métodos que permite desenhar e criar textos e outros elementos na janela. A rasterização consiste na conversão de dados geométricos e do pixel em fragmentos.

Figura 5 – Local do OpenGL num típico programa Fonte: (WRIGHT; LIPCHAK; HAEMEL, 2007).

Uma implementação de hardware do OpenGL geralmente é realizada na forma de driver de placas gráficas. A figura 6, a seguir mostra a relação da aplicação assim como a figura 5 apresentou para as implementações de software. É observado que as chamadas da API do OpenGL são passadas para o driver do hardware. Este driver não passa sua saída para o GDI do Windows para mostrar na tela, o driver faz a interface diretamente com o display do hardware gráfico, trazendo consequentemente a idéia do pipeline do OpenGL.

Figura 6 – Local do OpenGL de aceleração de hardware num programa típico Fonte: (WRIGHT; LIPCHAK; HAEMEL, 2007)

A maior parte dos programas implementados do OpenGL possuem ordem de operações a serem executadas. A palavra “pipeline” é utilizada para descrever um processo que leva dois ou mais estágios distintos ou passos. A figura 7 a seguir mostra uma versão simplificada do pipeline do OpenGL. Assim como a aplicação faz as chamadas de função do OpenGL, os comandos são colocados no buffer de comandos. Este buffer eventualmente é preenchido com comandos, dados de vértices e texturas. Os comandos e dados passam para o próximo estágio do

pipeline quando o buffer é acionado. Transformação e Iluminação é um estágio matematicamente intensivo, onde pontos são usados para descrever a geometria dos objetos, onde são recalculadas de acordo com a localização e orientação do objeto. Os cálculos da iluminação são para indicar o brilho das cores em cada vértice. Após a rasterização, a imagem é mandada para o frame buffer, memória do dispositivo gráfico que apresentará a imagem na tela.

Figura 7 – Versão Simplificada do pipeline do OpenGL Fonte: (WRIGHT; LIPCHAK; HAEMEL, 2007).

Algumas das funções gráficas do OpenGL podem ser citadas abaixo: A função chamada Buffer de acumulação, em que múltipos frames renderizados podem ser compostos para produzir uma única imagem. Este buffer é utilizado para gerar efeito de profundidade de campo, “blur” de movimento e suavização da imagem (anti-aliasing). A função Alfa Blending pode gerar transparência nos objetos utilizando a informação alfa, definindo total transparência ou opacidade de um objeto. Anti-aliasing, que é um método de renderização que suaviza linhas e curvas, calcula a média da cor dos pixels junto à linha, fornecendo uma aparência mais suave. O Modo Color-Index é um buffer de cores que armazena os índices de cores dos componentes vermelhos, verdes, azuis e alfa das cores (RGBA). A Display List é uma lista de comandos do OpenGL, que podem ser préprocessados e executar de maneira mais eficiente do que se fossem executados de modo imediato. A função chamada Double buffering é utilizada para trazer uma animação mais suave dos objetos, permitindo que somente imagens completas sejam sempre apresentadas na tela (HAWKINS, 2004). A Iluminação e sombreamento de materiais é a computação da cor exata em algum ponto, de acordo com as propriedades materiais para a superfície.

As operações de pixel armazenam, transformam e processam o aumento e redução das imagens. O mapeamento de texturas é um processo em que se aplica uma imagem a uma primitiva gráfica, gerando mais realismo nas imagens. As transformações trazem as mudanças de rotação, tamanho e perspectiva de um objeto no espaço 3D. O Z-buffering, utilizado na remoção de superfície escondida, verifica se uma porção de algum objeto é mais próxima da tela do que outra (HAWKINS, 2004). Para o funcionamento do OpengGL no Microsoft Windows, são necessários alguns arquivos específicos, os quais podem variar de nome da extensão da biblioteca auxiliar do compilador (que pode ser da extensão .a ou .lib, dependendo do compilador utilizado), porém as funções são as mesmas. As bibliotecas do OpenGL são encontradas como parte do sistema operacional Microsoft Windows, e também podem ser baixadas no site oficial do OpenGL: http://www.opengl.org. O gl.h é o leitor primário do OpenGL. Por convenção, deve estar na pasta GL do compilador que será utilizado. O glu.h é o leitor da biblioteca de utilidades do OpenGL, colocado na mesma pasta que o gl.h. O arquivo opengl32.lib é uma biblioteca que contém os comandos para as funções do OpenGL e deve ser colocado na pasta de biblioteca do compilador (HAWKINS, 2004). O glu32.lib é outra biblioteca que contém os comandos para as funções da biblioteca de utilidades do OpenGL. O opengl32.dll é uma biblioteca de link dinâmico que contém as funções de implementação e está ligada aos drivers de hardware de vídeo, é encontrada na pasta de sistema do Windows (system32). O glu32.dll é outra biblioteca de link dinâmico que contém as funções de implementação da biblioteca de utilidades do OpenGL, encontrada na pasta system32 do Windows (BARBOSA SOBRINHO, 2003). O GLUT (OpenGL Utility ToolKit) é um conjunto de ferramentas para a criação de programas OpenGL, o qual é suportado pela maior parte das plataformas. Como o OpenGL não suporta diretamente nenhuma forma de janela, menus ou entrada, o GLUT oferece a funcionalidade de todas estas áreas, provendo uma API portátil, a qual permite que os programas rodem em várias plataformas. O GLUT suporta janelas múltiplas para a renderização OpenGL, respostas a eventos baseados em Callback de funções, rotinas “idle” e “timers”, criação de menus pop-ups, suporta bitmaps e traz uma grande variedade de funções para gerenciamento de janelas.

A maioria das funções do OpenGL seguem uma convenção de nomenclatura em que informa de qual biblioteca as funções são, bem como algumas também informam quais tipos de argumento que a função possui. Todas as funções possuem uma “raiz” que representa o comando da função correspondente. Todas as funções do OpenGL seguem o seguinte formato: <prefixo da biblioteca> <comando raiz> <contador opcional de argumentos> <tipo opcional de argumentos>, exemplificado na figura 8, a seguir.

Figura 8 – Uma função do OpenGL dissecada Fonte: (WRIGHT; LIPCHAK; HAEMEL, 2007).

Todos os comandos utilizam o prefixo “gl” em minúsculas, que representa a biblioteca gl. As constantes são definidas com as iniciais “GL_”, em letras maiúsculas, seguido por “underline” para separar as palavras (por exemplo, GL_COLOR_BUFFER_BIT).

A função de exemplo da figura 8 indicada, a qual

define o comando de cores, traz o sufixo “3f” que indica três argumentos de pontoflutuante. Uma outra versão de “Color” necessita de 4 argumentos, uma delas define a transparência (alpha channel) (BARBOSA SOBRINHO, 2003). Para facilitar a identificação da lista de argumentos, é adicionado o número e o tipo do argumento. A figura 9, a seguir, indica uma função do OpenGL e as convenções adotadas.

Figura 9 – Sintaxe de comandos OpenGL Fonte: (BARBOSA SOBRINHO, 2003)

O OpenGL possui alguns comandos que aceitam até 8 tipos diferentes de argumentos, em que as letras usadas como sufixo vão determinar o tipo de dados para a implementação. Os sufixos de comandos com seus respectivos tipos de dados para argumentos são apresentados no quadro 2 abaixo.

Sufixos de comandos e tipos de dados para argumentos Sufixo

Tipo de Dados

Tipo correspondente

Definição de tipo para

na linguagem C

OpenGL

Inteiro de 8 bits

Signed char

GLbyte

Inteiro de 16 bits

Short

GLshort

Inteiro de 32 bits

Int ou long

GLint,GLsizei

Ponto flutuante de 32 bits

Float

GLfloat,GLclampf

Ponto flutuante de 64 bits

double

GLdouble,GLclampd

Inteiro não sinalizado de 8 bits

Unsigned char

GLubyte,GLboolean

Inteiro não sinalizado de 16 bits

Unsigned short

GLushort

Inteiro não sinalizado de 32 bits

Unsigned

int

unsigned long Quadro 2 – Sufixos de comandos e tipos de dados Fonte: (BARBOSA SOBRINHO, 2003)

GLuint,GLenum,GLbitfield

Para que um programa OpenGL execute perfeitamente, o mesmo deve ter um mínimo de requisitos, em que se deve declarar os arquivos de “header (bibliotecas), configurar e abrir a janela, inicializar os estados no OpenGL, registrar as funções de “callback”, renderizar, redimensionar, configurar entradas tais como mouse e teclado, e entrar no loop de processamento dos eventos. Um programa exemplo do OpenGL que traz sua estrutura básica, é apresentado na figura 10 a seguir.

//Estrutura básica de um programa OpenGL #include <GL/gl.h> //Biblioteca do OpenGL #include <GL/glut.h> //Biblioteca do GLUT void main( int argc, char** argv ) { glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB); //Define modo de operação GLUT glutInitWindowSize(400,350); //Especifica tamanho da janela glutInitWindowPosition(10,10); //Especifica posição da janela na tela glutCreateWindow("Nome do programa"); //Cria janela com título Inicializa();

//Chama função que irá inicializar

glutDisplayFunc( Desenha ); //Executa a funcao callback de redesenho da //Janela de visualização glutReshapeFunc(AlteraTamanhoJanela); // Registra a função callback de //redimensionamento da janela de visualização glutKeyboardFunc( Teclado ); // Registra a função callback para tratamento //das teclas ASCII glutMouseFunc(GerenciaMouse); //Registra a função callback para eventos de // botões do mouse glutIdleFunc( idle ); glutMainLoop();

// Inicia o processamento e aguarda interações

//do usuário }

Figura 10 - Estrutura básica de um programa OpenGL

As biliotecas, ou arquivos de header (.h) possuem as rotinas e declarações necessárias para o funcionamento do OpenGL/GLUT com a linguagem C/C++. As funções

glutInitDisplayMode()

glutCreateWindow()

são

responsáveis

pela

configuração da janela. A função glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB) cria uma janela double-buffered (GLUT_DOUBLE) com o modo de cores

RGBA(GLUT_RGB), que define a intensidade dos componentes red, green e blue (vermelho, verde e azul) separadamente. A função glutCreateWindow("Nome do programa") cria uma janela com o nome especificado, de acordo com os parâmetros definidos nas funções glutInitWindowSize (tamanho da janela em pixels) e glutInitWindowPosition (posição da janela). A seguir é chamada a rotina init() que inicializará o prograna, em que serão inicializados os estados do OpenGL que serão executados. Depois será necessário o registro das funções callback, que serão utilizadas na execução do programa. Por fim, o programa entrará num processo de loop, que vai interpretar os eventos e chamadas de rotinas especificadas como callback. As funções de callback são definidas como funções executadas quando qualquer evento ocorre no sistema, como o redimensionamento da janela, quando o usuário fornece entradas através de teclado, mouse ou outro dispositivo de entrada, e animações. Cabendo ao programador definir a ação específica que será executadas de acordo com a ocorrência de cada evento. A GLUT fornece suporte a vários tipos de ações de callback, que devem ser utilizadas nas situações descritas abaixo. glutDisplayFunc() – quando um pixel ou figura na janela necessita ser atualizado. glutReshapeFunc() – quando a janela é redimensionada. glutKeyboardFunc() – quando alguma tecla do teclado é pressionada. glutMouseFunc() – quando o usuário pressiona um botão do mouse. glutMotionFunc() – quando o usuário movimenta o mouse enquanto mantém algum botão do mesmo pressionado. glutPassiveMouseFunc() – quando o mouse é movimentado,sem estar apertando os botões glutIdleFunc() – quando nada estiver acontecendo, muito utilizada em animações.

Um exemplo completo de um programa simples, que desenha um cubo na tela pode ser demonstrado nas figuras 11 e 12, a seguir.

//Programa simples

desenha cubo vermelho

Exemplo 1

//Referência do Código: OpenGL Programming Guide

RedBook

#include<stdlib.h> #include<GL/glut.h>

//Funcao callback de redesenho da janela de visualização void Desenha(void) { //Limpa janela de visualizacao com a cor branca glClearColor(1,1,1,1); //Limpa o Buffer de Pixels glClear(GL_COLOR_BUFFER_BIT); //Define dor de desenho: vermelho glColor3f(1,0,0); //Desenha um cubo sólido glutSolidCube(1); glEnd(); //Inicia processo de desenho através dos dados bufferizados glFlush(); } //Funcao callback chamada para gerenciar eventos de teclas void Teclado(unsigned char key, int x, int y) { if (key == 27)

//Se tecla

ESC

for pressionada, sair

exit(0); }

//Funcao responsavel por inicializar parâmetros e variaveis void Inicializa(void) { //Define a janela de visualizacao 2D glMatrixMode(GL_PROJECTION); //inicializa os valores de visualização gluOrtho2D(-1.0,1.0,-1.0,1.0); glMatrixMode(GL_MODELVIEW); }

Figura 11.A - Primeira parte do programa exemplo 1 – desenha cubo vermelho

//Programa Principal int main(void) { //Define do modo de operacao da GLUT glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB); //Especifica o tamanho inicial em pixels da janela GLUT glutInitWindowSize(400,400); //Cria a janela passando como argumento o título da mesma glutCreateWindow("Primeiro Programa"); //Registra a funcao callback de redesenho da Janela de visualização glutDisplayFunc(Desenha); //Registra a funcao callback para tratamento das teclas ASCII glutKeyboardFunc(Teclado); //Chama a funcao responsavel por fazer as inicializações Inicializa(); //Inicia o processamento e aguarda interações do usuário glutMainLoop(); return 0; }

Figura 11.B - Continuação do programa exemplo 1 – desenha cubo vermelho

Figura 12 - Execução do Exemplo 1

2.2 A AUTOMAÇÃO E A TECNOLOGIA COMPUTACIONAL

Sempre houve dificuldade em representar adequadamente projetos de engenharia. Apesar das tecnologias emergentes ainda não serem utilizadas plenamente, a computação gráfica vem revolucionando na forma de representação de um projeto (VENETIANER, 1988). Decodificar todas as informações a partir de representações bidimensionais é uma tarefa que exige clareza, habilidade do autor do projeto, bem como conhecimento técnico, imaginação e criatividade (ANAND, 1993). A Automação Industrial segundo Bennati (1990); Natale (2000) é uma área de tecnologia multidisciplinar, refere-se aos processos contínuos e discretos e exige conhecimento de áreas básicas, tecnológicas e complementares, para tanto, faz-se necessário a realização de um projeto minucioso uma vez que esta área visa o aumento da produtividade, eficiência e segurança, envolvendo todas as atividades de transformação de trabalho que eram desempenhados pelo homem em tarefas executadas pelo computador. Muitas pessoas acham que o processo de automatizar inclui todos os aperfeiçoamentos tecnológicos desde a criação de ferramentas. Já outros relacionam com as formas mais modernas e atuais (PENTEADO; GASPAR; DI´POLITO, 1996). Pode-se encontrar uma definição mais ampla das palavras de um líder da União dos Trabalhadores das Usinas Siderúrgicas Americanas, que disse “Automação é a substituição do operário pela máquina”. Já um outro especialista disse que ela é “uma palavra criada recentemente para descrever um processo antigo”. A automação é, realmente, apenas uma fase no nosso contínuo progresso tecnológico. Inicialmente, os processos produtivos eram realizados intensivamente através da força da mão-de-obra. A produção possuía estágios em que as pessoas sempre desempenhavam as mesmas funções, especializando-se numa etapa da produção ou numa determinada tarefa. Iniciando assim a produção seriada (VENETIANER, 1988). O termo automatização se espalhou desde a construção das primeiras máquinas e se consolidou com a Revolução Industrial. A automatização está ligada a idéia de movimento mecânico repetitivo e automático, reproduzindo a ação através da mecanização. A automação é um conjunto de técnicas que possibilitam a

construção de sistemas ativos que atuam eficientemente com base nas informações recebidas do meio em que atuarão (PENTEADO; GASPAR; DI´POLITO, 1996). Pode-se dizer que a Automação forma um conjunto de procedimentos, sistema de informação e equipamentos que desempenham tarefas produtivas automaticamente, com a mínima interferência humana (NATALE, 2000). Com um mínimo de esforço humano, podem ser geradas renderizações (processos de obtenção de imagens digitais) e perspectivas (NATALE, 2000). O nível de flexibilidade do sistema é bem maior, pois está associado ao conceito de software, que proporciona ao sistema automatizado a possibilidade de mudar totalmente seu comportamento para produzir diferentes resultados (PENTEADO; GASPAR; DI´POLITO, 1996). Os modelos gerados por computador trazem como um dos pontos chave o realismo,

pela

representação

elementos

arquitetônicos

escala,

tridimensionalidade e simulação de efeitos luminosos e texturas nas superfícies e volumes (HARTMANIS; LIN, 1992). Segundo Natale (2000), os processos, que são implementados pelos procedimentos automatizados, podem ser classificados em três categorias: Processos Contínuos (produção em fluxo contínuo, em que as variáveis são analógicas, como nas indústrias siderúrgicas, químicas e etc.); Processos de Manufatura (produção em fluxo discreto, tendo origem industrial com utilização intensiva de mão de obra, a exemplo da indústria automobilística) e Processos de Serviço (em que o produto final é um serviço, a exemplo da indústria financeira, comércio e engenharia). Atualmente, os computadores são a base de toda a tecnologia da Automação, aplicados em praticamente todas as áreas do conhecimento e da atividade humana (PENTEADO; GASPAR; DI´POLITO, 1996). Por exemplo, um caixa 24 horas de um banco, em que o cliente, para verificar um simples extrato, é obrigado a interagir com um computador. Passando o cartão de cliente do respectivo banco e informando a senha e em alguns segundos obtêm-se o extrato bancário impresso. A parte mais visível da automação atual está ligada à robótica e também é utilizada em indústrias petroquímicas, químicas e farmacêuticas, com o uso de transmissores de pressão, vazão, temperatura e outras variáveis necessárias para um SDCD (Sistema Digital de Controle Distribuído) ou CLP (Controlador Lógico

Programável, dispositivos de desenvolvimento e alteração da lógica para acionamento das saídas em função das entradas de informação). Os principais objetivos da Automação Industrial é a produtividade, qualidade e segurança em um processo. Todas as informações dos sensores são concentradas em um controlador programável, em que os estados dos atuadores são definidos por um programa em memória. Atualmente, as funções executadas no controlador programável têm uma tendência a serem migradas para instrumentos de campo inteligente. Segundo Penteado; Gaspar; Di´Polito (1996), a maior parte dos sistemas modernos de Automação, a exemplo dos das industrias automobilísticas e petroquímicas e de supermercados, é muito complexa e exige muitos ciclos de realimentação. Sendo um sistema de Automação Industrial composto por cinco elementos: O primeiro elemento, o acionamento, proporciona ao sistema a energia para atingir a um determinado objetivo, através de atuadores, como por exemplo, motores elétricos, pistões hidráulicos dentre outros, os quais realização a ação. O segundo elemento, o sensoriamento, que através de sensores, mede o desempenho do sistema de automação ou alguma particularidade de algum componente, como por exemplo termopares para medir temperatura e encoders para medir velocidade. O terceiro elemento, controle, usa a informação fornecida pelos sensores para regular o acionamento, a exemplo de um controlador de fluxo que abre ou fecha uma válvula, para manter o nível de água num reservatório. Até um robô necessita de um controlador, para acionar o motor elétrico que o movimenta. O quarto elemento, o comparador ou elemento de decisão, faz a comparação dos valores recebidos com os valores pré-estabelecidos e decide quando atuará no sistema, a exemplo dos termostatos e programas de computadores. O quinto elemento, ou seja, os programas: possuem as informações do processo e possibilitam o controle das interações entre os componentes do sistema (PENTEADO;

GASPAR;

DI´POLITO,

1996;

HARTMANIS;

LIN,

1992).

Relembrando que tais elementos constituem um sistema de Automação Industrial, isto é, há outros sistemas de automação, tais como, por exemplo, caixas automáticos de bancos, em que seu sistema de automação não é constituído por todos os elementos citados acima.

2.2.1 Áreas de aplicação O desenvolvimento de elementos sensores cada vez mais poderosos e o baixo custo do hardware computacional vêm possibilitando aplicar a automação numa vasta gama de equipamentos e sistemas, tais como produtos de consumo, videocassetes, televisores e microcomputadores, carros com sistemas de injeção micro processada que aumentam o desempenho e reduzem o consumo de combustível, indústrias mecânicas, robôs controlados por computador, bancos, caixas automáticos, chaveamento de chamadas telefônicas, comunicações via satélite, telefonia celular, correios, controle de tráfego de veículos, sistemas de radar, pilotos automáticos, sistemas automáticos de segurança e também na área de Medicina, diagnóstico e exames. Com o surgimento de sensores cada vez mais poderosos e de baixo custo de hardware, possibilita-se cada vez mais a aplicação da automação nos mais variados equipamentos e sistemas, tais como produtos de consumo, eletroeletrônicos, como videocassetes, televisores e microcomputadores, indústrias mecânicas, robôs controlados por computador, CAD/CAM (que integra ambientes de projeto e manufatura), bancos, caixas automáticos, chaveamento de chamadas telefônicas, comunicação via satélite, telefonia celular, correios, transportes controle de tráfego de veículos, sistemas de radar, pilotos automáticos, sistemas automáticos de segurança, medicina e diagnóstico e exames (PENTEADO; GASPAR; DI´POLITO, 1996; HARTMANIS; LIN, 1992). Apesar dos benefícios, o aumento da automação vem causando também sérios problemas para os trabalhadores, como o aumento do nível de desemprego, principalmente nas áreas em que atuam profissionais de baixo nível de qualificação, pelo fato de que a experiência de um trabalhador se torna rapidamente obsoleta, muitos empregos que eram importantes estão se extinguindo, o que vem ocorrendo com as

telefonistas, perfeitamente

substituíveis por centrais

telefonia

automáticas. Outros problemas também podem ser observados como o aumento das ausências no trabalho, falta de coleguismo, alcoolismo ou consumo de drogas, que alteram o comportamento dos indivíduos no ambiente de trabalho. De certa forma, esse processo de alienação deriva do sentimento de submissão do trabalhador à máquina, da falta de desafios.

Ainda segundo Penteado; Gaspar; Di´Polito (1996), automação, apesar de trazer inúmeros benefícios, também vem causando problemas aos trabalhadores, tais como o aumento do desemprego, principalmente nas ares que trabalham os profissionais de baixo nível de qualificação; a experiência do trabalhador torna-se obsoleta rapidamente; atividades que antes eram importantes e desenvolvidas por pessoas estão se extinguindo, como a de telefonista que pode ser substituída por centrais automáticas e um sentimento de submissão do trabalhador à máquina, ocasionando ausências no trabalho, falta de coleguismo e consumo de álcool, alterando o comportamento dos indivíduos no ambiente de trabalho. Esses problemas, no entanto, podem ser solucionados com programas contínuos de aprendizagem e reciclagem de trabalhadores para novas funções. Além disso, as indústrias de computadores, máquinas automatizadas e serviços vêm criando um número de empregos igual ou superior àqueles que foram eliminados no setor produtivo. No entanto, esses problemas podem ser solucionados com programas contínuos de aprendizagem e reciclagem de trabalhadores para funções novas. E também as indústrias de máquinas automatizadas e computadores vêm criando um número até maior de empregos dos que foram eliminados. 2.2.2 A Importância da Automação É observado que o homem mecaniza atividades manuais desde a pré-história, em que invenções como a roda, moinhos movidos por vento ou força animal mostram o interesse do homem em poupar seus esforços. Enquanto a mecanização é a simples substituição do esforço humano através da utilização de máquinas para a realização de um trabalho, a Automação pode realizar um trabalho através de máquinas controladas automaticamente. Pela necessidade do aumento na produção e produtividade, foram surgindo inovações tecnológicas, as quais traziam máquinas modernas que produziam com maior precisão e rapidez, também traziam fontes alternativas de energia, tais como o vapor. No início do século XX, surgiram os primeiros sistemas inteiramente automáticos, contando com computadores, servomecanismos e controladores programáveis. A Automação aplicada nos mais variados setores da atividade humana trouxe muitos benefícios à sociedade, pois ela reduz custos e aumenta a produtividade do trabalho. Tal aumento proporciona maior tempo livre e melhores

salários para a maior parte dos trabalhadores. O quadro 3 a seguir indica por que a Automação mostra-se tão expressiva a cada dia.

É um processo que traz uma constante evolução tecnológica Valoriza o ser humano, pois o libera da execução de tarefas repetitivas e entediantes, até mesmo de trabalhos com situação insalubre e de risco Aumenta a qualidade de vida da sociedade, trazendo conforto e maior integração Proporciona um maior enriquecimento devido ao baixo custo do produto, pois traz uma baixa manutenção, rapidez, precisão na execução das tarefas e aumento da produtividade num curto período de tempo Traz um aumento na produção e na continuidade operacional, melhorando a qualidade Proporciona um forte apelo de marketing, devido ao mercado muito competitivo Cria empregos diretos e indiretos, também traz novos empregos encarregados do desenvolvimento, supervisão e manutenção de sistemas Visa melhorar cada vez mais a qualidade do produto e consequentemente, a satisfação do cliente Quadro 3 – Vantagens da Automação Fonte adaptada: Penteado (1996)

2.3 SISTEMAS SUPERVISÓRIOS Também conhecidos como SCADA (Supervisory Control and Data Aquisition), os sistemas supervisórios, permitem a monitoração e rastreamento de informações de um processo de produção ou uma instalação física (PEREIRA; PARDI JUNIOR, 2003). As informações são colhidas com a utilização de dispositivos de coleta de dados e posteriormente manipuladas, analisadas, armazenadas para depois ser apresentadas ao usuário (PEREIRA; PARDI JUNIOR, 2003; CURY; QUEIROZ; SANTOS, 2001). Os primeiros sistemas SCADA utilizavam painéis com medidores, lâmpadas e gráficos lineares. Operavam-se manualmente vários botões para controlar a supervisão (BAILEY; WRIGHT, 2003). Estes dispositivos ainda são utilizados como controle supervisório e aquisição de dados de fábricas e algumas indústrias de energia. A figura 13, a seguir, demonstra um sistema com painel e sensores.

Figura 13 – Sistema com painel e sensores Fonte: (BAILEY; WRIGHT, 2003, p.1 ).

Inicialmente, os processos industriais modernos e de fabricação, indústrias de mineração e de segurança sempre necessitavam da conexão dos equipamentos a sistemas separados pela distância, podendo a mesma ser apenas alguns metros como milhares de quilômetros. Utilizava-se então a telemetria, informando o estado corrente do processo industrial sem nenhuma interface aplicacional com o usuário, monitorando sinais de medidas e estados dos dispositivos através de um painel com lâmpadas e indicadores e utilizando-se da lógica de contatos de relé (BAILEY; WRIGHT, 2003). Com o surgimento da CPU e outros dispositivos eletrônicos, os fabricantes incorporaram a eletrônica digital em seus equipamentos de lógica de contatos de relé. Com o surgimento do CLP, também surgiu a necessidade de monitoração e controle de maior número de dispositivos. Com a distribuição dos CLPs, os sistemas tornaram-se mais inteligentes e baratos e ainda é um dos sistemas de controle mais utilizados na indústria. Os CLPs são utilizados como apresentados na figura 14, a seguir.

Figura 14 – Utilização de CLPs Fonte: (BAILEY; WRIGHT, 2003, p.3).

Os sistemas SCADA representam pontos de entrada e saída de dados do processo controlado através da identificação de tags, que são todas as variáveis numéricas ou alfanuméricas da aplicação (CURY; QUEIROZ; SANTOS, 2001). Podendo assim executar funções computacionais (operações lógicas, matemáticas, com vetores etc.). Os dados apresentados ao usuário são coletados com base nos valores das tags, que em processos reais podem ser exemplificados como valores de temperatura, nível e vazão, proporcionando uma ligação entre controlador e sistema (CURY; QUEIROZ; SANTOS, 2001; PEREIRA; PARDI JUNIOR, 2003). O software (programa) conhecido como supervisório, fornece a visualização de qualquer processo industrial ou comercial, através de telas gráficas. O trabalho do projetista consiste em elaborar telas gráficas de acordo com o processo que será controlado, dependendo também dos comandos e a indicação das operações (CURY; QUEIROZ; SANTOS, 2001). Cada vez mais modernos, alguns sistemas supervisórios adotaram a utilização de rede de comunicação, que é a plataforma na qual as informações serão transmitidas dos CLPs para o sistema SCADA, dependendo dos requisitos do sistema e da distância, pode ser montado através de cabos Ethernet, fibras ópticas, linhas dial-up, modems dentre outros (SILVA; SALVADOR, 2005). As principais unidades dos sistemas SCADA são as estações de monitoração central, as quais são responsáveis pela coleta de informações gerada pelas estações remotas, e devem agir de acordo com os eventos detectados. Tais estações podem consistir em um único computador, ou distribuídas por uma rede de computadores, que permitirá um compartilhamento das informações coletadas. Este sistema é retratado na figura 15, a seguir.

Figura 15 – Sistema de supervisão e controle Fonte: (SILVA; SALVADOR, 2005, p. 3).

Atualmente, são utilizadas tecnologias de computação e comunicação em sistemas de automação industrial, para automatizar a monitoração e controle dos processos industriais, possibilitando a coleta de dados em ambientes mais completos e distantes geograficamente, e com interfaces mais amigáveis para o operador, utilizando-se de recursos gráficos e conteúdo multimídia (SILVA; SALVADOR, 2004). As necessidades atuais exigem cada vez mais o aumento da produtividade, flexibilidade e redução de custos, levando o mercado a se organizar de forma a atender tais exigências (MAIA, 1998). Os profissionais estão se adequando a várias ocupações no mercado de trabalho, para atenderem às exigências do cliente, buscando conhecimento e maior variedade de produção (MAIA, 1998). Uma importante contribuição dos sistemas de Automação Industrial é a conexão do sistema de supervisão e controle com sistemas corporativos de administração de empresas. Permitindo o compartilhamento de dados importantes das operações diárias, proporcionando maior agilidade no processo de decisão e maior confiabilidade dos dados que suportam as decisões dentro da empresa (JURIZATO; PEREIRA, 2003). Atualmente existe uma grande quantidade de programas supervisórios criados por várias empresas de tecnologia, muitos deles nacionais, com protocolos de comunicação e drivers de obtenção de dados desenvolvidos, especialmente para CLPs de origem nacional (JURIZATO; PEREIRA, 2003). Sendo que a maioria deles contém ferramentas pré-definidas para a criação de softwares de supervisão, em que o usuário vai montando seu próprio sistema. Pode-ser citar entre os mais utilizados hoje em dia o: E3 e Elipse da Elipse Software, iFix da GE, InTouch da Wonderware, WinCC da Siemens e outras. Dentre estes citados, pode-se fazer uma breve descrição sobre a Elipse Software, que é uma das maiores desenvolvedoras de software para automação do Brasil e vem ampliando sua participação no mercado externo em países como a Alemanha, Estados Unidos e outros. A Elipse Software possui importantes clientes como o Banco Itaú, Elektro, Brasil Telecom, Nestlé e outros. A Elipse Software possui alguns softwares para sistemas supervisórios tais como o Elipse, E3 e Elipse SCADA. O E3 é composto de servidores, regras de aplicação, estações clientes locais e pela Internet, no qual é montado o sistema supervisório específico a cada cliente. Exemplos de aplicação do E3 podem ser mostrados nas figuras 16 e 17, a seguir.

Figura 16 – Aplicação de exemplo do E3: dosagem de substâncias Fonte: (ELIPSE, 2007).

Figura 17 – Edição de telas no E3 Studio, Aplicação de tratamento térmico de chapas Fonte: (ELIPSE, 2007).

A GE, que é uma grande empresa internacional de sistemas SCADA e interfaces de supervisão possui vários softwares para sistemas supervisórios, como o iFIX, que também consiste em ferramentas para que se possibilite a criação de sistemas supervisórios específicos. A versão atual do iFIX é a 4.5, que traz inovações gráficas e melhor performance. Pode ser demonstrado a interface do iFIX versão 3.0, na figura 18, a seguir.

Figura 18 – Interface do iFIX 3.0 Fonte: (SKUNKSWORKS, 2007).

2.4 VISUALIZAÇÃO E INTERFACE GRÁFICA A visualização pode ser conceituada, segundo Srasko (1997), como o uso de imagens para representação de informação significativa. A mesma possui muitos ramos, tais como a Visualização Científica, de Informação, Geográfica, de Negócios, Estatística, de Processo e Visualização de Software. Todos os tipos de visualização possuem o mesmo objetivo de transformar o dado em uma representação visual útil que possa trazer ao observador humano um melhor entendimento. Nos dias atuais, esta transformação é feita através de recursos gráficos gerados por computador. A Visualização de Informação, de acordo com Card et al. (1999), é a utilização da representação visual, interativa e suportada por computador, de dados abstratos de forma a ampliar a percepção. A representação visual do dado abstrato auxilia os indivíduos a enxergarem um fenômeno no dado, através da percepção para diminuir o esforço cognitivo. Nos anos 50, surgiu a idéia da computação gráfica interativa: forma de entrada de dados por meio de símbolos gráficos com respostas em tempo real. O MIT produziu figuras simples por meio da interface de tubo de raios catódicos (idêntico ao tubo de imagem de um televisor) com um computador. Em 1959, a GM começou a explorar a computação gráfica.

A década de 1960 foi o período mais crítico das pesquisas na área de computação gráfica interativa. Na época, o grande passo da pesquisa foi o desenvolvimento do sistema sketchpad, que tornou possível criar desenhos e alterações de objetos de maneira interativa, num tubo de raios catódicos. No início dos anos 60, o termo CAD (do inglês Computer Aided Design ou “Projeto Auxiliado por Computador”) começou a ser utilizado para indicar os sistemas gráficos orientados para projetos. Hoje em dia, a computação gráfica é amplamente utilizada como forma de representação visual das informações. Porém, a computação gráfica é um objeto de estudo e pesquisa desde os anos 50, em que houve o surgimento da idéia da computação gráfica interativa, em que a forma de entrada de dados era por meio de símbolos gráficos e traziam respostas em tempo real. O MIT (Instituto Tecnológico de Massachusetts), que é um dos líderes mundiais em ciência e tecnologia, desenvolveu uma interface de tubo de raios catódicos, idênticos ao tubo de imagem de um televisor, com um computador, produzindo figuras simples. Em 1959, a GM iniciou a exploração na computação gráfica. Nos anos 70, as pesquisas desenvolvidas na década anterior começaram a dar frutos. Setores governamentais e industriais passaram a reconhecer a importância da computação gráfica como forma de aumentar a produtividade. Na década de 1980, as pesquisas visaram à integração e/ou automatização dos diversos elementos de projeto e manufatura com o objetivo de criar a fábrica do futuro. O foco das pesquisas foi expandir os sistemas CAD/CAM (Projeto e Manufatura Auxiliados por Computador). Desenvolveu-se também o modelamento geométrico tridimensional com mais aplicações de engenharia (CAE – Engenharia Auxiliada por Computador). Alguns exemplos dessas aplicações são a análise e simulação de mecanismos, o projeto e análise de injeção de moldes e a aplicação do método dos elementos finitos. Nos anos 60, surgiu o termo CAD (Computer Aided Desgin ou Projeto Auxiliado por Computador), utilizado para identificar sistemas gráficos orientados para projetos. Nos anos 70 e a partir da década de 80, surgiu uma maior importância na computação gráfica, em que as pesquisas começaram a visar à integração e/ou automatização de diversos elementos de projeto e manufatura, objetivando a criação da fábrica do futuro. As pesquisas tinham como foco a expansão dos sistemas CAD/CAM (Projeto e Manufatura Auxiliados por Computador), desenvolvendo-se

também a modelagem geométrica tridimensional com mais aplicações de engenharia (CAE – Engenharia Auxiliada por Computador). Pode-se citar como exemplo destas aplicações a analise e simulação de mecanismos, bem como projeto e análise de injeção de moldes e aplicação do método dos elementos finitos. As possibilidades de construção das telas que servem como interface homem-máquina são inúmeras, sua montagem depende, basicamente, da visão do processo do programador. As telas gráficas ilustram o processo com seus parâmetros e variáveis e contêm, também, alguns

elementos lógicos como botões de liga/desliga,

potenciômetros deslizantes, caixas de valores de set points entre outros objetos. Com a constante evolução da computação gráfica e dos hardwares capazes de realizá-la, é possível gerar gráficos cada vez mais realistas e complexos em diversos

tipos

aplicações.

A interface homem-máquina

traz

inúmeras

possibilidades na construção de telas, as quais ilustram o processo com parâmetros, variáveis e outros objetos tais como elementos lógicos como botões liga/desliga, potenciômetros deslizantes e caixas de valores de set points. A montagem de tais telas depende da visão do processo do programador.

2.4.1 Visualização em sistemas supervisórios Sabe-se que em qualquer sistema supervisório, faz-se necessária uma interface bem definida e de fácil entendimento, para isso, é interessante que se faça um breve estudo sobre a aplicação de técnicas de computação gráfica, ou seja, definir a visualização das informações. Segundo Stasko (1997), visualização é o uso de imagens para representação de informação significativa. No processo de visualização, é de grande importância determinar qual técnica será utilizada na aplicação, dependo do tipo de informação que o sistema trabalhará e as tarefas que serão realizadas pelo usuário. Uma técnica de visualização baseia-se numa representação visual e mecanismos de interação que permitem ao usuário a manipulação desta representação, para que o mesmo compreenda os dados que serão representados. O nível de abstração deve ser alto, pois o usuário está somente interessado na observação das características ou padrões no conjunto de dados.

A visualização proporciona ao usuário uma percepção visual para melhor análise e compreensão das informações, através da combinação da computação gráfica, interface homem-computador e manipulação de dados. Contanto, cabem aos projetistas de sistemas de visualização definir a melhor forma de representação gráfica, de fácil interpretação (FREITAS; CHUBACHI, 2001). Dentre as várias técnicas de visualização pode-se classificar, segundo Shneiderman (1996), como unidimensionais (1D), temporais, bidimensionais (2D), tridimensionais (3D) e multidimensionais (nD), nas quais figuras ou imagens representam os dados para uma visão geral ou detalhada. Podem ser citados como representações visuais os gráficos de pontos, de linha e barras, bem como elementos visuais como cores ou símbolos geométricos. É observado que a maioria dos sistemas supervisórios da atualidade utilizamse da técnica de visualização em 2D, em que a imagem é constituída somente de largura e altura, medidos no plano cartesiano como coordenadas x e y. Apesar de já ser bastante eficiente a utilização desta técnica, pouco se sabe quanto à utilização da utilização da técnica de visualização em 3D em sistemas supervisórios. Sabe-se que adicionando perspectiva à imagem em 2 dimensões, cria-se uma sensação de profundidade e mais realismo à imagem, pode-se observar a diferença entre as duas técnicas na figura 19, apresentada a seguir.

Figura 19 – Objetos com medidas bi e tridimensionais Fonte: (WRIGHT JR.; LIPCHAK; HAEMEL, 2007, p. 11).

Para ter uma visão tridimensional de um objeto, é necessário vê-lo com ambos olhos ou fornecer a cada olho imagens diferentes do objeto. Observando a figura 20 a seguir, percebe-se que cada olho recebe uma imagem bidimensional, como uma fotografia exibida em cada retina. Essas duas imagens possuem leves diferenças porque estão em dois ângulos diferentes devido ao espaçamento dos

olhos (WRIGHT JR.; LIPCHAK; HAEMEL, 2007). O cérebro combina essas duas imagens levemente diferentes, produzindo uma única imagem em 3D.

Figura 20 – Vendo em três dimensões. Fonte: (WRIGHT JR.; LIPCHAK; HAEMEL, 2007).

A tela do computador mostra uma plana achatada numa superfície plana e não duas imagens com diferentes perspectivas para cada olho. Portanto, o que se pode considerar como gráficos de computação gráfica 3D é na verdade, uma aproximação do verdadeiro 3D. Esta aproximação é feita da mesma maneira que em pinturas de quadros realistas, em que é aplicada uma profundidade aparente, utilizando-se dos mesmos truques que a própria natureza fornece para as pessoas que só possuem um olho. O efeito de perspectiva é proporcionado através da aplicação de efeitos de cores, texturas, iluminação, sombreamento, trazendo à percepção ocular humana uma imagem tridimensional (WRIGHT JR.; LIPCHAK; HAEMEL, 2007). Com o passar dos anos, tais técnicas foram cada vez mais aperfeiçoadas para criar aplicativos com imagens cada vez mais realistas. A OpenGL traz vantagens quanto à visualização tridimensional devido a sua capacidade atual de performance em gráficos 3D em tempo real, que já são utilizados em diversos tipos de aplicações, sejam de simulação, jogos, arquitetura, médicas. Se tal recurso pode ser utilizado com tamanha eficácia nestes tipos de aplicativos, se aplicado em sistemas supervisórios pode trazer uma visualização quase real, como se o operador estivesse, de fato, observando aos eventos ocorridos com o sistema.

3 METODOLOGIA Uma pesquisa pode ser definida como um procedimento racional e sistemático que tem como objetivo proporcionar respostas aos problemas que são propostos (GIL, 1996, p. 19). As características deste trabalho de pesquisa podem ser classificadas, no ponto de vista da sua natureza como Pesquisa Aplicada, na qual o resultado tem aplicação prática, trazendo solução de problema específico, isto é, trará uma devida utilidade além do próprio conhecimento. Do ponto de vista da forma de abordagem (SILVA; MENEZES, 2001, p. 20), esta é uma Pesquisa Qualitativa, de caráter descritivo, pois há uma relação entre o mundo real e o sujeito, em que os dados são analisados indutivamente pelo pesquisador e não foi necessário o uso de métodos e técnicas estatísticas. Do ponto de vista do procedimento técnico, esta é uma Pesquisa Experimental, na qual envolveu um experimento prático e foi observado se o resultado foi satisfatório. Do ponto de vista do objetivo, esta é uma Pesquisa Exploratória, na qual foi estudado um determinado assunto, ainda pouco examinado, que é a aplicação do OpenGL em sistemas supervisórios. Foi necessária uma aproximação do pesquisador com este objeto de estudo para que o mesmo se familiarize com tal objeto, bem como um levantamento bibliográfico acerca do assunto. Para esta pesquisa foi utilizado o Método Indutivo, no qual o conhecimento foi fundamentado na experiência, observando casos da realidade concreta (GIL, 1999; LAKATOS; MARCONI, 1993). Este trabalho foi desenvolvido em três etapas distintas, em que a primeira foi a elaboração do referencial teórico, a segunda foi o desenvolvimento do projeto e a terceira etapa constituiu na identificação de se realmente a implantação do OpenGL é eficaz e viável. Tal assunto é de interesse do pesquisador, que se identificou com a disciplina Automação Industrial, a qual abordou o tema de interface gráfica nos processos automatizados, que foi um dos focos principais do pesquisador, que buscou maior estudo acerca deste assunto. A preparação do projeto foi realizada inicialmente em laboratórios. Os instrumentos utilizados para a elaboração do projeto são compostos por programa compilador da linguagem C++, o DEV-C++ na versão 4.9.9.2, em que foi instalada a biblioteca do OpenGL, a Glut, para a compilação dos códigos que foram utilizados. Foi estudado a aplicação da biblioteca gráfica do OpenGL com a utilização da

linguagem em C++, que foi aplicado em projetos de automação industrial feitos durante as aulas da matéria de mesmo nome. Tais projetos, já implementados, utilizavam também a linguagem C++, com o programa compilador Turbo C, baseando-se na visualização 2D e com poucos recursos de efeitos visuais. Para o objetivo final, foi elaborado um hardware adequado, o qual é composto de sensores e atuadores, sendo ligado através de porta USB ao computador. O programa foi desenvolvido de acordo com a estrutura e funcionamento do hardware e é capaz de comandá-lo e supervisioná-lo. Através de testes foi verificado se realmente a utilização do OpenGL em automação é viável.

4 DESENVOLVIMENTO DO PROJETO Pode-se definir um processo de desenvolvimento de software como um grupo de atividades ordenadas em partes, que visa à obtenção de um produto de software (WIKIPÉDIA, 2008). Em computação, é a transformação da necessidade de um usuário em produto de software através da elaboração e implementação de um sistema computacional, em que são aplicados processos da engenharia de software combinados com as necessidades do produto para o desenvolvimento do software (AMBLER, 1998). O objetivo deste projeto é mostrar a viabilidade da utilização do OpenGL como interface gráfica de visualização para processos automatizados. O desenvolvimento do mesmo foi dividido em duas etapas: a primeira é o desenvolvimento de um hardware adequado para ser utilizado com o software, a segunda etapa consiste na criação do software que controlará o hardware desenvolvido.

4.1 ANÁLISE DE REQUISITOS DO PROJETO A primeira fase do desenvolvimento de um software consiste na análise de requisitos de software, na qual o analista reúne-se com clientes e/ou os usuários do software para ter conhecimento das funcionalidades do sistema que será desenvolvido (BOOCH, 1994). Sabe-se que é nesta fase que ocorrem a maior parte dos erros devido a falta de clareza dos clientes ou usuários quanto às funcionalidades que o software terá. O software desenvolvido teve como pretensão a visualização e controle de um processo automatizado, o qual informa ao usuário de forma tridimensional e realista o processo em execução, fornecendo infinitas formas de visualização e ângulos de visão. O hardware desenvolvido tem como desempenho fundamental a seleção de objetos de acordo com o tamanho, o qual identificará os objetos e faz a mensuração dos mesmos, para posteriormente aceitá-los ou rejeitá-los. O hardware rejeitará os objetos de tamanho especificado pelo usuário. O software tem como função a visualização de tal processo em tempo real e de forma tridimensional, informando ao

usuário cada momento da execução. Assim, objetiva-se que o mesmo realize todas as funcionalidades citadas de forma eficiente e de fácil interpretação. Para o desenvolvimento do software, torna-se necessário em primeiro momento, a criação de um hardware que será usado em conjunto com o software. 4.1.1 Descrição do processo O processo é basicamente dividido em 7 etapas, as quais são simuladas tridimensionalmente pelo software, são descritas detalhadamente a seguir:

Etapa 1. O usuário informa ao software o tamanho dos objetos que serão rejeitados pelo hardware, uma variável do software armazenará o valor escolhido pelo usuário para comparar posteriormente com os objetos medidos ao longo do processo. O usuário inicia o processo com um clique do mouse em um botão virtual no software.

Figura 21 – Etapa 1 do processo

Etapa 2. Os objetos são empilhados verticalmente em um reservatório, em que vão caindo à medida que são empurradas pelo empurrador (controlado pelo software). O objeto é empurrado para a esteira número um, a qual possui um sensor infravermelho de presença em seu início que irá identificar o objeto no início do processo, para informar ao software.

Figura 22 – Etapa 2 do processo

Etapa 3. O objeto é medido com uma haste conectada a um potenciômetro, que de acordo com a rotação referente à altura do objeto. O potenciômetro enviará um valor analógico (em volts), o qual será convertido em digital através de um conversor digital-analógico. O valor convertido em bits é enviado ao software que, de acordo com o valor em bits recebido, calculará a altura em centímetros do objeto medido e armazenará o valor recebido em uma variável.

Figura 23 – Etapa 3 do processo Etapa 4. O objeto, já medido, segue adiante na esteira superior, e é identificado por um sensor infravermelho que se encontra no fim da mesma, informando ao software a presença do objeto. O software aciona o atuador empurrador, que empurrará o objeto para deslizar por uma rampa até a segunda esteira, inferior.

Figura 24 – Etapa 4 do processo

Etapa 5. O objeto desliza pela rampa e chega na segunda esteira, a qual possui em seu início, um sensor infravermelho de presença, identificando o objeto e informando ao software. O objeto segue adiante para a próxima etapa.

Figura 25 – Etapa 5 do processo

Etapa 6. A segunda esteira dispõe de outro sensor infravermelho, que quando identifica o objeto, informa ao software. O software, que armazenou anteriormente o valor do tamanho do objeto medido, fará uma comparação entre o valor informado pelo usuário referente a objetos rejeitáveis com o valor do objeto detectado. Se o valor for diferente, o objeto seguirá adiante para a etapa final.

Figura 26 – Etapa 6 do processo

Se acaso o valor referente ao tamanho do objeto for igual ao tamanho rejeitável especificado pelo usuário, o software acionará um dispersador de objetos rejeitáveis, empurrando-o para fora da esteira. A cada objeto rejeitado, uma variável correspondente ao tamanho rejeitado será incrementada, e será apresentado na tela o número de objetos rejeitados referentes a cada tamanho.

Figura 27 – Etapa 6 do processo

Etapa 7. Quando o tamanho do objeto medido é diferente do especificado pelo usuário, o sistema aceita o objeto, ele segue adiante, chegando ao fim do processo de seleção. Sendo que este processo pode, teoricamente, fazer parte de vários processos separados, dando continuidade a outros seguintes. A cada objeto aceito, uma variável correspondente ao tamanho aceito será incrementada, e será apresentado na tela o número de objetos aceitos referentes a cada tamanho.

Figura 28 – Etapa 7 do processo

4.2 ESPECIFICAÇÃO

A especificação é a descrição precisa do software que será escrito e do hardware que será desenvolvido, preferencialmente, de forma matematicamente rigorosa (BOOCH, 1994). Isto é, a definição do que se espera que o software faça. O software desenvolvido foi escrito em linguagem C++, integrada à biblioteca OpenGL, responsável pela interface gráfica de alto nível para acesso ao hardware. Este software será capaz de monitorar o processo em execução, mostrando a exata situação na tela do computador em terceira dimensão. O mesmo fornecerá ao usuário a liberdade para explorar visualmente cada parte do hardware virtual em execução sincronizada com o hardware real. Para que fosse atendida a necessidade deste software, foi desenvolvido um hardware (em forma de maquete), o qual tem funções de sensoriamento e atuação que serão monitorados pelo software. O hardware tem como função principal a seleção de objetos de acordo com o tamanho especificado pelo usuário. Ele foi constituído de sensores e atuadores que enviará os dados de entrada para o computador, o qual fará o tratamento dos dados e enviará o comando para o funcionamento dos atuadores. A figura 29 a seguir demonstra a idealização do projeto, bem como a localização dos sensores e atuadores que o compõem.

Figura 29 – Visão superior do projeto do hardware

Os sensores, localizados em locais estratégicos informarão ao programa a localização do objeto detectado,

para que o

mesmo

seja

representado

tridimensionalmente no software na posição referente a real. A mensuração dos objetos será realizada de forma analógica, para que os dados enviados do medidor analógico sejam convertidos em dados digitais para serem recebidos pelo software. Além de esteiras como atuadores, o hardware também consistirá de atuadores de dispersão, os quais serão responsáveis pelo deslocamento do objeto para a esteira inicial, de uma esteira para outra, e para fora dela no caso do objeto rejeitado.

4.3 ARQUITETURA DO HARDWARE O projeto do hardware confeccionado é composto de 5 sensores infravermelhos, 3 atuadores, 2 esteiras e 1 medidor ligado a um potenciômetro. A estrutura foi elaborada anteriormente a sua montagem, incluindo medidas e posições. A figura 30.A a seguir apresenta o hardware elaborado, a identificação dos seus elementos principais e suas dimensões. A sua estrutura física foi montada com material derivado da madeira chamado MDF (Fibra de Média Densidade). Cada esteira funciona com um motor utilizado em antenas parabólicas, de 5V. Observando a figura 30.B a seguir, pode-se observar o hardware construído e, detalhadamente, cada parte enumerada do mesmo.

Figura 30 .A – Visão em perspectiva do projeto e dimensões;

30.B – Hardware construído

Na parte identificada com o número 1 na figura 30.B, está localizada a empilhadeira de caixas, a qual armazenará um número limitado de caixas verticalmente. Abaixo da empilhadeira está instalado um empurrador giratório, ligado a um motor que ao ser acionado empurra a caixa para a esteira e conseqüentemente a próxima caixa cairá na posição a ser empurrada. No início da esteira, logo após a empilhadeira, foi colocado um sensor infravermelho para identificar a presença do objeto, informando ao software para que o mesmo reproduza esta situação na tela do computador. No empurrador giratório também foi instalado um sensor para indicar uma volta completa. Cada sensor infravermelho é composto de um emissor e um receptor, o emissor é um LED infravermelho do tipo LD 271, que também é utilizado em controles remotos. O receptor de infravermelho é ligado com um potenciômetro para ajustar a sua sensibilidade.

Figura 31 – Aspecto físico de alguns tipos de LED infravermelho Fonte: LED INFRARED (2008).

No circuito elétrico dos sensores foi utilizado um comparador de tensão, o qual é um amplificador operacional de alto ganho que compara uma tensão de entrada com uma tensão de referência. A saída será em nível alto ou baixo, dependendo se a tensão de entrada for maior ou menor do que a tensão de referência. O comparador utilizado foi o LM339 (BRAGA, 2008). Os comparadores de tensão são amplamente utilizados em alarmes, aplicações em controles, sensores e outros circuitos.

Figura 32– Características do comparador LM339 Fonte: MANGHARAM (2007, p. 1).

O esquema do circuito confeccionado para emissores e receptores foi montado com o programa Eagle Circuit Maker e encontra-se apresentato na figura 33, já o circuito elétrico está na figura 34. O mesmo foi montado com os seguintes componentes, indicados no quadro 4, a seguir.

2 CI’s 7404 1 Regulador de tensão 7805 1 Diodo 1n4004 1 LED Verde 1 LED Amarelo 6 Resistores de 10KΩ 8 Potenciômetros de 10K 8 Emissores Infravermelhos 8 Receptores Infravermelhos 2 Comparadores LM339 Quadro 4 – Componentes do circuito dos sensores

Figura 33 – Esquema do circuito dos sensores

Figura 34 – Circuito elétrico dos sensores

Na parte identificada com o número 2 na figura 30.B, está localizado o medidor de objetos, que é uma haste acrílica conectada a um potenciômetro. O potenciômetro é um componente eletrônico que possui uma resistência elétrica que pode ser ajustada. Isto é, um resistor que possui três terminais, onde a conexão central é deslizante e pode ser manipulada (WIKIPÉDIA, 2008).

Figura 35A – Um potenciômetro de uma volta; Fonte: WIKIPÉDIA (2008, p. 1).

35.B – Símbolo esquemático de um potenciômetro. Fonte: WIKIPÉDIA (2008, p. 1).

À medida que a haste de acrílico gira quando um objeto passa por ela, o potenciômetro também gira, alterando a resistência do circuito e conseqüentemente, o valor enviado para o software. Para que o computador entenda o dado enviado deste potenciômetro, é necessário que seja utilizado um conversor analógico-digital. O conversor capaz de converter grandezas analógicas em dados binários 0s e 1s utilizado neste projeto foi o ADC0804. Este conversor faz a conversão utilizando

8 bits (P PARALELA, 2008). A figura 36 e quadro 5, a seguir, mostram como fazer os cálculos de conversão para o ADC0804. Observa-se que a saída pode ter valores entre 0 a 255, com o valor binário de 8 bits, oferecendo uma possibilidade de 256 combinações diferentes.

Figura 36 – Cálculo da resolução do ADC0804 Fonte: ROGERCOM, (2008)

Volts 0,0195 0,0390 0,0585 0.0780 . . . 4,9920

Decimal 1 2 3 4 . . . 255

Binário 00000001 00000010 00000011 00000100 . . . 11111111

Quadro 5 – Tabela de conversão do ADC0804 Fonte: ROGERCOM, (2008)

Figura 37 – Características do conversor ADC0804 Fonte: ROGERCOM, (2008)

O esquema do circuito confeccionado para o conversor analógico-digital, montado com o programa Eagle Circuit Maker, encontra-se na figura 38, a seguir e o circuito elétrico, na figura 39. O mesmo foi montado com os seguintes componentes, identificados no quadro 6, a seguir.

1 7805 (Regulador de tensão) 1 ADC0804 8 Leds - Vermelhos 1 Led Verde 1 Led Amarelo 10 Resistores de 470 Ω 4 Resistores de 10 KΩ 1 Capacitor de 150 pF; 1 Capacitores de 104 pF; 2 CIs 7408 1 Diodo 1n4004 Quadro 6 – Componentes conversor analógico-digital

circuito

Figura 38 – Esquema do circuito conversor analógico-digital

Figura 39 – Circuito elétrico conversor analógico-digital

Na parte identificada com o número 3 na figura 30.B, a qual indica o final da primeira esteira, há um sensor infravermelho de presença que informará ao software que o objeto chegou ao final da primeira parte do percurso. Há também um motor conectado a uma haste de arame revestida com material plástico transparente. Através do comando enviado pelo software, assim que identificar o objeto no sensor, fará com que o motor execute um movimento circular na haste de arame que empurrará o objeto pela rampa. A parte identificada com o número 4 na figura 30.B, mostra o início da segunda esteira. Também está localizado neste local um sensor infravermelho que detectará a presença do objeto vindo da rampa. Na parte identificada com o número 5 na figura 30.B, localizado no meio da segunda esteira, há um sensor infravermelho de presença na borda da esteira, e em cima deste sensor, há um motor adaptado com engrenagem que será o “dispersador de objetos rejeitados”. Este dispersador somente será acionado, através do software, caso o objeto identificado seja rejeitável. Para o controle de todos os motores utilizados neste projeto, foi desenvolvido e confeccionado um circuito, no qual os mesmos funcionarão através de acionamento de relés. Relés são componentes eletromecânicos que podem

controlar, a partir de pequenas correntes ou tensões, circuitos externos com grandes correntes (PATSKO, 2006). Com um relé acionado por uma bateria, pode-se controlar um motor ligado em 110 ou 220 V. Nos relés, quando uma corrente circula pela sua bobina, esta gera um campo magnético que atrai um ou vários contatos, abrindo ou fechando circuitos. Quando a corrente da bobina é interrompida, o campo magnético também é interrompido, retornando os contatos à posição original. A figura 40 a seguir identifica um relé, em que o contato normalmente aberto (NA) está aberto enquanto a bobina não está energizada e se fecha quando a mesma recebe corrente. O contato normalmente fechado (NF) se abre quando a bobina recebe corrente. O contato central (C) é o contato comum quando o contato NA se fecha, estabelecendo condução com o mesmo.

Figura 40 – Desenho ilustrativo de um relé e a configuração mais comum dos contatos dos relés Fonte: Patsko (2006, p. 1).

Figura 41– Modelos de relés vendidos comercialmente Fonte: MAXWELLBOH

O esquema do circuito desenvolvido para controle de todos os motores utilizados no projeto, montado com o programa Eagle Circuit Maker, encontra-se na figura 42, a seguir e o circuito elétrico, na figura 43. O mesmo foi montado com os seguintes componentes, identificados no quadro 7, a seguir.

4 Relés de 12 V 1 Regulador de tensão 7805 1 Diodo 1n4004 4 Leds Vermelhos 1 Led Verde 1 Led Amarelo 5 Resistores de 470 Ω 5 Resistores de 2 KΩ 4 Transistores BC548 Quadro 7 – Componente do circuito dos motores

Figura 42 – Esquema do circuito de controle dos motores

Figura 43 – Circuito elétrico de controle dos motores

Por fim, na parte identificada com o número 6 na figura 30.B, estão indicados os objetos que serão utilizados no sistema, cada caixa cúbica possui um tamanho específico e uma cor definida. A caixa de 3 cm está indicada na cor azul, a de 4 cm está na cor verde, a de 5 cm na cor amarela e por fim, a de 6 cm na cor vermelha. O hardware está conectado ao computador através da porta USB, a qual será conectada através de uma placa de circuito impresso desenvolvida na Fainor, a qual possibilita a conexão de dispositivos e sensores ao computador. Esta placa possui duas portas, a porta C e B nas quais respectivamente possuem nove e cinco pinos em que o primeiro pino de cada porta corresponde ao aterramento do sistema. As portas são habilitadas através do microcontrolador Atmel AT90S2313P. O sistema utiliza praticamente todos os pinos disponíveis na placa USB, em que na porta B serão utilizados cinco pinos para as entradas de cada sensor do hardware e os três pinos restantes serão para os atuadores (dispersador, empurrador e rejeitador). A porta C é utilizada para as entradas do medidor (que utiliza o conversor analógicodigital com oito saídas) utilizando três pinos com os valores binários necessários para a mensuração dos objetos específicos do sistema. O esquema do circuito USB utilizado encontra-se a seguir.

Figura 44 â&#x20AC;&#x201C; Esquema do circuito USB

5 PROJETO DO SOFTWARE Para a construção do programa, é de importância relevante o levantamento dos requisitos do software. Também é importante a criação de modelos para que a qualidade seja garantida. A UML (Linguagem de Modelagem Unificada) oferece maior segurança e controle no desenvolvimento de um sistema, pois garante uma diminuição da complexidade do mesmo, bem como uma abstração de maior entendimento e a possibilidade de simular situações de erro e problemas de execução (MATOS, 2002). A especificação de um requisito significa compreender o que deve ser feito no sistema e o que é esperado como resultado. A UML baseia-se em um conjunto de diagramas, em que cada diagrama enfoca uma abstração ou funcionalidade diferente.

5.1 ANÁLISE DE REQUISITOS DO SOFTWARE Os requisitos representam as restrições e características do software em relação à satisfação das necessidades do usuário. Independente da tecnologia aplicada na construção é a parte mais crítica no desenvolvimento de um software (MATOS, 2002). Os requisitos dizem respeito às propriedades de um software. Um conjunto de requisitos de software define a condição que o software deve possuir para atingir os objetivos do usuário. Os requisitos podem ser classificados como funcionais, que descrevem as funcionalidades que o software deve realizar, e não-funcionais, que são as restrições e características do sistema relativas ao uso, manutenção, desempenho, interface, custo e outras (MACORATTI.NET, 2008a; 2008b).

5.1.1 Requisitos funcionais Os requisitos funcionais definem as funcionalidades do software, isto é, a descrição das funções que os usuários precisam ou desejam que o software realize (DEBONI, 2008). As funções são realizadas pelo sistema através de comandos do usuário. Os requisitos funcionais do projeto desenvolvido encontram-se a seguir.

[RF001] – Informar tamanho de objeto rejeitável Ator: Usuário Prioridade: (X) Essencial ( ) Importante ( )Desejável Entradas: Selecionar tamanho do objeto que será rejeitado pelo sistema, na tela principal. Pré-condições: O programa deve estar aberto, e usuário deve somente escolher uma das opções de tamanho de objeto para ser rejeitado. Saídas: Valor indicado pelo usuário será armazenado numa variável. Pós-condições: Usuário deve clicar no botão “Iniciar” para iniciar o processo. A variável que armazenou o valor indicado pelo usuário será comparada com o valor do objeto medido no sistema. •

Descrição do fluxo normal: 1) Inicialmente, o usuário selecionará na tela principal o tamanho de objeto rejeitável clicando numa das opções de tamanho disponíveis. 2) A opção escolhida será armazenada numa variável. Após o usuário escolher o tamanho rejeitável, deve clicar em “Iniciar” para o processo começar. 3) Assim que o processo se inicia, o objeto entra no processo e será medido o seu tamanho, o qual será armazenado em outra variável. 4) Quando o objeto medido chegar ao ponto em que se encontra o “dispersador de objetos rejeitáveis”, a valor da variável que armazenou o tamanho escolhido pelo usuário será comparado com o valor da variável que armazenou o valor do objeto medido. Se os valores forem iguais, o software acionará o dispersador que conseqüentemente empurrará o objeto rejeitado. Caso os valores sejam diferentes, o objeto será tido como aceito e continuará o processo. 5) O valor de objeto rejeitável pode ser escolhido pelo usuário a qualquer momento do processo, modificando-o como desejar.

[RF002] – Iniciar processo Ator: Usuário Prioridade: (X) Essencial ( )Importante ( )Desejável

Entradas: Clique com o botão esquerdo do mouse no botão “Iniciar” da tela principal do programa Pré-condições: O programa deve estar aberto e botão “Iniciar” da tela principal estar disponível para clique e usuário já deve ter fornecido o tamanho do objeto a ser rejeitado e usuário já deve ter escolhido tamanho de objeto rejeitável. Saídas: Processo real e virtual se inicia Pós-condições: Botão “Iniciar” estará disponível para clique após alguns segundos •

Descrição do fluxo normal: 1) Inicialmente, o usuário clica no botão “Iniciar” na tela principal do sistema, uma vez definido o tamanho dos objetos rejeitáveis. 2) O programa inicia o processo real e virtual, e o botão “Iniciar” torna-se indisponível por alguns segundos, para que haja o devido tempo entre cada objeto inserido no processo. 3) Após alguns segundos, o botão “Iniciar” torna-se disponível novamente podendo ser clicado, dando início a um novo processo.

[RF003] – Apresentar na tela objetos identificados, tamanho dos objetos medidos e movimentação dos atuadores acionados. Ator: Software Prioridade: (X) Essencial ( )Importante ( )Desejável Entradas: Valores enviados pelos sensores do hardware serão responsáveis pela simulação tridimensional do processo Pré-condições: O programa deve estar aberto e iniciado, isto é, usuário já deve ter escolhido valor de objeto rejeitável e iniciado o processo. Saídas: São exibidas na tela a animação e situação do processo. Pós-condições: Animação é constantemente atualizada de acordo com a identificação feita pelos sensores. •

Descrição do fluxo normal: 1) Com o processo iniciado, o software aciona os atuadores de acordo com a situação do processo, e com isso, simula na tela principal a movimentação do mesmo atuador virtualmente.

2) Assim que um objeto é identificado por um sensor infravermelho, o software apresenta na tela a posição que o objeto se encontra no processo. 3) Quando o objeto passa pelo medidor de tamanho, o valor medido é guardado em uma variável, será mostrada na tela a representação do tamanho medido do objeto. 4) O software permanece em constante atualização, assim, aguardando a identificação de novos objetos.

[RF004] – Enviar dados obtidos dos sensores e medidor Ator: Hardware Prioridade: (X) Essencial ( )Importante ( )Desejável Entradas: Hardware envia dados, através dos sensores infravermelho e medidor, para o software. Pré-condições: O hardware devidamente ligado e calibrado. Saídas: Tratamento de dados realizados pelo software. Pós-condições: O hardware enviará constantemente sinal dos sensores e medidor. •

Descrição do fluxo normal: 1) O hardware é ligado, calibrado e conectado ao computador. 2) Software é iniciado e aguarda instruções do usuário para iniciar o processo. 3) Quando processo é iniciado, o hardware envia sinais dos sensores e medidor para o software. 4) Software recebe os dados e realiza o tratamento dos dados.

[RF005] – Detectar objetos nos sensores de presença Ator: Software Prioridade: (X) Essencial ( )Importante ( )Desejável Entradas: Sinal enviado do hardware assim que um objeto for identificado pelo sensor infravermelho Pré-condições: O programa deve estar em funcionamento e hardware devidamente ligado e calibrado..

Saídas: Valor de saída enviado para o software. Pós-condições: Assim que objeto sair do sensor, novos objetos podem ser identificados. •

Descrição do fluxo normal: 1) Objeto que se encontra na área de percepção dos sensores infravermelhos é identificado. 2) Sensor envia valor modificado para o software, o qual entenderá como um objeto identificado no ponto em que se encontra o sensor que o detectou. 3) Software faz o tratamento e realiza as funções de acordo com o valor recebido.

[RF006] – Medir tamanho dos objetos identificados Ator: Software Prioridade: (X) Essencial ( )Importante ( )Desejável Entradas: Sinal enviado do medidor de objetos do hardware. Pré-condições: O programa deve estar em funcionamento, hardware devidamente ligado e medidor calibrado (zerado). Saídas: Valor de saída enviado para o software. Pós-condições: Assim que objeto for medido, o medidor volta à posição e valor zerado. •

Descrição do fluxo normal: 1) Objeto passa pelo medidor, e o mesmo é medido através da haste de acrílico do medidor (hardware). 2) O movimento de rotação que a haste faz com o movimento do objeto através da esteira altera o valor de entrada do tamanho. 3) Valor medido é enviado ao software e armazenado numa variável. 4) É representado na tela o objeto medido. 5) Assim que objeto é medido, medidor volta à sua posição inicial e aguarda novas medições.

[RF007] – Detectar objeto rejeitado Ator: Software Prioridade: (X) Essencial ( )Importante ( )Desejável Entradas: Sinal enviado do hardware assim que um objeto previamente medido como “rejeitável” for identificado pelo sensor infravermelho na posição do dispersador de objetos rejeitáveis. Pré-condições: O programa deve estar em funcionamento e hardware devidamente ligado e calibrado. Saídas: Software aciona o dispersador de objetos rejeitáveis e objeto é rejeitado. Pós-condições: Próximo objeto deve estar caracterizado como “rejeitável” para que o dispersador o rejeite. •

Descrição do fluxo normal: 1) Valor do objeto medido é comparado com o valor informado pelo usuário para objeto rejeitável. 2) Quando objeto aciona o sensor localizado no local onde se encontra o dispersador de objetos rejeitáveis, valores comparados são verificados. Se forem iguais, software aciona o dispersador e rejeita o objeto. 3) Situação é simulada na tela do programa. 4) Sensor do dispersador aguarda próximo objeto.

[RF008] – Acionar atuadores Ator: Software Prioridade: (X) Essencial ( )Importante ( )Desejável Entradas: Clique no botão “Iniciar” pelo usuário para dar início ao processo e acionar o atuador 1 (empurrador 1), objetos detectados por sensor infravermelho localizado no atuador 2 (empurrador 2). Pré-condições: O programa deve estar em funcionamento e hardware devidamente ligado e calibrado. Saídas: Software aciona os atuadores, reproduzindo a situação tridimensionalmente da tela principal do programa. Pós-condições: Processo é atualizado, e software aguarda novos objetos serem identificados nos sensores dos atuadores.

•

Descrição do fluxo normal: 1) Assim que programa é iniciado pelo usuário através do clique no botão “Iniciar” na tela principal, o programa aciona o empurrador 1, localizado no compartimento de objetos empilhados, e empurra o objeto na esteira. 2) Software reproduz na tela principal o movimento do empurrador 1 e caixa sendo empurrada. 3) Quando objeto é detectado no sensor localizado no empurrador 2, ao final da primeira esteira, o software aciona o empurrador 2 e objeto é empurrado pela rampa, em direção à esteira 2. 4) Software reproduz na tela principal o movimento do empurrador 2 e caixa sendo empurrada e deslizando pela rampa.

5.1.2 Requisitos não-funcionais Os requisitos não-funcionais são as qualidades do programa, diretamente ligados com a satisfação dos usuários. Podem ser descritos como requisitos nãofuncionais a usabilidade, desempenho, manutenibilidade, portabilidade e custo. Tais requisitos são geralmente de maneira informal e são de grande importância. [RNF001] – Usabilidade O sistema dever ter uma interface intuitiva e de fácil entendimento para o usuário. [RNF002] – Desempenho O sistema deve ser executado em um computador razoavelmente rápido, para que a renderização 3D ocorra de forma mais precisa e fiel. [RNF003] – Manutenibilidade O sistema não precisa ser atualizado devido às suas limitações. Porém se o hardware for modificado, o mesmo deve ser atualizado. [RNF004] – Portabilidade O sistema deve ser executado em computadores que possuam o OpenGL instalado (facilmente encontrado na internet para instalação), entrada USB para conectar o hardware e o arquivo .dll necessário (AVR309IO.DLL – fornecida pelo

desenvolvedor do projeto) para o reconhecimento do hardware na porta USB, a mesma deve estar copiada na pasta do Microsoft Windows.

5.2 MODELAGEM DA APLICAÇÃO

De acordo com a proposta básica efetuada pela OMG (Object Management Group), a modelagem pode ser indicada em cinco níveis de abstração, tais como: o Diagrama de Caso de Uso, Diagrama de Classes, Diagrama de Interação (Seqüência), Diagrama de Estado e Atividade, e por fim, a esquematização de implementação através de Diagramas de Componentes e de Implantação. 5.2.1 Diagrama de Caso de Uso Os casos de uso representam uma funcionalidade, e representam todos os requisitos de um sistema, fornecendo uma visão externa do sistema de suas interações com o mundo exterior. Os principais componentes do Modelo de Casos de Uso são: o caso de uso, o ator (entidade externa que interage com os casos de uso) e o sistema (conjunto de casos de uso). O diagrama de Caso de Uso do projeto encontra-se a seguir, na figura 45.

Figura 45 – Diagrama de Caso de Uso

5.2.2 Diagrama de Classes Diagramas de classes representam a estrutura do sistema e suas relações. As classes possuem nome, atributos e operações que realizam no sistema. Uma relação entre classes indica dependência entre as mesmas, podendo ser associações, agregações ou heranças. Tal dependência pode ser forte, como em caso de herança ou agregação, e também pode ser mais fraca, como no caso da associação. Estas relações mostram que cada classe que está relacionada contribui com o funcionamento do sistema. Pode-se dizer que Diagramas de Classes são estáticos, isto é, apenas demonstra as interações e não o que acontece quando as classes interagem. O diagrama de Classes do projeto encontra-se a seguir, na figura 46.

Figura 46

Diagrama de Classes

O diagrama de Classes descrito na figura 46 descreve as classes com seus respectivos atributos, métodos e relacionamentos. As classes descritas indicam os principais componentes do sistema, em que são divididas em: classe Menu Principal,

classe Sensores Medidor e Atuadores, classe Dispersador, classe Medidor, classe Empurrador, classe Rejeitador. A classe Menu Principal representa as alterações que o usuário provoca a partir de sua escolha no menu do software, incluindo também o acionamento do processo iniciado pelo usuário. A seguir serão descritos seus atributos e métodos, bem como a responsabilidade de cada um.

Atributos da classe Menu Principal: •

tamanho_escolhido indica o tamanho de objeto escolhido pelo usuário no menu;

•

valor_textura_menu indica o valor equivalente a textura do menu, que é modificada sempre que o usuário clica nas opções de tamanho e inicia o processo;

•

aciona é responsável pelo início do processo, que é ativado assim que usuário faz a escolha do tamanho do objeto e clica no botão “Iniciar” do menu;

•

aciona_1 é responsável pelo acionamento da textura equivalente à escolha da opção de tamanho 1 (3 cm) pelo usuário;

•

aciona_2 é responsável pelo acionamento da textura equivalente à escolha da opção de tamanho 2 (4 cm) pelo usuário;

•

aciona_3 é responsável pelo acionamento da textura equivalente à escolha da opção de tamanho 3 (5 cm) pelo usuário;

•

aciona_4 é responsável pelo acionamento da textura equivalente à escolha da opção de tamanho 4 (6 cm) pelo usuário;

•

rejeitados_3cm indica o número de objetos com 3cm rejeitados pelo sistema;

•

rejeitados_4cm indica o número de objetos com 4cm rejeitados pelo sistema;

•

rejeitados_5cm indica o número de objetos com 5cm rejeitados pelo sistema;

•

rejeitados_6cm indica o número de objetos com 6cm rejeitados pelo sistema

•

aceitos_3cm indica o número de objetos com 3cm aceitos pelo sistema;

•

aceitos_4cm indica o número de objetos com 4cm aceitos pelo sistema;

•

aceitos_5cm indica o número de objetos com 5cm aceitos pelo sistema;

•

aceitos_6cm indica o número de objetos com 6cm aceitos pelo sistema.

Método da classe Menu Principal: •

inicia_processo

é responsável pelo acionamento do dispersador e

conseqüentemente, do início do processo.

A classe Dispersador representa o funcionamento do dispersador de caixas para o sistema. Esta classe traz as atributos e métodos que são responsáveis pelo acionamento do dispersador real, bem como a animação do mesmo na tela, incluindo a animação do objeto dispersado.

Atributos da classe Dispersador: •

dispersador é responsável pela ativação das funções de acionamento do dispersador real e virtual;

•

dispersador_on é responsável pelo ligamento do dispersador real;

•

roda_dispersador é responsável pela animação do dispersador virtual;

•

bloquear permite que o acionamento das funções do dispersador sejam executadas até o fim, sem interrupções;

Métodos da classe Dispersador: •

aciona_dispersador() possui os comandos responsáveis pela animação do dispersador virtual;

•

termina_dispersador(int) é responsável pelo desligamento do dispersador real após um determinado tempo, ela é utilizada com a função glutTimerFunc, que faz parte da biblioteca OpenGL GLUT, que executa uma função após certo tempo em milisegundos;

•

aguardar(int) permite que o dispersador não seja acionado novamente por determinado tempo.

A classe Medidor representa o funcionamento do medidor de objetos do sistema, os objetos identificados e medidos. Também é responsável pelo armazenamento dos valores medidos dos objetos.

Atributos da classe Medidor: •

roda_medidor é responsável pela animação do medidor virtual, com base no movimento do medidor real quando está medindo um objeto;

•

tamanho_medido indica o valor recebido do medidor real, o qual representará o tamanho do objeto medido;

•

caixa_medidor_3cm aciona a representação virtual referente ao objeto de 3cm, a qual depende do valor do objeto medido para isto;

•

caixa_medidor_4cm aciona a representação virtual referente ao objeto de 4cm, a qual depende do valor do objeto medido para isto;

•

caixa_medidor_5cm aciona a representação virtual referente ao objeto de 5cm, a qual depende do valor do objeto medido para isto;

•

caixa_medidor_6cm aciona a representação virtual referente ao objeto de 6cm, a qual depende do valor do objeto medido para isto;

Método da classe Medidor: •

armazena_tamanho(int)

armazena

valor

recebido

pelo

atributo

tamanho_medido em uma matriz, que representará os valores de uma certa quantidade de objetos medidos. •

compara_tamanho faz a comparação entre o valor escolhido pelo usuário com o valor obtido através da medida do objeto.

A classe Sensores e Atuadores é responsável pela entrada e saída de dados do sistema. Os valores de entrada são responsáveis por todo o tratamento de informações do sistema.

Atributos da classe Sensores, Medidor e Atuadores: •

leitura1 recebe o valor enviado do medidor real, e é responsável pelo acionamento das funções que definem o tamanho e cor do objeto medido;

•

leitura2 recebe os valores enviados dos sensores do sistema, que são responsáveis pela detecção da presença dos objetos em cada fase do sistema;

•

saída envia o valor que aciona determinado atuador. Para cada atuador, um valor específico de saída deve ser executado no momento adequado.

A classe Empurrador representa o funcionamento do empurrador de objetos já identificados e medidos. Esta classe é responsável pelo acionamento do mesmo e pela a animação do objeto já medido na fase anterior.

Atributos da classe Empurrador: •

empurrador é responsável pela ativação das funções de acionamento do empurrador real e virtual;

•

empurrador_on é responsável pelo ligamento do empurrador real;

•

liga_empurrador

responsável

pelo

acionamento

animação

dispersador virtual; •

bloquear_empurrador permite que o acionamento das funções do empurrador sejam executadas até o fim, sem interrupções;

•

roda_dispersador é responsável pela animação do dispersador virtual;

Métodos da classe Empurrador: •

aciona_empurrador() possui os comandos responsáveis pela animação do empurrador virtual;

•

termina_dispersador(int) é responsável pelo desligamento do empurrador real após um determinado tempo;

•

aguardar_empurrador(int) permite que o empurrador não seja acionado novamente por determinado tempo.

A classe Rejeitador representa o funcionamento do rejeitador, a qual é invocada quando o objeto medido pelo medidor possui mesmo valor indicado pelo

usuário como valor de objeto rejeitável. Esta classe é responsável pelo acionamento do mesmo e pela a animação do objeto rejeitado.

Atributos da classe Empurrador: •

rejeitador é responsável pela ativação das funções de acionamento do rejeitador real e virtual;

•

rejeitador_on é responsável pelo ligamento do rejeitador real;

•

liga_rejeitador é responsável pelo acionamento da animação do rejeitador virtual;

•

roda_ rejeitador é responsável pela animação (rotação) da engrenagem do rejeitador virtual;

•

move_rejeitador é responsável pela animação do rejeitador;

•

bloquear_rejeitador permite que o acionamento das funções do rejeitador sejam executadas até o fim, sem interrupções;

Métodos da classe Rejeitador: •

aciona_rejeitador() possui os comandos responsáveis pela animação do rejeitador virtual;

•

termina_rejeitador(int) é responsável pelo desligamento do rejeitador real após um determinado tempo;

•

aguardar_rejeitador(int) permite que

rejeitador

não seja

acionado

novamente por determinado tempo.

5.2.3 Diagrama de Seqüência Um diagrama de seqüência é representa a seqüência de processos em uma aplicação. Ele apresenta como as mensagens entre os objetos são passadas ao longo de um tempo, para a execução de uma operação. Num diagrama de seqüência, as linhas verticais representam o tempo de vida de um objeto. As mensagens de chamada são representadas como setas cheias e as mensagens de retorno são representadas como setas tracejadas. Este diagrama é montado com

base no diagrama de Caso de Uso, em que inicialmente deve ser definido o papel do sistema (use cases) e posteriormente, deve ser definido como será realizado o papel do software (seqüência de operações). O diagrama de Seqüência encontra-se a seguir, na figura 47.

Figura 47 – Diagrama de Seqüência

5.3 FUNCIONAMENTO DO SOFTWARE Neste tópico serão apresentados os principais códigos e funções utilizados no software e todo o seu funcionamento. O código implementado para a construção das janelas, figuras tridimensionais e menu possui funções básicas do OpenGL, bem como bibliotecas auxiliares. A figura 48 abaixo traz uma parte do programa em que

são declaradas as bibliotecas utilizadas: glut.h, gl.h, glu.h (que são bibliotecas do OpenGL), stdio.h, string.h, windows.h (necessária para que o acesso do hardware à porta USB do computador seja possível), ModelType.h (Responsável pela importação de objetos 3D e texturas - Autor: Karl Berg) e glaux.h (responsável pelo uso de texturas BMP).

#include <gl/glut.h> #include<gl/glu.h> #include<gl/gl.h> #include <stdio.h> #include<string.h> #include <windows.h> #include "ModelType.h" #include "glaux.h"

Figura 48 – Declaração das bibliotecas do programa

A biblioteca ModelType.h, utilizada para importar objetos 3D gerados por programas como o 3D Studio Max ou Blender 3D, deve estar incluída na mesma pasta do projeto do programa implementado, bem como o arquivo ModelType.cpp. Para declarar uma variável (global) para acessar esta biblioteca deve-se usar o comando ModelType nome_da_variavel. Para definir o objeto que será importado, deve ser utilizado o comando LoadObj na função principal Main da seguinte forma: nome_da_variavel.LoadObj("arquivo.obj", tamanho);. Para o objeto importado ser desenhado na tela, é preciso usar o comando nome_da_variavel.Draw(); na função Desenha (responsável pelo redesenho da janela de visualização). Se forem utilizadas texturas nos arquivos importados .obj, as mesmas devem estar no formato .tga e todos os arquivos devem estar na mesma pasta do programa. Para a utilização da porta USB, a qual está conectada ao hardware do sistema, faz-se necessária a declaração e configuração das portas da placa USB utilizada para a conexão. Esta declaração deve ficar fora das funções (variáveis globais), em que duas variáveis irão receber os valores de entrada da porta B e C da placa USB, e uma outra variável de saída que enviará para a USB o valor

correspondente ao pino que acionará o atuador conectado. Abaixo é demonstrado o código de configuração inicial da USB. ... //SETANDO PORTA USB HINSTANCE GetDLL; FARPROC SetDirecaoID; FARPROC SetOutID; FARPROC GetInID

;

typedef int (__stdcall * pF1)(char DirectionByteB, char DirectionByte, char DirectionByte, char UsedPorts); typedef int (__stdcall * pF2)(char DataOutByteB, char DataOutByteC, char DataOutByteD, char UsedPorts); typedef int (__stdcall * pF3)(int *); typedef int (__stdcall * pF4)(int *); pF1 DirDasPortas; pF2 Saidas; pF3 Medidor; pF4 Sensores;

//Variaveis //conectados

de na

sensores, porta

medidor e

(receberão

respectivamente

valores e

saída

dos da

sensores porta

//(acionamento dos atudadores) int leitura1,leitura2,saida; ... Figura 49 – Configuração inicial da porta USB

Para que a animação seja possível, para cada objeto ou figura “desenhada”, é opcional definir a posição, tamanho, rotação e cor. Para desenhar um objeto e definir todos seus atributos, deve-se chamar a função glPushMatrix() e no final deve-se chamar a função glPopMatrix() para que o próximo objeto a ser desenhado não seja afetado pelas atributos do anterior. As funções responsáveis pela animação dos objetos são as glTranslatef e glRotatef, as quais definem respectivamente posição na tela (x,y,z) e rotação (x,y,z). Criando uma variável que será incrementada e colocando nestas funções, gerará uma movimentação no objeto desenhado. A seguir é demonstrado um trecho da função Desenha, na figura 50, a qual desenha o empurrador do sistema e define a direção em que ele será movimentado.

... //carrega empurrador das caixas para a rampa glPushMatrix(); glColor4f(0,0,0,1); glRotatef(90,1,0,0); glRotatef(90,0,0,1); glTranslatef(-2.55,2.6,-2.77); glRotatef(roda_empurrador,0,1,0); myModel5.Draw(); //carrega figura .obj definida em Main glPopMatrix(); ... Figura 50 – Definição do empurrador (função Desenha)

É observado na figura citada anteriormente que a variável roda_empurrador corresponde ao ângulo em que o objeto será rotacionado através de glRotatef, em que coloca-se “0” nos eixos que não serão afetos pela rotação e “1” no eixo em que será realizada a rotação. Dentro da função Desenha, são definidas as variáveis que irão receber os valores dos sensores e medidor, em que sempre irão verificar o valor recebido para ser feito o tratamento de acordo com os valores recebidos. O código abaixo, trecho da função Desenha, demonstra o recebimento dos valores. É observado que a variável leitura2, a qual recebe os valores dos sensores, passa por um tratamento em que só serão considerados os valores referentes aos pinos um a cinco da porta B, o restante será definido como saída. As variáveis leitura1 e leitura2 serão as responsáveis pela execução das funções essenciais do programa. ... Medidor(&leitura1) Sensores(&leitura2) //Tratamento das entradas = 1 a 5 -> (1 + 2 + 4 + 8 + 16 = 31) leitura2 = (leitura2 ^ 255) & 31 ... Figura 51 – Definição dos valores que serão recebidos dos sensores e medidor

Na função principal (Main) são feitas as chamadas dos arquivos .dll necessários para o acesso à porta USB, bem como a configuração das portas utilizadas. A função DirDasPortas especifica o número de pinos que a porta utilizará

como entrada e saída. O último valor especificado na função refere-se a porta configurada (1 = porta B; 4 = porta C). A figura a seguir mostra estas definições.

int main (int argc, char **argv) {

//DEFINIÇÕES PARA A PORTA USB GetDLL = LoadLibrary("C:/WINDOWS/AVR309IO.DLL"); LoadLibrary("user32.dll");

SetDirecaoID =

GetProcAddress(HMODULE(GetDLL), "DoSetDataPortDirections");

DirDasPortas = pF1(SetDirecaoID);

SetOutID = GetProcAddress(HMODULE(GetDLL), "DoSetOutDataPorts"); Saidas = pF2(SetOutID); GetInID = GetProcAddress(HMODULE(GetDLL), "DoGetInDataPortC");

Medidor = pF3(GetInID); GetInID = GetProcAddress(HMODULE(GetDLL), "DoGetInDataPort");

Sensores = pF4(GetInID);

//Porta B (valor 1) - 2 saidas e 5 entradas (255

31 = 224)

DirDasPortas(224,0,0,1);

//Porta C (valor 4) - 4 entradas (primeiro valor = 0) DirDasPortas(0,0,0,4);

//Saidas

Primeiro valor especifica o atuador ligado = 0 ->todos desligados

Saidas(0,0,0,1); ... Figura 52 – Definições para a porta USB

Quando o sistema é iniciado e um objeto é medido, seu valor é armazenado numa matriz que terá seus valores comparados com o valor da variável que armazenou o valor de tamanho escolhido pelo usuário. A função auxiliar compara_tamanho, que é chamada na função Desenha contém o tratamento de dados quando um objeto (já medido) é identificado no sensor localizado no rejeitador. O valor enviado por este sensor é verificado na função, bem como os valores comparados e de acordo com o resultado, duas funções podem ser

chamadas: a de rejeitar o objeto ou a de aceitá-lo. O código a seguir demonstra a função compara_tamanho.

void compara_tamanho(void) { if(leitura2

(arm_tam[v]==tamanho_escolhido)

bloquear_rejeitador== false ) { glutTimerFunc(1000,ligar_atuador_rejeitador,1000); bloquear_rejeitador = true; liga_rejeitador = true; rejeitador = true; } if(leitura2== 16 && (arm_tam[v] != tamanho_escolhido) && (arm_tam[v]!= 0)) {

bloquear_caixa5 = true; aciona_caixa5 = true; caixa_5 = true;

}

} Figura 53 – Função compara_tamanho

No momento em que o usuário inicia o software, é apresentada na tela a interface de todo o processo. Esta interface consta de duas subjanelas: a primeira mostra a representação tridimensional do hardware, na qual o usuário terá toda a liberdade para controlar os ângulos e posições de visão com o mouse. Com o botão esquerdo do mouse pressionado é possível rotacionar a figura tridimensional, com o botão direito pressionado é possível aproximar ou afastar (zoom) a figura, com o botão do meio (também chamado de “wheel”) pressionado é possível mover a figura para os lados (pan). O hardware tridimensional representado é animado e indica tudo o que acontece no hardware real. A segunda subjanela traz o menu de interação do usuário com o sistema. Este menu indica os valores de entradas dos sensores, medidor e valores de saídas que acionam os atuadores do sistema. O mesmo também traz cinco botões, nos quais quatro deles são as opções de tamanho de objeto que serão rejeitados pelo sistema, e o quinto botão é o responsável pelo início do processo. Também são mostrados no menu, a quantidade de objetos rejeitados e aceitos de acordo com o tamanho (3 cm, 4cm, 5cm e 6cm). A tela inicial é mostrada na figura 54, a seguir.

Figura 54 – Tela inicial do programa

O usuário deverá escolher entre os quatro tamanhos disponíveis de objeto para serem rejeitados com o clique do mouse em um dos quatro botões correspondentes aos tamanhos disponíveis. Após a escolha do tamanho, o usuário deverá clicar no botão “Iniciar” para que o processo se inicie. Imediatamente o dispersador (real e virtual) é ativado, e dispersa o objeto no processo. O usuário deve aguardar alguns segundos para dispersar outro objeto no sistema. A figura 55 a seguir demonstra esta fase do processo.

Figura 55.A – Processo iniciado (virtual);

55.B – Processo iniciado (real)

Em seguida, o objeto (ainda não medido) será identificado no primeiro sensor, localizado no início da esteira. O objeto real e o objeto virtual seguirão o caminho até o medidor, que de acordo com o tamanho medido, acionará as funções responsáveis pela movimentação do medidor virtual e definição da cor e tamanho do

objeto medido. O objeto medido seguirá adiante para a próxima etapa. A figura 56 a seguir demonstra esta fase.

Figura 56.A - Objeto virtual sendo medido

56.B – Objeto real sendo medido

Após a mensuração do objeto, o valor do mesmo é guardado numa matriz para que nas próximas etapas a característica do objeto detectado não seja a mesma de um objeto medido posteriormente. Quando o objeto chega ao fim da primeira esteira, ele é detectado por um sensor que aciona o empurrador de objetos. O objeto medido é empurrado rampa abaixo para a próxima etapa. Ver figura abaixo.

Figura 57.A – Objeto virtual empurrado para a segunda esteira;

57.B – Objeto real empurrado

A seguir, o objeto é identificado pelo sensor localizado no início da segunda esteira, acompanhando o objeto real até o sensor localizado em frente ao rejeitador. Quando o objeto é detectado pelo sensor do rejeitador, o valor medido é comparado com o valor escolhido. Se os valores forem iguais, o rejeitador real será acionado e rejeitará o objeto do sistema.

A animação desta situação corresponderá aos eventos reais ocorridos neste momento. Será indicada no menu a quantidade de objetos rejeitados de acordo com seu tamanho. A figura a seguir demonstra esta etapa.

Figura 58.A – Objeto virtual rejeitado pelo sistema;

58.B – Objeto real rejeitado pelo sistema

Durante a etapa anterior, se o objeto medido for diferente do valor escolhido, o objeto será aceito pelo sistema, seguindo adiante até o fim da segunda esteira. Será indicada no menu a quantidade de objetos aceitos de acordo com seu tamanho. A figura a seguir demonstra esta etapa final. O usuário poderá reiniciar o processo quantas vezes desejar, sendo somente necessário que respeite o tempo estabelecido de intervalo entre cada acionamento do botão “Iniciar”, pois é necessário certo espaço entre os objetos no sistema para que haja sincronismo e eficiência.

Figura 59.A – Objeto virtual aceito pelo sistema;

59.B – Objeto real aceito pelo sistema

6 ALGUMAS POSSIBILIDADES DA UTILIZAÇÃO DO OPENGL EM SISTEMAS SUPERVISÓRIOS O OpenGL pode fornecer uma visualização tridimensional, permitindo uma maior compreensão e melhor acompanhamento do processo. Pode-se observar o processo em qualquer ângulo e qualquer ponto de visualização. Além deste acompanhamento visual mais eficiente, o OpenGL pode oferecer uma gama de possibilidades que podem constituir novos projetos com novas funcionalidades, bem como serem implantadas em projetos já existentes. Algumas delas podem ser citadas como detecção de erros e possíveis problemas no sistema, supervisão via rede, experimentos científicos em tempo real e outros. A detecção de erros pode ser implantada no programa que utiliza OpenGL, através de chamadas de funções que são acionadas mediante a resposta de alguns sensores, quando certo atuador recebeu o comando de ativação porém o sensor próximo a ele não foi acionado. O sistema pode avaliar as possibilidades para o problema ter acontecido e informar ao usuário para verificar as prováveis falhas do sistema, demonstrando os componentes que podem estar comprometidos com ou sem mensagens de avisos, e com aproximação (zoom automático) da área comprometida. Alguns exemplos desta utilização, que podem ser implantados no projeto citado no tópico anterior, são simulados em algumas situações descritas abaixo. Na possibilidade 1, representada na figura 60 a seguir, simula-se a implantação de funções que detectam problemas no sistema. Uma situação problemática é imaginada, em que o usuário escolheu o tamanho de objeto rejeitável e iniciou o processo. Sendo que o hardware esteja em outro local e o usuário esteja supervisionando-o via rede, o objeto não é identificado pelo primeiro sensor e nem é medido pelo medidor segundos após o início do processo. O sistema avisará ao usuário que há algo errado no sistema e que tal evento inesperado pode ter sido causado por: falta de objetos no reservatório de objetos, problemas no motor do dispersador de objetos ou no primeiro sensor (localizado no início da primeira esteira). Os componentes do sistema com possíveis problemas serão destacados para o usuário visualizar e posteriormente corrigir o problema no hardware para que o sistema continue funcionando normalmente.

Figura 60 – Detecção de erros no sistema

Na situação 2, representada na figura 61 abaixo, simula-se a implantação de funções que possibilitam o usuário o “zoom automático” em áreas importantes do sistema. Por exemplo, se o usuário deseja aproximar imediatamente do medidor de objetos no momento em que o objeto está sendo medido, basta um clique em cima da área especificada pelo programa, para que o programa aproxime-se do mesmo. O sistema oferece total liberdade para o usuário visualizar o sistema, mas em situações rápidas em que o tempo para aproximar da zona desejada não é suficiente para observar a etapa por completo, este recurso seria bastante conveniente.

Figura 61.A – Clique na área para “zoom”

61.B – Área aproximada

Na situação 3, observada na figura 62 a seguir, cria-se uma possibilidade de visualização mais detalhada do funcionamento de cada componente do sistema. Nesta situação hipotética, o usuário também poderá visualizar por dentro, por exemplo, o funcionamento interno de um motor, com engrenagens funcionando. O usuário terá usa representação totalmente detalhada de todo o processo, inclusive em detalhes mínimos. As informações proporcionadas serão mais ricas e detalhadas, o funcionamento por completo poderá ser observado durante a execução da aplicação com o hardware que está sendo controlado.

Figura 62.A – Motor do empurrador

62.B – Visualização das engrenagens do motor

7 CONSIDERAÇÕES FINAIS A utilização do OpenGL traz inúmeras vantagens podendo-se destacar a possibilidade de criação de aplicações, tanto bidimensionais quanto tridimensionais interativas, em que grandes quantidades de informações visuais podem ser facilmente acessadas pelo usuário, de forma intuitiva. O grande diferencial da utilização do OpenGL com recursos 3D em relação aos programas já utilizados em supervisão é a completa visualização tridimensional do sistema, que ao contrário da limitada visão 2D, o usuário tem total liberdade de visitar qualquer área, acessando partes que seriam inacessíveis no mundo real, como por exemplo, um grande forno cujas informações do seu funcionamento só poderiam ser descrita em valores numéricos recebidos por sensores de temperatura. Se este sistema fosse construído utilizando o OpenGL e seus recursos tridimensionais, o usuário poderia entrar no sistema e visualizar cada detalhe interno e tudo o que acontece dentro dele, o que seria impossível no mundo real. Outra característica a ser considerada deve-se ao fato da utilização do OpenGL como interface multiplataforma, isto é, ele pode ser utilizado em diversos sistemas operacionais. Os usuários de Linux, cujo número cresce a cada dia, podem executar aplicações que utilizam OpenGL tranqüilamente. Este trabalho teve como objetivo o estudo da utilização do OpenGL como ferramenta gráfica na criação de sistemas supervisórios, bem como a sua viabilidade. Os objetivos específicos foram a criação de um hardware adequado com sensores e atuadores, a projeção e desenvolvimento de um protótipo em maquete que é controlado pelo computador para a utilização do sistema supervisório, a apresentação da melhor solução de visualização de sistemas na área de automação industrial e a verificação da viabilidade da utilização do OpenGL em sistemas supervisórios. Para tanto, foi necessária a criação e montagem de um hardware para a aplicação do OpenGL e vários testes de funcionamento com o software. Após a construção do software supervisório e a sua aplicação no hardware, pôde-se constatar que ele realmente atendeu ao objetivo principal, isto é, o controle eficaz de um sistema automatizado.

Pôde-se também constatar que a melhor solução de visualização de sistemas na área de automação é a tridimensional, a qual traz maior densidade de informações. O OpenGL mostrou-se bastante satisfatório em sistemas supervisórios, em que a maior parte atualmente utilizam visualização bidimensional. As expectativas também foram atendidas, pois a aplicação desenvolvida pode representar em tempo real, cada etapa do processo, reproduzindo cada movimentação de cada simples componente do sistema. A aplicação proporciona uma representação realista do sistema, a qual pode ser reproduzida fielmente em cada detalhe do hardware, contanto que para isto sejam modelados todos os componentes do mesmo em um programa de modelagem 3D tal como o 3D Studio Max ou Blender. Após todos os testes, o funcionamento e sincronia do software construído, em conjunto com o hardware foram extremamente satisfatórios. Tanto o OpenGL, quanto sua biblioteca auxiliar utilizada neste trabalho, a GLUT, possuem extensa documentação na internet, acessível a todos que desejam aprendê-la. Ao contrário de sua grande rival, a Direct3D da Microsoft, o OpenGL não necessita da instalação de uma API para poder programá-la, e também é observado que o mesmo mostra-se mais consistente e portátil que o Direct3D. O OpenGL pode ser implementado em algumas linguagens de programação, tais como C++ e Java, o que traz comodidade para o programador da utilização da linguagem que lhe é mais conveniente. Porém, esta interface apresenta algumas desvantagens. Apesar das aplicações que utilizam esta interface serem leves e acessíveis, grandes quantidades elementos tridimensionais podem tornar a aplicação mais pesada e lenta em computadores mais modestos. E para que haja total sincronia com o hardware, é necessário que o número de frames por segundo da animação do software seja específico. Por exemplo, em certo computador a taxa de frames por segundos da animação da aplicação é de 60 fps e corresponde com fidelidade e sincronia a movimentação dos componentes do hardware real, porém se esta mesma aplicação for executada em um computador com uma configuração mais modesta, a sincronia poderá ficar comprometida, mas sem contudo interferir no funcionamento e acionamento dos atuadores. Isto é, para ter um funcionamento com movimentação e animação dos elementos de forma suave e síncrona (dependendo

da complexidade tridimensional da aplicação), é necessário um computador com uma configuração satisfatória. Como sugestão para futuros trabalhos aponta-se para a implantação de funções analisadoras de possíveis erros no sistema a qual pode ser aplicada em aplicações já desenvolvidas. É sugerido um estudo acerca da

performance de

aplicações

computadores mais modestos, apesar de que programas tridimensionais mais complexos indiscutivelmente requeiram computadores mais velozes, certos pontos podem garantir uma sutil melhoria no desempenho, alguns deles são a utilização de funções que podem otimizar o carregamento de figuras 3D, redução do número de chamadas de funções, ou o controle da taxa de atualização da animação, em que é estabelecida uma taxa de fps máxima para a aplicação. A biblioteca que importa objetos 3D, a ModelType, é importante para que objetos modelados sejam importados com sua textura, possui grande portabilidade e facilidade de utilização no programa. Porém, ela só carrega arquivos .obj. Existem outras que pode substituir, mas que carregue outros formatos de objetos 3D, como por exemplo arquivos .3DS que incluem animação pronta em seu formato, mas todas as bibliotecas pesquisadas (fora a utilizada) mostraram-me de difícil portabilidade e a maior parte delas específicas para carregar determinado objeto tridimensional. Outro ponto que pode ser melhorado é a utilização de bibliotecas auxiliares mais modernas e poderosas, a GLUT, apesar de fácil entendimento e vasta documentação, é mais antiga e não foi atualizada, ela é mais utilizada em aplicações mais simples e leves. Quando utilizadas chamadas de subjanelas do GLUT, a performance da aplicação cai pela metade, pois são feitos todos os procedimentos de atualização para cada janela. Então para que uma aplicação seja mais rápida, deve-se criar todo o contexto numa única janela. Para aplicações mais complexas, existem ferramentas (“toolkits”) mais utilizadas hoje em dia para a criação de games, como o GLEW, que trazem mais funcionalidades e recursos, porém não tão documentado e de fácil aplicação como o GLUT. E uma última sugestão é a adaptação da aplicação para o controle via rede, em que um computador controla e recebe informações do hardware e envia para outro que está executando a aplicação supervisora.

A biblioteca OpenGL, utilizada amplamente na produção de jogos e aplicações de simulação mostrou-se bastante eficaz quanto ao controle de hardware em tempo real, afinal não foi encontrado nenhum registro de sua aplicação em sistemas automatizados. A mesma possui funções que somente recebem entradas de teclado, mouse e joystick (para estabelecer comandos necessários para que se possa ter controle em um jogo). Com a inclusão do controle de dispositivos ligados à porta USB ou paralela, as possibilidades de sua aplicação cresceram exponencialmente, podendo além de receber valores de entrada também enviar valores de saída, capazes de acionar dispositivos e atuadores. Isto é, a aplicação do OpenGL 3D em sistemas automatizados ou de controle é muito promissora. Entretanto, mesmo apresentando pontos que podem ser melhorados, constata-se que com todos os recursos utilizados para a concepção e criação do programa,

podem

ser

construídos

inúmeros

sistemas

supervisórios

com

funcionamento totalmente satisfatório e de funcionamento geral em computadores mais modestos, desde que sua complexidade não seja extremamente avançada. Deve-se verificar que este trabalho serviu como base de dados para que este estudo continue e novos recursos aprimorados sejam adicionados a este trabalho. As possibilidades que a visualização tridimensional traz para o acesso a informações são muitas, pois enriquece a bagagem de informações que o sistema traz, resolvendo problemas que a visualização bidimensional não poderia solucionar. Uma visualização para ser mais eficaz, deve conter o máximo de informações possíveis numa apresentação, porém deve ser de fácil interpretação. Em um sistema supervisório, é de extrema importância que o maior número de informações detalhadas seja fornecido acerca do processo. Com a utilização de figuras 3D utilizando o OpenGL em aplicações de automação industrial e sistemas supervisórios pode-se chegar a um novo nível de controle, mais próximo da realidade.

REFERÊNCIAS

AMBLER, S. Análise e projeto orientado a objeto. v.2, IBPI Press, 1998.

ANAND, Vera B. Computer graphics and geometric modeling for engineers. NewYork: John Wiley & Sons, 1993. BAILEY, David; WRIGHT, Edwin. Practical scada for industry. LOCAL: Elsevier, 2003. BARBOSA SOBRINHO, Marcionílio, Tutorial de utilização do opengl, 2003

BENNATI, R. Aplicações da informática na indústria mecânica. Petrópolis: Vozes, 1990. BOOCH, G. Object-oriented analysis and design with applications. 2nd ed. Addison-Wesley, 1994

BRAGA, Newton C. Aplicações para comparadores de tensão. Disponível em: < >. Acesso em: abr. de 2008. COHEN, Marcelo; MANSSOUR, Isabel. Opengl: uma abordagem prática e objetiva. Editora Novatec, 2006.

CURY, J. E. R., QUEIROZ, M. H de; SANTOS, E. A. P. Síntese modular do controle supervisório em diagrama escada para uma célula de manufatura. V Simpósio Brasileiro de Automação Inteligente, Canela, RS, Brasil, 2001.

DEBONI, José Eduardo Zindel. Breve introdução aos diagramas da uml. Disponível em: <http://www.voxxel.com.br/pages/introdiauml.html >. Acesso em: jul de 2008. ELIPSE. Elipse software – e3 and elipse scada products home – automação industrial. Disponível em: << http://www.elipse.com.br/elipse/produto_texto.aspx?id=1&opcao=Telasexemplo&titulo_secao=E3 >> Acesso em: set de 2007.

100

FREITAS, Carla Maria Dal Sasso; CHUBACHI, Olinda Mioka Introdução à visualização de informações: revista de informática teórica e aplicada. Volume VIII. Número 2, 2001.

GIL, A. C. Métodos e técnicas de pesquisa social. 5ª ed. Atlas, 1999. HARTMANIS, J. and LIN, H., EDS. Computing the future: a broader agenda for c’omputing science and engineering. National Academy Press, Washington, D.C. 1992. HAWKINS, Dave Astle, Kevin. Beginning opengl game programming. Course PTR, 2004 JURIZATO, Luís Augusto; PEREIRA, Paulo Sérgio R. Sistemas supervisórios. Network Technologies, Nova Odessa, v.1/2, n.1/2, p.105-114, 2002/2003 – ISSN: 1677-7778 (versão impressa). LAKATOS, Eva Maria; MARCONI, Mariana de Andrade. Técnicas de pesquisa. Lisboa : Presença, 1993. LED INFRARED. Led infravermelho. Disponíel em: < http://www.burgoseletronica.net/ledinfrared.htm >. Acesso em: abr. 2008. MAIA, W. U. Sistema integrado de operação e diagnóstico de falhas para sistemas de energia elétrica : SODF. 1998.

MACORATTI.NET. Conceitos: Especificação de requisitos. Disponível em: <http://www.macoratti.net/07/12/net_fer.htm >. Acesso em: jul. 2008. MACORATTI.NET. A gestão de requisitos. Disponível <http://www.macoratti.net/vb_conc2.htm >. Acesso em: jul. 2008.

em:

MANGHARAM, Rahul. Assistant professor of electrical and systems engineering, PhD in Electrical & Computer Engineering (2007). Também disponível em: < http://www.ese.upenn.edu/ >.

MATOS, Alexandre Veloso. UML: prático e descomplicado. Rio de Janeiro: Editora Érica, 3ª Ed. 2002

101

NATALE, Ferdinando. Automação industrial, 2ªedição, Editora Érica, São Paulo, 2000. OPENGL. Grand espectacle. Disponível em: << http://www.apple.com/fr/macosx/features/opengl/ >> Acesso em: 9 set. 2007

PENTEADO, Branca Menesses; GASPAR, Carlos Alberto; DI´POLITO, Celso. Mecânica: automação. In: Telecurso 2000, São Paulo: Fundação Roberto Marinho, 1996.

PEREIRA, C. E., PARDI JUNIOR, W. A supervisory tool for realtimeindustrial automation systems. In: Sixth IEEEInternational Symposium on ObjectOriented RealTime Distributed Computing, 2003.

P PARALELA. Características de funcionamento do conversor analógico digital adc0804 de 8 bits. Disponível em: <http://www.rogercom.com/pparalela/ConversorADC0804.htm>. Acesso em: abr. 2008. PATSKO, Luís Fernando. Tutorial controle de relés. São Paulo: Maxwell Bohr, 2006. Também disponível em: <http://www.maxwellbohr.com.br/downloads/Tutorial%20Eletronica%20-%20Rele.pdf >. Acesso em: abr. 2008. SAMPAIO, Marcos Costa. Material sobre uml. Disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/interacao/seq uencia.htm >. Acesso em: jul. 2008. SEDDON, Chris.: OpenGL game development (Wordware applications Library). USA: Wordware Publishing, 2005.

SEGAL, Mark; AKELEY, Kurt. The opengl graphics system: a specification. Disponível em: <<http://www.opengl.org >> Acesso em: set. 2007.

SILVA, Ana Paula Gonçalves da; SALVADOR, Marcelo. O que são sistemas supervisórios?, RT 025.04,2005.

SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da pesquisa e elaboração de dissertação. ed. 3, 2001.

102

SKUNKSWORKS. Application of ifix in power engineering . Disponível em: << http://www.skunksworks.net/doc/asutp/opinion/ifixenerg.php >> Acesso em: set de 2007.

TUFTE, E. R. The visual display of quantitative information. Cheshire, CT: Graphics Press, 1983. VENETIANER, Tomas. Desmistificando a computação gráfica. São Paulo: McGraw-Hill, 1988. WIKIPÉDIA. Desenvolvido pela wikimedia foundation. Apresenta conteúdo enciclopédico. Disponível em: <http://pt.wikipedia.org/w/index.php?title=Processo_de_desenvolvimento_de_softwar e&oldid=9630757>. Acesso em: 25 Mar 2008 WRIGHT JR., Richard S.; LIPCHAK, Benjamin; HAEMEL, Nicholas. Opengl: superbible. Ed. 4. EUA: Addison-Wesley, 2007.