U NIVERSIDADE F EDERAL DE M INAS G ERAIS – UFMG E SCOLA DE E NGENHARIA D EPARTAMENTO DE E NGENHARIA E LÉTRICA Integração de um sistema de leitura por visão computacional a um calibrador automático de instrumentos de medição Danilo Alves de Lima Belo Horizonte Dezembro de 2008 DANILO ALVES DE LIMA Integração de um sistema de leitura por visão computacional a um calibrador automático de instrumentos de medição Projeto de Final de Curso apresentado ao Colegiado de Engenharia de Controle e Automação da Universidade Federal de Minas Gerais como requisito para obtenção do título de Engenheiro de Controle e Automação. Orientador: Prof. Guilherme Augusto Silva Pereira / DEE - UFMG Supervisor: Prof. Flávio Henrique Vasconcelos / DEE - UFMG Belo Horizonte Dezembro de 2008 Resumo O presente trabalho abordará a solução adotada para se integrar um sistema computacional de leitura por visão computacional a um sistema de calibração automática de instrumentos de medidas elétricas (SISCAL). Esta integração permitirá a calibração automática de instrumentos que originalmente não possuem interface com o computador. Sendo os sistemas originalmente desenvolvidos em linguagem de programação e frameworks diferentes (C#/.Net e C++/MFC), suas estruturas sofreram alterações para permitir a comunicação entre eles. A integração fez uso dos recursos do framework .Net para a portabilidade entre sistemas, tornando, por exemplo, a aplicação de leitura por visão computacional independente de linguagem de programação. Além da integração, recursos extras foram adicionados ao sistema final, complementando funcionalidades e respeitando as especificações do programa SISCAL definidas em trabalhos anteriores. Os resultados obtidos atenderam todos os objetivos propostos, fornecendo uma aplicação de fácil compreensão a futuros usuários interessados em dar continuidade ao projeto SISCAL. Palavras chave: Calibração automática de instrumentos; Visão computacional; Banco de dados; Integração de dados. i Abstract In this work it is studied a solution to integrate a computer vision system for reading measurements instruments to a system for automatic calibration of electrical measurement instruments (SISCAL). This integration allows the automatic calibration of instruments that originally do not have a hardware communication interface for computers. As the systems have been originally developed in different programming languages and frameworks (C#.Net and C++/MFC), their structures have been changed to allow the communication between them. This integration used resources of the .Net framework for system portability, making, for example, a computational vision reading application independent of programming language. Beyond the integration, extra resources have been added to the final system, complementing functionalities and respecting the specifications of the SISCAL program, defined in previous works. The results realize all the proposals objectives, disposing a useful application, easily to future users interested in the maintenance of the project SISCAL and the measurement instruments reading by computer vision. Keywords: Automatic instruments calibration; Computational vision; Data base; Data integration. ii Lista de Abreviaturas e Siglas SISCAL Sistema Automatizado para a Calibração de Instrumentos Elétricos de Medição GPIB Do inglês General Purpose Interface Bus SCPI Do inglês Standard Commands for Programmable Instruments MFC Do inglês Microsoft Foundation Class CLR Do inglês Common Language Runtime SQL Do inglês Structured Query Language OCR Do inglês Optical Caracter Recognition SDK Do inglês Software Development Kit DLL Do inglês Dynamic Link Library iii Lista de Figuras 1.1 “Figura esquemática do papel do VISA na comunicação com instrumentos de medição” (Fonte: KUDO, 2007, pág. 28) [1] . . . . . . . . . . . . . . . . . . . . . . . 1.2 Exemplo de funcionamento da interface COM. . . . . . . . . . . . . . . . . . . 1.3 O framework .Net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7 8 2.1 “Diagrama de contexto do SISCAL.”(Fonte: KUDO, 2007, pág. 35) [1] . . . . . . 12 3.1 3.2 3.3 3.4 19 20 21 3.5 3.6 3.7 3.8 3.9 Estrutura do Banco de Dados desenvolvido por Kudo (2007) [1] e suas relações. . Janela para acesso às principais funcionalidades do SISCAL. . . . . . . . . . . . Telas para cadastro no banco de dados. . . . . . . . . . . . . . . . . . . . . . Fluxograma com as etapas realizadas no processo de leitura de instrumentos digitais (à direita) e analógicos (à esquerda ).(LIMA et al, 2007, p. 2)[2] . . . . . . Imagem binária representando a região de interesse de um multímetro digital. . . Histogramas para delimitar os dígitos do número 118,5. . . . . . . . . . . . . . Imagem do número 8 e seus 7 segmentos ativos. . . . . . . . . . . . . . . . . . Imagem binária com as bordas em destaque obtida pelo Método de Canny e sua correspondente região de interesse. (LIMA et al, 2007, p. 2)[2] . . . . . . . . . Simetria de alguns instrumentos analógicos. . . . . . . . . . . . . . . . . . . . 4.1 4.2 4.3 4.4 4.5 4.6 Sistema de iluminação projetado para o sistema SISCAL. . . . . . . . . . . Janela para configuração da leitura de instrumentos digitais. . . . . . . . Janela para configuração da leitura de instrumentos analógicos. . . . . . . Janela de seleção do tipo de câmera. . . . . . . . . . . . . . . . . . . . . Janela de seleção do modelo do instrumento analógico. . . . . . . . . . . . Tabelas “PropriedadesCamera” e “AnguloValor” e suas relações com a tabela trumento”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Nova janela para o cadastro de instrumentos do programa SISCAL. . . . . . . . . . . . . . . . . . . . 23 24 25 25 26 26 31 34 35 36 36 “Ins- . . . . . . 37 38 A.1 Fluxograma exemplificando a seqüência de chamada das funções da biblioteca OCR. 45 iv Sumário Resumo i Abstract ii Lista de Abreviaturas e Siglas iii Lista de Figuras iv Sumário vi 1 Introdução 1.1 Motivação e Relevância . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Revisão Bibliográfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 3 8 2 O SISCAL 2.1 O Sistema . . . . . . . . . . . . . . 2.2 Arquitetura do Sistema . . . . . . . 2.3 Características de Desenvolvimento 2.4 Parâmetros de Aceitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 11 13 14 3 As aplicações 3.1 O programa desenvolvido por Kudo . . . . . . . . . . . . . . 3.1.1 Os recursos utilizados . . . . . . . . . . . . . . . . . 3.1.2 O banco de dados . . . . . . . . . . . . . . . . . . . 3.1.3 A interface com o usuário e trabalhos não concluídos 3.2 O programa de leitura por visão computacional . . . . . . . 3.2.1 Os recursos utilizados . . . . . . . . . . . . . . . . . 3.2.2 O programa . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 A interface com o usuário e trabalhos não concluídos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 15 15 16 18 20 22 22 27 . . . . 28 28 29 31 34 . . . . 4 A integração das aplicações 4.1 As opções de integração . . . . . . . 4.2 Os recursos adicionais . . . . . . . . 4.3 A nova aplicação OCR . . . . . . . . 4.4 A integração com a aplicação SISCAL 5 Conclusão A As funções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 v 41 SUMÁRIO vi B As tabelas novas 46 Referências 50 Capítulo 1 Introdução 1.1 Motivação e Relevância A criação de padrões em medidas e instrumentos de medição é algo que esteve presente ao longo de vários anos na história da humanidade. Como descreve Kudo (2007) [1], por exemplo, tanto na China dos séculos XVI a XVIII a.C quanto no Egito do período das pirâmides, a padronização e controle de medidas foram importantes para um aumento no volume de produção artesanal da época e na qualidade final dos produtos. Ainda no Egito, já se possuía relatos de padrões de medidas esculpidos em granito, que serviam de amostras para que se realizassem réplicas. Atualmente, com os avanços da sociedade moderna, a necessidade de se aumentar a qualidade em diversos meios fez com que se originassem padrões internacionais de medidas e com ela a calibração de instrumentos de medição. Nos processos de calibração, através das características físicas e operacionais de funcionamento dos instrumentos, equações que regem as medidas do instrumento podem ser formuladas. Para a calibração de instrumentos de medição foram criados normas e padrões que visavam entrar em conformidade com a norma internacional de qualidade ISO/IEC1 17025. No Brasil, as normas que seguem o padrão ISO/IEC 17025 são as da Associação Brasileira de Normas Técnicas, ABNT (1999)[3], e fornecem informações necessárias para que o instrumento possa ser certificado. Nos modelos de calibração definidos pelos padrões da ABNT, o operador responsável deve ser capaz de informar diversos parâmetros sobre o instrumento a ser calibrado e o instrumento de referência, tais como escala, extensão e resolução do mostrador por exemplo. Além desses parâmetros, o operador 1 Do inglês International Organization for Standardization e International Electrotechnical Commission. 1 CAPÍTULO 1. INTRODUÇÃO 2 deve adquirir todas as medidas do instrumento a ser calibrado e seu respectivo valor de referência para realização das operações de calibração. A calibração é necessária com vistas a estabelecer a rastreabilidade do instrumento aos padrões do S.I. (sistema internacional de unidades) e para obtenção da incerteza das medidas. Realizando as etapas anteriores com sucesso, será emitido um certificado de calibração para o instrumento. Sendo os passos anteriores necessários para se realizar uma calibração, verificase que existe um grande número de operações que, normalmente, uma pessoa deve realizar manualmente, abrindo assim possibilidades para que sejam cometidos erros grosseiros. A omissão de algum parâmetro descritivo do instrumento, um erro de leitura e anotação de um valor de seu mostrador são apenas alguns problemas que podem ocorrer, desqualificando o processo de calibração. Devido aos problemas citados, surgiu a idéia de automatizar a calibração de instrumentos digitais e analógicos de medição, como uma solução para estas questões e também como um fator para aperfeiçoar e dar agilidade ao processo. Em projetos de iniciação científica da Universidade Federal de Minas Gerais (UFMG), nos laboratórios LaMIC2 e CORO3 , foram desenvolvidas duas aplicações com este intuito. A primeira, desenvolvida por Aparecida Terayama Sallum durante o seu mestrado, quando elaborou parte da arquitetura do sistema. Posteriormente, João Felipe Kudo deu continuidade ao gerenciamento de toda a informação necessária para a calibração de instrumentos de medição. Kudo (2007)[1] implementou o banco de dados operacional, projetado por Sallum (2002)[4] com informações de usuário, instrumentos e resultados de calibração com a linguagem de programação C#. A segunda aplicação foi desenvolvida pelo autor do presente trabalho, e realizava a leitura do mostrador de diversos instrumentos de medição, sejam eles analógicos ou digitais, utilizando a visão computacional. Neste caso, a linguagem de programação foi o C++. As aplicações foram propostas como parte integrante de um projeto final chamado Sistema Automatizado para a Calibração de Instrumentos Elétricos de Medição, ou SISCAL, com o qual se vislumbra uma parceria entre a UFMG e a empresa Furnas Centrais Elétricas S/A. Este sistema seria uma solução aos problemas citados inicialmente e que são bastante comuns em processos de calibração. Porém, para que tenha seu real valor, as duas aplicações precisam interagir entre si, combinando informações para que 2 3 Laboratório de Medição e Instrumentação Computacional. Laboratório de Sistemas de Computação e Robótica. CAPÍTULO 1. INTRODUÇÃO 3 a calibração de instrumentos possa ocorrer. Assim é necessária a adaptação das duas aplicações criadas anteriormente para que ocorra a comunicação e interação da forma mais amigável possível para o usuário, e sejam, enfim, incorporadas ao sistema final do SISCAL. Sendo este trabalho focado no desenvolvimento do SISCAL, a seguir será apresentado um pouco sobre a evolução da metrologia e suas tecnologias. 1.2 Revisão Bibliográfica A preocupação com o sistema de medição brasileiro quanto à sua qualidade e fiscalização esteve sempre presente desde os primórdios das capitanias hereditárias. Segundo Dias (1998) [5], em 1532 já se tinha conhecimento de um funcionário colonial responsável por realizar a fiscalização de pesos e medidas, o almotacé. Com o crescimento da colônia, novas formas de fiscalização foram sendo criadas. Surgindo em meados do século XVIII, por exemplo, o Juiz de Balança do Tabaco e o Intendente do Ouro, que eram responsáveis por fiscalizar as medidas de tabaco e ouro respectivamente. No século XIX, após a independência, padrões de pesos e medidas foram incluídos na constituição de 1824, sempre visando questões comerciais. No Brasil e no mundo durante os séculos XIX e XX, foram surgindo importantes indústrias de instrumentos, laboratórios de metrologia e com eles pesquisas na área foram sendo desenvolvidas, visando melhorias nos instrumentos de medidas utilizados. Digno de nota é o denominado "Acordo do Metro", assinado em 1875, quando se iniciou o sistema metrológico atual. Paralelamente, a definição de padrões internacionais de medidas tornou-se mais necessária, devido ao surgimento de novas tecnologias e a globalização do comércio, que auxiliou na criação das normas ISO em 1947 e do Sistema Internacional de Unidades (SI) em 1960. A Associação Brasileira de Normas Técnicas, ABNT, de 1940 e o Instituto Nacional de Metrologia, Normalização e Qualidade industrial, INMETRO [6], de 1973 são as referências nacionais para padrões internacionais. A norma internacional adotada atualmente para o ramo da calibração de instrumentos é a ISO/IEC 17025. Acompanhando o desenvolvimento mundial de normas para a calibração de instrumentos de medição e, conseqüentemente, a complexidade em seus processos, verificouse o surgimento de novas tecnologias nesta área. Estas tecnologias foram de fundamen- CAPÍTULO 1. INTRODUÇÃO 4 tal importância para viabilizar propostas de automação para o processo de calibração. A primeira delas, como destaca Kudo (2007) [1], foi o computador, com surgimento principalmente na década de 60, ocorrendo automação do processo de medição manual. Esta evolução fez com que na década de 70 surgissem instrumentos com a capacidade de controle remoto por computador. Com o surgimento dos novos instrumentos, surgiram também diversas formas de se realizar a comunicação entre eles e o computador. Assim, tinha-se um cenário com vários instrumentos e interfaces possíveis, complicando para o usuário, que deveria conhecer todas as formas de comunicação e se tornava preso ao que o fabricante do equipamento lhe impunha, tornando inviável a criação de sistemas complexos de medição. Como forma a solucionar o problema, surgiu a necessidade de se padronizar interfaces. Uma interface que ganhou ampla aceitação foi a HPIB4 da Hewlett-Packard, que através da união de fabricantes juntamente com a comissão internacional de eletrotécnica (IEC), em 1973 definiram o padrão IEC 60625-1, também conhecido por ANSI/IEEE 488.1, como descreve Pieper (2004) [7]. Este padrão criou o barramento GPIB5 que além de interface de comunicação é também um protocolo. Para adicionar funcionalidades ao padrão IEEE 488.1, foi criado o padrão IEEE 488.2, que está um nível acima do protocolo GPIB e fornece um arcabouço para a comunicação entre dispositivos e um controlador, sendo uma interface para a troca de mensagens. O padrão IEEE 488.2 define uma estrutura de comandos e formatos que motivou um consórcio de empresas, o Standard Commands for Programmable Instruments (SCPI), a desenvolver um conjunto único de comandos de programação para instrumentos. Isto permitiu o seu uso com outros padrões que surgiram ao longo da evolução do computador, tais como o IEEE 1174, conhecido como barramento RS-232, o VME eXtensions for Instrumentation ou VXI e os mais recentes Universal Serial Bus ou USB e o IEEE 1394 ou Firewire, por exemplo. Acompanhando esta evolução, a VXI Plug&Play Systems Alliance em 1993 lançou a arquitetura VISA6 para servir como uma API comum (Application Programming Interface) de controle e desenvolvimento de drivers para instrumentos com diferentes barramentos. A Figura 1.1 apresenta a arquitetura da interface VISA para a comunicação com instrumentos de medição. 4 5 6 Do inglês Hewlett-Packard Interface Bus. Do inglês General Purpose Interface Bus. Do inglês Virtual Instrument Software Architecture. CAPÍTULO 1. INTRODUÇÃO 5 Fig. 1.1: “Figura esquemática do papel do VISA na comunicação com instrumentos de medição” (Fonte: KUDO, 2007, pág. 28) [1] Com auxílio dos padrões da IEEE7 , vários foram os desenvolvimentos em automação de sistemas de calibração. Hayward (1988) [8] e Koeman (1990) [9], por exemplo, criaram dispositivos que utilizam um sistema de calibração e aquisição de dados para vários instrumentos com uso da interface IEEE 488.1. O primeiro foi desenvolvido para um laboratório de testes térmicos, com o objetivo de integrar e automatizar o processo, aumentando a qualidade e quantidade de calibrações efetuadas. O segundo criou um sistema modular eletrônico, com a capacidade de calibração automatizada que inclui um sistema de controle e o uso de uma pluralidade de instrumentos de calibração para calibrar um instrumento alvo. Com relação às funcionalidades da aplicação e não de seus recursos, Maia et al (2003) [10] gerou um banco de dados relacional capaz de gerenciar uma calibração de instrumentos de medição de estações de gás natural. Este sistema pode, também, calibrar o instrumento após a inserção das medidas realizadas pelo operador, gerando todos os cálculos estatísticos do processo. O processo de aquisição de dados, portanto, é manual. Para sistemas de calibração mais abrangentes, visando a leitura dos mostradores dos instrumentos de medição, Foiatto et al (2005) [11] desenvolveu uma aplicação para leitura de instrumentos digitais, fazendo uso da visão computacional e da interface de comunicação GPIB. Um sistema que libera o operador da função de leitura dos dados, mas como foi dito, restrito aos instrumentos digitais. Neste mesmo direcionamento, Alegria (1997) [12] apresentou em sua dissertação de mestrado um aplicativo capaz de realizar a leitura por visão computacional de instrumentos digitais e analógicos, também realizando a calibração de ambos. Alegria também disponibilizou a calibração para 7 Do inglês Institute of Electrical and Electronics Engineers. CAPÍTULO 1. INTRODUÇÃO 6 instrumentos com a interface GPIB e uma base de dados sobre o operador e instrumentos a serem calibrados. Em suma, as idéias do projeto desenvolvido por Alegria são próximas às que serão apresentadas ao longo deste trabalho, a menos pela integração de duas linguagens de programação distintas. Sabendo que a maioria dos sistemas desenvolvidos atualmente são em ambiente Microsoft e em computadores com processadores Intel e seus similares, como descreve Mendes (2008)[13], a integração de aplicações sempre foi muito voltada para esta combinação. Foi assim com as tecnologias DDE, OLE, COM, DCOM, COM+ e ActiveX, todas desenvolvidas pela própria Microsoft. A primeira delas, o DDE8 , foi criada para troca de dados entre aplicações do Windows 3.0 (1990), através de memória compartilhada, sendo seus comandos complexos. Com o surgimento de programas como Microsoft Word e Microsoft Excel, veio a necessidade de se utilizar documentos compostos, como tabelas do Excel dentro de documentos Word. A tecnologia OLE9 1.0 permitia esta funcionalidade nos sistemas Windows 3.1 (1992), considerada uma tecnologia à frente de seu tempo por utilizar muita memória, não disponível para as máquinas da época, sendo este o início do que seria componentização para aplicações Microsoft. Paralelamente ao surgimento da OLE 1.0, a componentização começou a ser uma prerrogativa para as novas aplicações. Foi pensando neste nicho de mercado que a Object Management Group (OMG) criou a tecnologia CORBA10 , para multiplataformas operacionais, porém não gratuito. Isto permite que funções implementadas em uma determinada aplicação possam ser chamadas em qualquer aplicação que utilize esta tecnologia. Assim, um componente A de uma aplicação pode acessar um componente B de uma segunda aplicação, obtendo apenas uma referência para o objeto B e acessando através de uma interface definida pela CORBA. Seguindo a linha da OMG, a Microsoft em 1993 lançou a especificação OLE 2.0, baseada no Component Object Model (COM), que foi a forma de criação de componentes de softwares definida e utilizada pela Microsoft em suas aplicações a partir deste momento, sendo, portanto, exclusiva de plataformas com sistemas operacionais Windows. A Figura 1.2 exemplifica este modelo de componentização, com a interface IUnknown para requerer o ponteiro para o objeto em destaque. Derivações, tais como Dis8 9 10 Do inglês Dynamic Data Exchange. Object Linking and Embedding Do inglês Common Object Request Architecture. CAPÍTULO 1. INTRODUÇÃO 7 tributedCOM (DCOM) e COM+ surgiram com o mesmo principio do COM, mas para realizar a integração entre aplicações distribuídas em máquinas diferentes. Pela internet, a ferramenta que segue este princípio é o ActiveX, executando dentro do web browser da máquina, com um grave problema de segurança por permitir acesso irrestrito à máquina que o executa. Fig. 1.2: Exemplo de funcionamento da interface COM. Em 1995, a Sun Microsystems desenvolveu a linguagem de programação e o ambiente de desenvolvimento Java para multiplataformas, com máquinas distribuídas e orientado a objetos. Foi desenvolvido para executar através de uma Máquina Virtual Java (JVM), garantindo acesso restrito à máquina hospedeira da aplicação. O Java assim como COM possui todo um sistema de componentização permitindo a interoperabilidade entre suas aplicações, mas com a segurança da JVM. Atualmente na versão Java 2 Enterprise Edition (J2EE), com recursos avançados para a criação de softwares, suas aplicações, por exemplo, permitem a comunicação facilitada com as desenvolvidas com a arquitetura CORBA. Como resposta da Microsoft à crescente utilização de aplicações desenvolvidas com Java, foi desenvolvido o framework .Net para aplicações distribuídas pela internet. De acordo com Mendes (2008)[13], a estrutura do framework .Net pode ser descrita pela Figura 1.3, onde, em níveis, separa o que o usuário visualiza e o que o sistema operacional realmente opera. Nela fica claro como programas em diferentes linguagens de programação suportadas pelo .Net são interpretadas por camadas em comum, sendo as principais a Base Class Library e a Common Language Runtime (CLR). Ao final, não importa a origem do código, pois o sistema operacional interpretará igualmente. Para fins de comparações, a CLR pode ser associada com a Java Virtual Machine (JVM), pois desempenham funções similares, tais como o garbage collection para a limpeza automática de memória. Atualmente o .Net esta na versão 3.5 e como diferencial às demais tecnologias de integração desenvolvidas pela Microsoft, pacotes gratuitos para CAPÍTULO 1. INTRODUÇÃO 8 desenvolvimento em outros sistemas operacionais são disponibilizados pela Microsoft Corporation (2008)[14]. Fig. 1.3: O framework .Net. 1.3 Objetivos Visando incorporar as aplicações de leitura de instrumentos de medição e gerenciamento de informações ao Sistema automatizado para a calibração de instrumentos elétricos de medição (SISCAL), este trabalho terá como objetivo realizar a integração dessas aplicações, sendo necessário: • Alterar a aplicação de leitura de instrumentos de medição por visão computacional de C++/MFC para C++/.NET; • Permitir que as funcionalidades da nova aplicação gerada no item anterior possam ser utilizadas na aplicação de gerenciamento de instrumentos; • Integrar os recursos de cada aplicação, possibilitando, por exemplo, o acesso ao banco de dados pela aplicação de leitura de instrumentos. Deverão também ser criadas funcionalidades que enriqueçam o processo de calibração utilizando o SISCAL. Todos os recursos extras serão desenvolvidos para uma interface amigável ao usuário, para que os novos módulos dos programas possam ser facilmente administrados. Este trabalho deverá fornecer subsídios para que futuros interessados possam prosseguir com o projeto e utilizá-lo para pesquisas futuras. Capítulo 2 O SISCAL A metodologia utilizada neste trabalho relaciona-se a um sistema final chamado SISCAL, o qual poderá ser utilizado por diversos usuários. Por esta razão, o seu desenvolvimento será realizado de forma a atender uma série de requisitos, como foram descritos por Kudo (2007) [1], considerados necessários para se ter um bom sistema de calibração. A seguir será apresentada esta especificação de requisitos que serviu como base para a criação das sub-aplicações de gerenciamento e leitura de instrumentos de medição de grandeza elétrica e é a definição da aplicação SISCAL. Este trabalho tentará aproximarse ao máximo da aplicação SISCAL. 2.1 O Sistema O sistema SISCAL tem como objetivo automatizar a calibração de instrumentos de medição de grandezas elétricas com ou sem interface com o computador. O SISCAL é composto por um sistema de aquisição de imagens de vídeo para os instrumentos sem interface com o computador, um banco de dados operacional, com todas as informações necessárias ao processo de calibração, e um software capaz de integrar todas essas funcionalidades, além de uma interface de comunicação com os demais instrumentos. Para que o sistema possa ser aplicado na vida prática de empresas, o SISCAL deverá atender aos clientes com benefícios, sendo estes divididos em essenciais e desejáveis. Os essenciais precisam ser cumpridos pela aplicação final, sendo o foco principal deste trabalho. Os desejáveis fornecerão características ao programa que serão diferenciais entre aos tradicionais métodos de calibração. 9 CAPÍTULO 2. O SISCAL 10 A seguir estão listadas as características consideradas essenciais para o projeto segundo Kudo: • Calibração informatizada de diversos instrumentos de medidas elétricas com ou sem interface de comunicação com computadores; • Comunicação com diferentes tipos de instrumentos e diferentes interfaces de comunicação; • Simplificação do processo de calibração para o usuário; • Diminuição de erros humanos no processo de calibração; • Armazenamento de procedimentos de calibração e características operacionais dos instrumentos, para que os mesmos possam ser repetidos sem a necessidade de configuração a cada vez que for realizada a calibração; • Armazenamento de informações relevantes que influenciam a calibração com o intuito de alertar o usuário de modo a minimizar efeitos sistemáticos; • Possibilidade de aumento do número de medidas efetuadas no processo de calibração sem as dificuldades práticas e inconveniências do processo manual. (KUDO, 2007, p. 33-34) [1] Kudo também descreveu alguns benefícios desejáveis: • Diminuição de mão-de-obra para o processo de calibração; • Diminuição do tempo gasto no processo; • Calibração de instrumentos remotos ligados a uma rede (Ex: Internet). (KUDO, 2007, p. 34) [1] Em adição a estes benefícios têm-se alguns que, se acrescidos ao sistema de leitura por visão computacional, seriam desejáveis no produto final, tais como: • Robustez do sistema de leitura às variações externas, tais como iluminação, alinhamento do visor e sombreamento; • Processamento rápido da imagem, independentemente de qualquer resolução; CAPÍTULO 2. O SISCAL 11 • Adaptabilidade do sistema de leitura ao maior número possível de mostradores de instrumentos de medição elétrica; • Simplicidade geral do sistema. Além de benefícios, o sistema final terá limitações, que posteriormente poderão tornar-se adições para futuros interessados em dar continuidade ao projeto e ampliar suas funcionalidades. Uma limitação importante, vinculada ao padrão de implementação adotado, é o uso exclusivo de comandos definidos pelo padrão SCPI para o envio de comandos e recebimento de informações dos instrumentos, assim todos os automatismos referentes a instrumentos estarão vinculados à aceitação deste padrão. Também será necessário que o instrumento calibrador seja capaz de receber comando via computador, caso contrário, o mesmo será realizado no próprio instrumento. O SISCAL não será um sistema o reconhecimento de dispositivos de maneira plug-and-play, o usuário será responsável por esta inserção e configuração. Por fim, com relação à leitura dos instrumentos por visão computacional, esta não será garantida para todos os instrumentos, dependo se suas características atendem aos algoritmos implementados, permitindo, porém, a adaptação do programa aos mesmos. 2.2 Arquitetura do Sistema Para se compreender melhor o sistema, o mesmo será apresentado na Figura 2.1 na forma de um diagrama de casos de uso. Nesta figura podem ser visualizadas diferentes permissões de acesso e uso do sistema, com os seguintes atores: Engenheiro, Técnico e Gerente, com ações que estejam de acordo com a norma ISO/IEC-17025. O Engenheiro é o usuário com maior conhecimento sobre metrologia, sistemas elétricos e instrumentação. Entre suas ações no sistema estão o cadastramento de instrumentos, com todas as configurações cabíveis (Gestão de Instrumentos) e gerando os procedimentos de calibração (Gestão de Procedimentos). O Técnico é o ator responsável pela execução do procedimento de calibração, sendo sua ação restrita ao uso das informações do sistema, sem alterações significativas. Por fim, o Gerente é o administrador do sistema, o qual possui todas as funcionalidades definidas para o Engenheiro e Técnico, possuindo também as responsabilidades pelo gerenciamento dos recursos humanos e financeiros do sistema. CAPÍTULO 2. O SISCAL 12 Fig. 2.1: “Diagrama de contexto do SISCAL.”(Fonte: KUDO, 2007, pág. 35) [1] Há também os atores sobre os quais o sistema atua, através da medição e geração de sinais. Eles podem ser realizados por mecanismos com ou sem interface de comunicação com o computador, como é feito com a leitura por visão computacional e instrumentos com interface GPIB. Além dos atores presentes na Figura 2.1, estão representados os casos de uso, que são as funcionalidades principais do SISCAL. A seguir os casos de uso serão brevemente descritos: • Gestão de Instrumentos - responsável pela configuração, cadastramento, consulta, alteração e remoção de sistemas de medição. • Gestão de Equações - atribui uma equação que representa o modelo de medição do instrumento. • Gestão de Variáveis - realiza o cadastramento, pesquisa e remoção de variáveis referentes às equações e funções de medição dos instrumentos. CAPÍTULO 2. O SISCAL 13 • Gestão de Procedimentos - responsável pela configuração dos procedimentos de calibração. • Gestão de Usuários - responsável pelo gerenciamento dos usuários do sistema. • Calibração - funcionalidade principal do SISCAL, que devido à sua complexidade, foi dividida em casos de uso menores: Análise de Incertezas, Identificação de não Conformidade e Ajuste de Instrumento. • Comunicação com PC e Visão Computacional - representam as comunicações possíveis a partir de cabos, hardware padrões e câmera de vídeo. • Gestão de Certificados - realiza a geração, consulta e impressão de certificados de calibração. • Administração da Periodicidade - realiza o monitoramento do prazo de validade das calibrações dos instrumentos cadastrados no SISCAL, com funcionalidades de variabilidade e definição do melhor período para se calibrar o instrumento. 2.3 Características de Desenvolvimento O desenvolvimento do sistema deverá respeitar os requisitos descritos nos itens anteriores. Tentar-se-á ao máximo, manter o uso das ferramentas que foram previamente utilizadas nas aplicações iniciais, evitando o retrabalho. Assim, o desenvolvimento será realizado nos sistemas operacionais Windows XP/Vista, da Microsoft Corporation (2008)[14], juntamente com o framework .Net 2.0 e linguagem C++ e C#. Esta opção possibilitará a integração das aplicações, mesmo sendo elas feitas em linguagens distintas, porém ocasionará a primeira mudança necessária na aplicação de visão computacional, alterando-a de C++/MFC1 para C++/.Net. Além das ferramentas de desenvolvimento, recursos extras para acesso a banco de dados e comunicação entre os instrumentos final deverão estar previamente disponibilizados pelo sistema. Foram usados o servidor MySQL com o conector para bancos de dados Conector/Net ver. 5.0 ou superior e os drivers de comunicação dos instrumentos e placas utilizadas, ficando a cargo do usuário configurá-los no sistema final. 1 Do inglês Microsoft Foundation Class. CAPÍTULO 2. O SISCAL 2.4 14 Parâmetros de Aceitação Para que o sistema possa ser aceito, este deverá atingir todos os requisitos listados na especificação de requisitos e com uma interface gráfica de fácil interação e aprendizado pelo usuário. O programa poderá ser adaptado às necessidades específicas de empresas, seguindo, por exemplo, padrões para a concepção de certificados e até mesmo layout da aplicação. No próximo capítulo serão apresentadas com maiores detalhes as aplicações desenvolvidas para a calibração de instrumentos e leitura por visão computacional até a realização deste trabalho. Estas aplicações serão as principais fontes de alterações neste trabalho. Capítulo 3 As aplicações Para se compreender as alterações realizadas nos programas de calibração de instrumentos de medição e de leitura por visão computacional, deve-se primeiramente esclarecer o funcionamento das aplicações em separado. Neste capítulo estas aplicações serão detalhadas, apresentando recursos usados, interfaces com o usuário e trabalhos futuros deixados pelos autores. 3.1 O programa desenvolvido por Kudo Responsável pela modelagem operacional do programa SISCAL, João Felipe Kudo (2007) [1] desenvolveu em seu projeto de final de curso o esboço de como seria a aplicação final. Em seu trabalho, levantaram-se os pré-requisitos necessários para se realizar a calibração de instrumentos e, conseqüentemente, as funcionalidades do programa SISCAL. Nesta seção, será apresentado brevemente o trabalho realizado por Kudo, com o banco de dados desenvolvido, os recursos utilizados por ele e o programa final apresentado. 3.1.1 Os recursos utilizados Como foi dito em capítulos anteriores, o programa desenvolvido por Kudo foi realizado inteiramente em Microsoft Visual C# Express 2005, com o framework .Net 2.0, que é uma ferramenta gratuita. Porém, como seu programa deveria apresentar outras funcionalidades, tais como comunicar com instrumentos remotos e com banco de dados, outras ferramentas foram utilizadas, sendo algumas delas incorporadas ao próprio programa C# na forma de bibliotecas. Algumas dessas ferramentas de software serão apre15 CAPÍTULO 3. AS APLICAÇÕES 16 sentadas a seguir, sendo que, para maiores informações recomenda-se ver o documento escrito por Kudo (2007) [1]. Para a comunicação com os instrumentos remotos, além dos softwares específicos, hardwares como placas GPIB e instrumentos compatíveis com SCPI foram também utilizados. Para desenvolver o banco de dados, foi necessário realizar sua modelagem, sendo utilizado o programa DBDesigner 4 (2003) [15] como ferramenta facilitadora do processo. Esta aplicação possui uma interface amigável com o usuário para a geração de tabelas, relações e outros elementos necessários na criação de um banco de dados. O sistema modelado foi exportado como um arquivo SQL1 , sendo importado no programa MySQL (2007) [16] para o gerenciando do banco de dados. O MySQL foi utilizado por possuir bibliotecas para serem utilizadas em aplicações .Net capazes de realizar a comunicação e gerenciamento de bancos de dados, sendo ela também gratuita. O banco de dados será detalhado na próxima seção deste capítulo. A parte de comunicação com instrumentos remotos via software foi feita com a interface VISA2 , atualmente mantida pela IVI Foundation [17]. O uso desta interface, segundo Kudo, garante um grande número de vantagens ao sistema final. Algumas delas são: independência de comandos específicos para cada interface, programação facilitada por utilizar uma linguagem orientada a objetos, expansível e portável. 3.1.2 O banco de dados O banco de dados modelado por Kudo (2007) [1] com o DBDesigner 4 baseou-se no diagrama de contexto do SISCAL apresentado na figura 2.1 do capítulo 2 deste trabalho. No desenvolvimento deste banco, Kudo se preocupou com as questões de gestão do programa SISCAL, criando as tabelas sempre referentes a estas gestões. Ao final, todas as tabelas se relacionam entre si. A seguir, tem-se uma breve descrição das tabelas do banco de dados (entidades) relacionadas com as gestões às quais pertencem: • Gestão de Usuários - Nesta gestão se encontra a entidade Usuario, responsável pela identificação de usuários que utilizam o sistema, controlando o acesso por níveis de hierarquia; 1 2 Do inglês Structured Query Language. Do inglês Virtual Instrument Software Architecture. CAPÍTULO 3. AS APLICAÇÕES 17 • Gestão de Instrumentos - Responsável pelo armazenamento de todas as informações pertinentes aos instrumentos. Várias são as entidades que compõem esta gestão: – Instrumento: com as características básicas do mesmo; – Proprietário: dono do instrumento; – Fabricante: quem fabricou o instrumento; – ConectorIO: terminais de entrada e saída dos instrumentos; – TipoCommPC: tipo de comunicação com o computador, tal como GPIB, USB, etc.; – CAmbiental: com as condições ambientais recomendadas pelo fabricante para a operação do instrumento. • Gestão de Equações - Diretamente relacionada com a Gestão de Instrumentos, esta gestão possui tabelas responsáveis pela inserção de equações, faixas de medição e variáveis relacionadas ao instrumento. As entidades estão listadas a seguir: – FaixaInst: armazena as faixas de trabalho (medição ou geração) do instrumento; – Mensurando: responsável por armazenar as funções de medição ou geração do instrumento; – Correlação: correlação entre os termos da equação. • Gestão de Variáveis - Para a manipulação de variáveis, que estão relacionadas às equações e medições, foram criadas as seguintes entidades: – Variável: criada para gerir e manipular variáveis; – Mensurando: possui informações das grandezas medidas; – Unidade: unidade física de medição. • Gestão de Procedimentos - Com entidades responsáveis pelos procedimentos de calibração do instrumento. São elas: – SMP: para cadastrar um instrumento padrão; – FaixaProc: faixas do instrumento que serão calibradas; CAPÍTULO 3. AS APLICAÇÕES 18 – EquacaoSMP: armazena equações de medição do instrumento padrão; – FaixaSMP: faixas de medição do instrumento padrão que serão utilizadas na calibração; – CorrSMP: correlação do instrumento padrão com as medidas de outros instrumentos. • Calibração - Possui entidades responsáveis pela calibração propriamente dita: – Relatório: armazena os dados pertinentes à calibração; – ValTermoEq: armazena os valores das variáveis de entrada e seus desvios para a análise de incertezas; – FaixaCalib: armazena um valor da faixa do procedimento de calibração; – InstCalib, ponto e medição: armazenam os valores medidos por todos os instrumentos do procedimento. • Gestão de Certificados - Neste caso de uso, todas as informações de certificados internos e externos serão armazenas nas seguintes entidades: – Certificado: armazena as informações de certificados gerados pelo laboratório, tais como condições ambientais, incertezas de medição, curva de erros entre outras; – CertificadoExt e Laboratório: prove informações sobre instrumentos já calibrados anteriormente, fornecendo dados sobre o certificado e o laboratório responsável. Para exemplificar as relações entre as entidades apresentadas anteriormente, a Figura 3.1 apresenta de forma geral a estrutura das tabelas com as chaves primárias e estrangeiras. Os demais atributos foram omitidos para se reduzir a figura, permitindo uma melhor visualização do banco de dados como um todo. 3.1.3 A interface com o usuário e trabalhos não concluídos Em seu trabalho, Kudo priorizou a modelagem do sistema e a interação com o Banco de Dados desenvolvido. Assim, foram criadas janelas de interface com o usuário para CAPÍTULO 3. AS APLICAÇÕES 19 Fig. 3.1: Estrutura do Banco de Dados desenvolvido por Kudo (2007) [1] e suas relações. a entrada de dados e preenchimento das tabelas deste Banco de Dados. A estrutura destas janelas está totalmente voltada para a aplicação SISCAL, controlando o acesso de usuários e organizando as funções possíveis em itens de menu, cujas funcionalidades são próximas às apresentadas nos casos de uso. A Figura 3.2 apresenta a janela para acesso às principais funcionalidades do SISCAL em sua barra de menus. Acessando cada item de menu, abre-se uma janela correspondendo ao cadastramento e visualização de uma entidade do Banco de Dados. Como uma entidade se relaciona com várias outras, dentro das janelas de cadastramento, novas janelas poderão ser abertas de acordo com a relação existente. A Figura 3.3(a) apresenta o exemplo de CAPÍTULO 3. AS APLICAÇÕES 20 Fig. 3.2: Janela para acesso às principais funcionalidades do SISCAL. uma janela para o cadastro de variáveis no sistema. Nesta janela existe um botão para a inserção de novas unidades ("mais.."), chamando a janela para cadastro de unidades, apresentada na Figura 3.3(b). Nesta aplicação não foram desenvolvidas a comunicação com os instrumentos remotamente e nem a calibração propriamente dita. Para a comunicação com os instrumentos, Kudo criou uma aplicação de teste chamada TesteVisa onde valores são enviados e recebidos pelo instrumento. A continuação do trabalho do aluno inclui: • Integrar na sua aplicação a leitura por visão computacional (foco deste trabalho); • Integrar a comunicação com instrumentos remotos para a leitura e envio de dados; • Desenvolver o algoritmo para realizar a calibração automática de instrumentos de medição. 3.2 O programa de leitura por visão computacional Quando a idéia para o desenvolvimento de um sistema automático para a calibração de instrumentos de medição surgiu em meados de 2005, o desafio de se desenvolver um mecanismo para a leitura de instrumentos de medição, analógicos e digitais, por visão computacional foi proposto ao presente autor como um projeto de iniciação científica. O sistema foi desenvolvido ao longo daquele ano, de forma descompromissada, sendo chamado de OCR3 como analogia à sigla inglesa para o reconhecimento ótico de caracteres. Sem levar em conta sua integração no SISCAL, teve-se apenas a preocupação em se desenvolver uma solução simples, amigável ao usuário e acessível aos recursos 3 Do inglês Optical Caracter Recognition. CAPÍTULO 3. AS APLICAÇÕES 21 (a) Tela de variáveis (b) Tela de unidades Figura 3.3: Telas para cadastro no banco de dados. CAPÍTULO 3. AS APLICAÇÕES 22 existentes. Nesta seção será apresentada esta aplicação, como também os recursos utilizados para sua elaboração. 3.2.1 Os recursos utilizados Para o desenvolvimento da aplicação OCR, importantes recursos computacionais foram utilizados, principalmente para a criação de interfaces gráficas com o usuário e análise e processamento de imagens. Na criação de interfaces gráficas utilizou-se a biblioteca MFC, responsável pela programação visual da maioria das aplicações em janelas disponibilizadas pela Microsoft em seus sistemas operacionais. Para ser utilizada, deveria ser usada uma ferramenta de desenvolvimento de softwares da própria Microsoft Corporation (2008)[14], o Microsoft Visual Studio, em versão não gratuita, e bibliotecas dinâmicas (DLLs) para a execução da aplicação. O processamento de imagens, foi auxiliado com o uso de uma biblioteca gratuita chamada OpenCV (2008)[18] (de Open Computer Vision Library), desenvolvida pela Integrated Electronics Corporation (Intel). Como é de conhecimento comum, a Intel é uma importante empresa fabricante de microprocessadores, os quais possuem rotinas otimizadas, programadas em nível de hardware. O OpenCV surgiu com o intuito de melhor utilizar estes recursos, garantindo performance e consequentemente divulgando os microprocessadores fabricados pela Intel. Atualmente com versões multiplataformas, a biblioteca possui uma grande gama de funções já documentadas e constantemente atualizadas. Como na época em que foi proposto o projeto poucos recursos financeiros estavam disponíveis, o programa foi inteiramente desenvolvido com câmeras de internet (webcams), justamente pelo seu baixo custo de aquisição. 3.2.2 O programa Para se compreender melhor o desenvolvimento do programa e as alterações realizadas neste (apresentadas no capítulo 4), o mesmo foi segmentado em etapas, como descrito no fluxograma da Figura 3.4. Como esta aplicação sofreu muitas alterações, o funcionamento do programa será mais detalhado que o apresentado para o de Kudo (2007)[1]. Nas próximas subsecções, o fluxograma da Figura 3.4 será explicado para cada instru- CAPÍTULO 3. AS APLICAÇÕES 23 mento (digital e analógico), sendo que para maiores detalhes recomenda-se ver Lima et al (2007)[2]. Fig. 3.4: Fluxograma com as etapas realizadas no processo de leitura de instrumentos digitais (à direita) e analógicos (à esquerda ).(LIMA et al, 2007, p. 2)[2] Leitura dos instrumentos digitais: De acordo com o fluxograma da Figura 3.4, o processo de leitura de instrumentos digitais desenvolveu-se em cinco etapas básicas. As duas primeiras, comuns aos instrumentos digitais e analógicos, são responsáveis pela aquisição das imagens do instrumento e delimitação do visor. Como o programa foi desenvolvido para câmeras USB do tipo webcam, a imagem obtida não possui grande resolução e é fortemente suscetível às variações de iluminação do ambiente. Porém, para fins acadêmicos apresentou uma boa qualidade. A delimitação do visor é um dos poucos momentos em que o usuário interfere na aplicação, sendo necessário para definir uma região específica onde estarão os dígitos a serem reconhecidos4 , reduzindo a área de processamento da imagem e veloci4 Esta região é definida como sendo a região de interesse do visor (ROI). CAPÍTULO 3. AS APLICAÇÕES 24 dade de reconhecimento. Na Figura 3.5 está representada uma imagem do instrumento com a região de interesse delimitada em vermelho. Fig. 3.5: Imagem binária representando a região de interesse de um multímetro digital. Com a região de interesse definida, é necessário delimitar os dígitos e aplicar o método de reconhecimento para cada um. Para facilitar a delimitação, a imagem foi transformada em binária (0 ou 1), fazendo com que a região de interesse apresente apenas informações dos números (ver Figura 3.5). A delimitação é feita por análise de histogramas, um para linhas e um para colunas, representando a quantidade de píxeis pretos em cada linha ou coluna de acordo com o histograma. Os limites dos dígitos são definidos nas regiões onde o número de píxeis pretos é próximo de zero nos histogramas (limite inferior). A Figura 3.6 apresenta dois histogramas criados para o número 118,5 com o limite inferior em destaque. Este método de delimitação foi projetado para ser rápido com relação ao processo de reconhecimento como um todo e com a menor ação do usuário. No entanto, esta delimitação acrescenta uma limitação para o sistema, pois se os dígitos forem demasiadamente inclinados, a segmentação dos mesmos não poderá ocorrer como planejado, necessitando-se de uma outra solução para a delimitação e possivelmente aumentando a ação do usuário no processo. Estando com os dígitos delimitados, aplica-se o método desejado para o reconhecimento dos dígitos, que neste caso foi o método dos segmentos ativos. Sabendo que os números digitais são formados em sua maioria por 7 segmentos, de acordo com a Figura 3.7, os números de 0 a 9 podem ser totalmente reconhecidos com facilidade. Ao final, basta compor os dígitos reconhecidos em seqüência e retornar o valor lido. CAPÍTULO 3. AS APLICAÇÕES 25 Fig. 3.6: Histogramas para delimitar os dígitos do número 118,5. Fig. 3.7: Imagem do número 8 e seus 7 segmentos ativos. Leitura dos instrumentos analógicos: Seguindo o fluxograma da Figura 3.4, os primeiros passos para a realização da leitura dos instrumentos analógicos são semelhantes aos apresentados para os instrumentos digitais. Neste caso, a região de interesse do instrumento analógico é definida como a área onde o ponteiro excursiona com a menor interferência possível do fundo de escala e demais elementos impressos no visor do instrumento (ver Figura 3.8). O próximo passo definido pelo fluxograma é o reconhecimento de bordas e transformação em imagem binária. A transformação em imagem binária é necessária por ser pré-requisito das funções que serão utilizadas adiante, sendo também importante por facilitar o processamento da imagem. O reconhecimento de bordas, como descrito em Lima et al (2007)[2], é feito pelo Método de Canny e possui uma implementação no OpenCV (2008)[18]. O resultado de sua utilização está apresentado na figura 3.8. Em seguida, com as bordas definidas, a imagem passará pela Transformada de Hough, responsável pela detecção de prováveis retas na mesma. Como o ponteiro é a única CAPÍTULO 3. AS APLICAÇÕES 26 Fig. 3.8: Imagem binária com as bordas em destaque obtida pelo Método de Canny e sua correspondente região de interesse. (LIMA et al, 2007, p. 2)[2] reta presente na região de interesse, a reta encontrada pela Transformada pode ser tranqüilamente associada ao ponteiro5 . Para finalizar o reconhecimento, é necessário aplicar alguma relação que associe a reta e sua inclinação ao valor apontado. Considerando que as escalas dos medidores analisados são constituídas de divisões iguais, com dois valores da escala e seus respectivos ângulos, é possível mapear toda a escala do instrumento. Em alguns casos, a construção desses instrumentos ocorre de forma simétrica à vertical, o que facilita ainda mais esse raciocínio por ser necessário apenas o ponto inicial de valor 0, já que o valor final pode ser facilmente obtido dessa simetria. A Figura 3.9 exemplifica a simetria do instrumento analógico já com o ponteiro reconhecido em destaque. Fig. 3.9: Simetria de alguns instrumentos analógicos. 5 Em certos casos, parâmetros como comprimento e largura mínimos e número de píxeis podem ser ajustados para melhorar o reconhecimento da reta. CAPÍTULO 3. AS APLICAÇÕES 27 É importante reforçar que o método apresentado na Figura 3.9 necessita que o instrumento esteja perfeitamente alinhado horizontalmente à câmera. Por isso o sistema necessita de uma guia física para controlar a disposição do instrumento sob a câmera. 3.2.3 A interface com o usuário e trabalhos não concluídos Como foi dito na subseção 3.2.1, a interface foi desenvolvida utilizando os recursos da MFC, não podendo ser aproveitada para a integração com a aplicação desenvolvida por Kudo. De acordo com as características de desenvolvimento apresentadas no capítulo 2, o programa SISCAL deverá ser inteiramente desenvolvido com os recursos do .Net. Por isso a interface em MFC não será apresentada e discutida neste capítulo, deixando para o próximo capítulo a discussão da nova interface em .Net. Após o desenvolvimento do sistema ainda faltavam: • Desenvolver um sistema de iluminação robusto às perturbações do ambiente; • Integrar câmeras de maior qualidade ao sistema; • Integrar a aplicação ao SISCAL. O próximo capítulo abordará a integração das aplicações, juntamente com as alterações necessárias para realizá-la. Detalhes aprofundados desta integração poderão ser encontrados nos apêndices A e B. Capítulo 4 A integração das aplicações Tendo em vista as aplicações apresentadas no capítulo 3, o presente capítulo abordará todos os detalhes da integração dessas aplicações. Serão apresentados os recursos adicionais utilizados, as alterações realizadas nos programas e no banco de dados, as funcionalidades adicionadas ao programas e os resultados dessa integração. 4.1 As opções de integração Antes de apresentar a integração adotada para as aplicações, é necessário entender o porquê de se integrar as duas aplicações e como fazer isto. Como foi apresentado no capítulo 3, as aplicações foram desenvolvidas em linguagens de programação diferentes entre si, com recursos de bibliotecas exclusivos para determinada linguagem que requerem uma forma de integração para serem aplicadas em uma outra linguagem. Este é o caso do OpenCV, uma biblioteca desenvolvida inteiramente em C/C++, sem usar os recursos do .Net. Se o programa OCR fosse transformado inteiramente para C#, seria necessário transformar todas as funções do OpenCV para .Net, ou pelo menos criar um wrapper1 para permitir a chamada destas funções. Além da biblioteca OpenCV, qualquer driver de dispositivo (de uma câmera por exemplo) para ser aceito em C# precisaria ser desenvolvido em código gerenciado no C++, ou seja puramente em .Net ou criando-se o wrapper para ele. Assim percebe-se que transformar a aplicação inteiramente em C# seria trabalhoso para o tempo de trabalho estimado para este projeto de final de curso. Outra opção seria 1 Maneira de se englobar as funcionalidades de uma biblioteca e fornecê-las de forma acessível a uma linguagem de programação. O .Net, por exemplo, fornece diversos wrappers em sua composição, sendo um deles apresentado mais adiante neste capítulo. 28 CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 29 transformar a aplicação desenvolvida por Kudo (2007)[1] inteiramente em C++/.Net, o que poderia ser menos penoso, pois basicamente tudo que é referenciável em C# pode ser adicionado em aplicações C++/.Net. Porém, toda a aplicação teria que ser adaptada para a linguagem C++ juntamente com sua interface gráfica e a aplicação OCR também teria que ser alterada para C++/.Net. Uma opção perigosa para o tempo desenvolvimento e funcionalidades que se deseja adicionar à aplicação OCR. A opção escolhida foi alterar a aplicação OCR para C++/.Net e disponibilizá-la na forma de uma biblioteca DLL2 para que possa ser referenciada na aplicação SISCAL. Nesta solução, a interface gráfica referente ao OCR continuará sendo desenvolvida em C++, resultando em poucas alterações na aplicação SISCAL. Lembrando que esta não significa a solução mais viável para a manutenção da aplicação, requisito desejável na engenharia de softwares, como é apresentado por Costa (2001)[19], mas que torna viável o período de trabalho proposto. Assim, juntar as interfaces gráficas em uma única aplicação será deixado para trabalhos futuros. 4.2 Os recursos adicionais Sabendo que a nova aplicação deverá respeitar todas as características apresentadas no capítulo 2, qualquer recurso adicional deve ser capaz de atender todos os requisitos apresentados. Outra característica importante é que qualquer recurso utilizado deve ser totalmente funcional em .Net para garantir a portabilidade entre as aplicações em C# e C++. Respeitando estes preceitos, ao utilizar os recursos do OpenCV para o processamento de imagens no Visual Studio C++ 2005, é necessário o uso do Microsoft Windows SDK3 . O OpenCV possui janelas pré programadas para algumas funções que disponibiliza, sendo essas janelas desenvolvidas com o Windows SDK. Este pacote de desenvolvimento, fornecido pela Microsoft Corporation (2008)[14], permite criar aplicações que utilizam todos os recursos de janelas do Windows, porém de maneira não orientada a objetos e pode ser obtido gratuitamente mediante a validação do sistema operacional vigente na máquina. Como as funções que abrem janelas no OpenCV não são necessá2 3 Do inglês Dynamic Link Library. Do inglês Software Development Kit. Até o Windows Server 2003 esta biblioteca era conhecida como Platform SDK CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 30 rias para a aplicação OCR, esta poderá ser desenvolvida orientada a objetos, utilizando apenas a opção de compilação “CLR não puro” para recursos não gerenciáveis pelo .Net. As janelas da aplicação OCR foram todas criadas utilizando as Windows Forms Application do próprio .Net (ver figura 1.3). Com elas, todos os recursos visuais utilizados com a biblioteca MFC podem ser utilizados e editados de forma gráfica no Visual Studio, mas alterando-se a estrutura do código, resultando no trabalho de se refazer a aplicação. Para a aplicação de visão computacional, também foi adicionada a possibilidade de leitura de imagens por meio das câmeras DragonFly e DragonFly2 da Point Grey Research (2008)[20]. Estas câmeras são capazes de obter imagens com mais opções de regulagem, boa resolução e com maior velocidade, utilizando o barramento IEEE 1394 (também conhecido como Firewire). Por serem câmeras melhor condicionadas, elas apresentam maior robustez a variações no ambiente de aquisição das imagens. A resolução das câmeras utilizadas (tanto USB quanto Firewire) foi temporariamente fixada em 640x480 píxeis. O fato de a resolução ter sido temporariamente fixada está relacionado à precisão da imagem adquirida. Sendo a resolução definida por píxeis por polegada (ppi4 ), quanto maior a resolução, maiores serão os detalhes obtidos na imagem pois se estará aumentando a quantidade de ppi’s. Na leitura dos instrumentos de medição analógicos, o aumento da resolução da câmera melhora o reconhecimento da reta e, conseqüentemente, a precisão de seu ângulo de inclinação, considerando um ambiente de aquisição de imagens controlado. Isto permite que valores entre os reais definidos pela marcação da escala do instrumento sejam reconhecidos, porém sem significar aumento na resolução do instrumento, pois esta é definida de fábrica. O valor fixado para a resolução da câmera mostrou-se suficiente para realizar a leitura dos diversos instrumentos analógicos testados, permitindo inclusive a leitura destes valores interescalares, que poderão ser descartados dependendo da real necessidade para o sistema final. Com esta resolução a aplicação garante uma boa visualização do instrumento e um tempo aceitável para o processamento de cada imagem (menor que 1 segundo). Também com o intuito de melhorar a aquisição das imagens, um sistema de iluminação foi projetado, baseado em Morais (2008)[21], como um recurso adicional ao 4 Do inglês pixels per inch. CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 31 sistema final para evitar interferência com a iluminação do ambiente externo. A Figura 4.1 apresenta este sistema composto por uma caixa com quatro fontes de luz, com paredes inferiores foscas para reduzir o reflexo e a parte superior em branco para aumentar a eficiência da iluminação. Para evitar a incidência direta da luz sobre o visor do instrumento, foi adicionado uma superfície semi-translúcida entre os níveis da caixa com um orifício que permite a leitura pela câmera. A caixa foi dimensionada para comportar diversos tipos de instrumentos e respeitando a distância focal das possíveis câmeras utilizadas. Nesta mesma caixa deverá ser instalado o sistema físico para realizar o alinhamento do instrumento com a câmera, necessário para o reconhecimento dos instrumentos analógicos, como descrito em 3.2.2. Fig. 4.1: Sistema de iluminação projetado para o sistema SISCAL. 4.3 A nova aplicação OCR Como ficou decidido no capítulo 2, a aplicação de leitura de instrumentos por visão computacional deverá ser refeita em C++/.Net, para sua utilização na aplicação desenvolvida por Kudo (2007)[1], futuramente compondo o SISCAL. Porém, simplesmente alterar para .Net não fará com que haja interação entre as aplicações. É necessária uma forma de acesso à aplicação de leitura, permitindo a configuração da leitura de acordo com o instrumento e realizando a leitura a partir de uma requisição do programa hospedeiro, no caso o SISCAL. Isto dá a capacidade para o programa hospedeiro, CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 32 por exemplo, em uma calibração, controlar automaticamente, quando deve ser lido o valor mostrado pelo instrumento a ser calibrado e o padrão, dependendo do modelo de calibração adotado. Para permitir tal controle pelo programa hospedeiro, o programa OCR foi segmentado em 6 funções, disponibilizadas na forma de uma biblioteca DLL. A opção pela biblioteca DLL faz com que o programa possa ser referenciado em qualquer aplicação que suporte o .Net, e não somente na aplicação SISCAL em C#, sendo disponibilizada como uma solução fechada para a leitura de instrumentos de medição. A passagem de parâmetros foi realizada por meio de extensões gerenciáveis do .Net, com o System::Runtime::InteropServices::Out, sendo este capaz de enviar e receber dados. Este é um recurso COM+5 (Component Object Model) incorporado ao .Net. As funções criadas são: • ConfigDigital - Responsável pela configuração do sistema de leitura para os instrumentos digitais, onde todos os parâmetros configurados são retornados para o programa hospedeiro. Esta função também pode ser chamada para visualizar parâmetros previamente configurados. • ConfigAnalogico - Possui funcionalidades semelhantes ao ConfigDigital, mas para os instrumentos Analógicos. • LeInstrumentoDigital - Retorna o valor lido do instrumento digital pela câmera no momento da requisição. Esta função foi desenvolvida para que a leitura fosse mais dinâmica, necessitando apenas dos parâmetros pré-configurados e da câmera estar iniciada. • LeInstrumentoAnalogico - Realiza a mesma tarefa da função LeInstrumentoDigital, mas para instrumentos analógicos. • IniciaCamera - Inicia a câmera responsável pela leitura do instrumento previamente configurado. Esta função precisa estar fora das funções de leitura dos instrumentos pelo fato da inicialização das câmeras normalmente gastar um tempo significativo para estabilizar a imagem com a iluminação ambiente. Assim, o processo de leitura gastaria mais tempo do que o realmente necessário. Estando fora, 5 Padrão criado para prover a interoperabilidade e reusabilidade de componentes (objetos) de software. CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 33 ela poderá ser chamada uma única vez para a leitura de uma seqüência de dados, ou seja, para uma seqüência de chamadas às funções de leitura. • FinalizaCamera - Finaliza a câmera iniciada pela função IniciaCamera. Para uma melhor compreensão de como as funções criadas devem ser utilizadas e quais são os parâmetros necessários para tal, ver Apêndice A. As duas funções de configuração foram desenvolvidas para que permitam a entrada e saída de todos os dados necessários para a configuração da leitura de instrumentos, cabendo ao programa hospedeiro a missão de armazenamento destes dados. A entrada dos dados possibilita visualizar uma configuração já realizada anteriormente e a saída permite armazenar uma nova configuração ou atualizar uma configuração anterior. Como são funções de configuração, foram desenvolvidas novas interfaces com o usuário, que permitem a alteração, de forma amigável, dos parâmetros necessários para o funcionamento da aplicação. Para a melhor visualização nas janelas de configuração das imagens adquiridas e processadas, sua resolução foi interpolada para 320x240 píxeis, não interferindo nas imagens reais processadas em 640x480 píxeis. Na janela de instrumentos digitais, os principais elementos configuráveis são: a escolha da câmera responsável pelas imagens; o limiar para realizar a binarização da imagem; os vértices de delimitação do visor; as condições específicas de inversão da imagem; e a posição da vírgula. Todos os elementos alterados são atualizados em tempo de execução. A Figura 4.2 apresenta a janela principal de configuração dos parâmetros de leitura dos instrumentos digitais. A Janela de configuração da leitura dos instrumentos analógicos, seguindo o mesmo princípio da referente aos instrumentos digitais, possui de forma acessível todos os parâmetros necessários para a leitura, como descritos na seção 3.2. Os parâmetros acrescidos, como escolha do tipo de câmera e modelo do instrumento, também podem ser configurados. Os principais elementos configuráveis são: a escolha da câmera responsável pelas imagens; as duas constantes necessárias pelo Método de Canny; os parâmetros necessários pela Transformada de Hough; o modelo do instrumento; e valores previamente reconhecidos para viabilizar o reconhecimento dos demais. Na figura 4.3 está a janela principal para configuração da leitura dos instrumentos analógicos. Como esta nova aplicação OCR foi desenvolvida para aceitar câmeras USB e modelos DragonFly, a escolha entre o tipo das câmeras é feita através de uma janela de diálogo. CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 34 Fig. 4.2: Janela para configuração da leitura de instrumentos digitais. Apertando o botão “Câmera”, presente em ambas as janelas de configuração, aparecerá a janela de seleção da figura 4.4. Confirmando-se o tipo de câmera, a lista de câmeras conectadas ao computador é exibida em outra janela para a seleção. Outro acréscimo, já mencionado anteriormente, foi a leitura de mais modelos de instrumentos analógicos de escala lineares, além dos simétricos. São 4 os modelos aceitos, sendo selecionados através da janela apresentada na figura 4.5, aberta após pressionar o botão “Modelo” na tela principal de configuração dos instrumentos analógicos. 4.4 A integração com a aplicação SISCAL6 Com a biblioteca para realizar a leitura dos instrumentos criada, é necessário referenciála na aplicação desenvolvida por Kudo (2007)[1]. Porém, para que suas funcionalidades sejam totalmente aplicáveis, armazenando as informações da última configuração 6 Aplicação desenvolvida por Kudo (2007). CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 35 Fig. 4.3: Janela para configuração da leitura de instrumentos analógicos. da leitura para cada instrumento e fornecendo-as sempre que necessário realizar uma nova leitura, o banco de dados da aplicação SISCAL foi alterado. Assim, criaram-se duas novas tabelas, a PropriedadesCamera e AnguloValor, desenvolvidas com auxílio da aplicação DBDesigner 4 da FabForce (2008)[15]. A primeira, PropriedadesCamera, é responsável pelo armazenamento de todas as propriedades com valores únicos da leitura dos instrumentos digitais e analógico. É uma tabela extensa, porém única para cada instrumento sem interface com o computador, ou seja, uma relação de 1x1 com a tabela instrumento. A segunda, AnguloValor, como o próprio nome diz, é responsável por armazenar ângulos de leitura e valores apontados pelos instrumentos analógicos, predeterminados na configuração pelo usuário. Estes valores são necessários para realizar operações de regressão linear ou regra de três, dependendo do modelo de instrumento analógico selecionado e determinar o valor lido CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 36 Fig. 4.4: Janela de seleção do tipo de câmera. Fig. 4.5: Janela de seleção do modelo do instrumento analógico. através do ângulo reconhecido. Sua relação com a tabela de PropriedadesCamera é Nx1. A figura 4.6 apresenta as duas tabelas criadas e suas relações com a tabela instrumento. Para um melhor detalhamento dos elementos que compõem estas tabelas, ver Apêndice B. Para finalizar a integração, as funções da biblioteca OCR precisam ser chamadas a partir da aplicação SISCAL em pontos específicos do programa. Como a aplicação SISCAL desenvolvida por Kudo não está completa, somente as duas funções de configuração de leitura puderam ser chamadas. Elas foram adicionadas nas janelas de cadastro, remoção e visualização de instrumentos. A figura 4.7 apresenta a janela de cadastro de novos instrumentos com o botão “Configurar Câmera” habilitado. Caso a opção de comunicação com o computador esteja selecionada, o botão será desabilitado. Como a aplicação de leitura é diferente para os instrumentos digitais e analógicos, ao se pres- CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES 37 Fig. 4.6: Tabelas “PropriedadesCamera” e “AnguloValor” e suas relações com a tabela “Instrumento”. sionar o botão “Configurar Câmera” uma janela de seleção será exibida para dizer se o instrumento é digital ou analógico e assim chamará a janela de configuração correspondente. Uma vez configurada a leitura, ao se pressionar novamente o botão, este abrirá diretamente a janela de configuração para a visualização dos parâmetros e possível alteração dos mesmos. Confirmando o cadastro do instrumento, os parâmetros de leitura por visão computacional serão salvos no banco de dados, podendo ser acessados sempre que necessário Já que nem todas as funções desenvolvidas para a biblioteca OCR puderam ser verificadas na atual aplicação SISCAL, uma aplicação de teste foi criada em C#/.Net para a rápida visualização e teste das mesmas. Nesta aplicação, a biblioteca OCR foi referenciada como no SISCAL, com todas as funcionalidades sendo utilizadas e atingindo todos os objetivos propostos para a integração das aplicações. CAPÍTULO 4. A INTEGRAÇÃO DAS APLICAÇÕES Fig. 4.7: Nova janela para o cadastro de instrumentos do programa SISCAL. 38 Capítulo 5 Conclusão Requisitos são funcionalidades necessárias a serem seguidas quando se pretende atender plenamente o funcionamento de um novo produto, sendo importante defini-los com clareza para viabilizar sua concepção. O programa SISCAL foi vislumbrado por professores do Departamento de Engenharia Elétrica da UFMG e aos poucos foi sendo desenvolvido e tomando a forma necessária para atender uma série de requisitos de funcionamento. O primeiro trabalho nesta direção foi o de João Felipe Kudo, que efetuou a análise de requisitos para o SISCAL e esboçou suas principais funcionalidades e o seu banco de dados. No presente trabalho, foi importante ter todos estes conceitos bem fundamentados para que fosse possível dar continuidade à aplicação desenvolvida anteriormente por Kudo. Mostrou-se ser plenamente possível integrar duas aplicações distintas quando estas atendem a requisitos preestabelecidos. As aplicações foram desenvolvidas em diferentes linguagens de programação, C++ e C#, o uso do .Net como framework de desenvolvimento mostrou-se eficaz para se realizar a integração entre elas. Como a aplicação de leitura de instrumentos de medição por visão computacional precisou ser refeita, esta pôde ser melhorada, acrescentado funcionalidades antes deixadas como trabalhos futuros na primeira implementação da aplicação OCR. Um novo sistema de aquisição de imagens foi incorporado, juntamente com um projeto de iluminação visando uma melhoria na obtenção das imagens do visor do instrumento. A nova aplicação OCR também foi expandida para ser capaz de ler mais modelos de instrumentos analógicos com escala linear, passando para 4 modelos no total. Para tornar a aplicação plenamente aplicável não somente na aplicação SISCAL, mas em qualquer aplicação em que se deseje realizar a leitura de instrumentos de medição, a 39 CAPÍTULO 5. CONCLUSÃO 40 nova aplicação OCR foi totalmente desenvolvida como uma biblioteca DLL, facilmente referenciável por qualquer aplicação .Net. O seu funcionamento se dá com apenas 6 funções, que garantem total acessibilidade aos recursos da aplicação. Os resultados finais obtidos conseguem cumprir todos os objetivos propostos inicialmente. Cada uma das 6 funções foi testada, respondendo de acordo com o proposto para elas. O código fonte do programa OCR foi totalmente comentado e detalhado para facilitar a utilização por futuros interessados em dar continuidade ao trabalho. Para os trabalhos futuros foram deixados: • finalizar da aplicação SISCAL para realizar a calibração automática de instrumentos de medição, geração de relatórios e gerenciamento de procedimentos de calibração; • centralizar a interface gráfica do programa em uma única linguagem de programação; • construir o sistema de iluminação projetado. Apêndice A As funções Como foi apresentado no capítulo 4, a aplicação OCR foi adaptada para 6 funções desenvolvidas em uma biblioteca DLL para que qualquer programa que deseje realizar a leitura de instrumentos de medição elétrica por visão computacional possa utilizá-las. Neste apêndice tem-se por objetivo expor todos os parâmetros necessários para se usar essas funções e como elas devem ser operadas. Foram criadas duas funções de configuração e duas para a leitura, sendo uma para cada tipo instrumento (analógico e digital). Também foram criadas funções para inicializar e finalizar uma câmera. Para o correto funcionamento da biblioteca, todas as funções devem ser chamadas com variáveis definidas e inicializadas no programa hospedeiro. No programa SISCAL, foi incorporada uma classe chamada Propriedades, a qual possui todos os parâmetros necessários para cada função. Chamando seu método construtor, todos os parâmetros são inicializados com os valores padrão, podendo ser alterados posteriormente por valores armazenados em banco de dados ou pelas funções da biblioteca. A primeira função de configuração é a ConfigDigital, que recebe os seguintes parâmetros em ordem: • coordX1, coordY1, coordX2 e coordY2 - Coordenadas inteiras X e Y referentes à delimitação da região de interesse da imagem; • delimitado - Condição booleana para dizer se o instrumento já foi delimitado (igual a 1) ou não (igual a 0); • tshold1 - Valor inteiro (0 a 255) do Threshold que será aplicado na imagem a ser binarizada; 41 APÊNDICE A. AS FUNÇÕES 42 • inversao - Condição booleana para dizer se a binarização será invertida (igual a 1) ou não (igual a 0); • invimagem - Condição booleana para dizer se a imagem será invertida horizontalmente (igual a 1) ou não (igual a 0); • pos_virgula - Número inteiro (0 a 6) para definir a posição da virgula do valor numérico reconhecido, de acordo com a equação A.1; • CameraSelecionada - Número inteiro da câmera USB selecionada no barramento ou do serial da câmera DragonFly selecionada. O valor negativo -1 significa que nenhuma câmera foi selecionada; • TipoCamera - Condição booleana para dizer se a câmera é USB (igual a 1) ou DragonFly (igual a 0). valor_real = valor_reconhecido × 10−(pos_virgula) (A.1) A próxima função, também de configuração, é a ConfigAnalogico, que recebe os seguintes parâmetros em ordem: • coordX1, coordY1, coordX2 e coordY2 - Coordenadas inteiras X e Y referentes à delimitação da região de interesse da imagem; • delimitado - Condição booleana para dizer se o instrumento já foi delimitado (igual a 1) ou não (igual a 0); • tshold1 - Valor para o Threshold 1 do Método de Canny para a detecção de bordas; • tshold2 - Valor para o Threshold 2 do Método de Canny para a detecção de bordas; • nplinha - Valor inteiro do mínimo de pontos necessários para se ter uma linha (1 a 254); • compreta - Valor inteiro do comprimento mínimo da reta (1 a 400); • largreta - Valor inteiro máximo da largura da reta (1 a 400); APÊNDICE A. AS FUNÇÕES 43 • invimagem - Condição booleana para dizer se a imagem será invertida horizontalmente (igual a 1) ou não (igual a 0); • extmedidor - Extensão do instrumento analógico a se lido; • tipomedidor - Valor inteiro (0 a 3) representando o modelo do instrumento analógico (ver Figura 4.5); • reconhece - Condição booleana para dizer se o reconhecimento está habilitado (igual a 1) ou não (igual a 0); • contador - Valor inteiro com o número de valores e ângulos inseridos pelo usuário; • Angulo e Valor - Vetores com ângulos e seus respectivos valores de leitura definidos pelo usuário. A dimensão desses vetores é igual ao contador; • CameraSelecionada - Número inteiro com o número da câmera USB selecionada no barramento ou o com o número do serial da câmera DragonFly selecionada; • TipoCamera - Condição booleana para dizer se a câmera é USB (igual a 1) ou DragonFly (igual a 0). Todos os parâmetros das funções ConfigDigital e ConfigAnalogico podem ser alterados internamente dentro das funções, porém somente serão retornados ao programa hospedeiro mediante a confirmação do usuário, pelo botão “Confirmar” (ver Figuras 4.2 e 4.3). A inicialização da câmera é feita pela função IniciaCamera, mediante dois parâmetros definidos em um dos métodos de configuração (ConfigDigital e ConfigAnalogico). Eles não são alterados internamente na função e por isso não são retornados. Os parâmetros em ordem são: • CameraSelecionada - Número inteiro com o número da câmera USB selecionada no barramento ou o com o número do serial da câmera DragonFly selecionada; • TipoCamera - Condição booleana para dizer se a câmera é USB (igual a 1) ou DragonFly (igual a 0). APÊNDICE A. AS FUNÇÕES 44 A função oposta para finalizar a câmera inicializada é chamada FinalizaCamera e não recebe parâmetros. Esta função pressupõe que somente existe uma câmera inicializada, sendo responsabilidade do programa hospedeiro chamar uma única vez as funções IniciaCamera e FinalizaCamera. Para a leitura direta dos instrumentos sem abrir a janela de configuração criou-se as funções LeInstrumentoDigital e LeInstrumentoAnalogico. Estas funções pressupõem que a câmera responsável pela leitura já está iniciada. Os parâmetros da função LeInstrumentoDigital em ordem são: • coordX1, coordY1, coordX2, coordY2, delimitado, tshold1, inversao, invimagem e pos_virgula - Parâmetros pré-definidos pela função ConfigDigital, cujos valores são constantes; • Reconhecido - Retorno booleano para dizer se o dígito foi reconhecido (igual a 1) ou não (igual a 0); • ValorReconhecido - Retorno do valor reconhecido pela função. A função LeInstrumentoAnalogico necessita dos seguintes parâmetros em ordem: • coordX1, coordY1, coordX2, coordY2, delimitado, tshold1, tshold2, nplinha, compreta, largreta, invimagem, extmedidor, tipomedidor, reconhece, contador, Angulo e Valor - Parâmetros pré-definidos pela função ConfigAnalogico, cujos valores são constantes; • Reconhecido - Retorno booleano para dizer se o valor indicado pelo ponteiro foi reconhecido (igual a 1) ou não (igual a 0); • ValorReconhecido - Retorno do valor reconhecido pela função. Com as 6 funções definidas, cabe ao programa hospedeiro chamá-las corretamente, dependendo do que se deseja realizar. O fluxograma da Figura A.1 apresenta a seqüência para a chamada dessas funções. APÊNDICE A. AS FUNÇÕES 45 Fig. A.1: Fluxograma exemplificando a seqüência de chamada das funções da biblioteca OCR. Apêndice B As tabelas novas De acordo com o capítulo 4, foram criadas duas tabelas novas para o gerenciamento das configurações de leitura dos instrumentos digitais e analógicos. Isto possibilita ao programa SISCAL o armazenamento das informações de configuração e acesso sempre que necessário para realizar a leitura de um instrumento ou até mesmo visualizar e alterar uma configuração. Para o melhor entendimento de seus elementos, as tabelas PropriedadesCamera e AnguloValor serão detalhadas neste apêndice. Como a aplicação OCR é responsável pela a leitura tanto de instrumentos digitais quanto analógicos, a tabelas de banco de dados devem ser capazes de atender a ambos. Sendo grande parte das configurações semelhantes entre eles, optou-se por fazer uma tabela comum para as propriedades que só possuem um único valor, a tabela PropriedadesCamera. A distinção entre qual é o tipo de instrumento que estas propriedades se relacionam será feita pela entidade Digital, como será apresentado a seguir com os demais elementos da tabela, listados na ordem em que aparecem na Figura 4.6: • idPropriedadesCamera e instrumento - Identificador da tabela ProriedadesCamera e de seu respectivo instrumento, compondo a chave primária da tabela. Esta relação é de 1:1 (leia-se um para um), por ser permitido apenas um conjunto de propriedades por instrumento; • coordX1, coordY1, coordX2 e coordY2 - Coordenadas inteiras X e Y referentes à delimitação da região de interesse da imagem, comum para instrumentos digitais e analógicos; • delimitado - Condição booleana para dizer se o instrumento já foi delimitado (igual a 1) ou não (igual a 0), comum para instrumentos digitais e analógicos; 46 APÊNDICE B. AS TABELAS NOVAS 47 • tshold1 - Valor inteiro (0 a 255) do Threshold aplicado na imagem a ser binarizada no caso de instrumento digital, ou valor do Threshold 1 do Método de Canny para a detecção de bordas do instrumento analógico; • tshold2 - Valor do Threshold 2 do Método de Canny para a detecção de bordas do instrumento analógico; • inversao - Condição booleana para dizer se a binarização é invertida (igual a 1) ou não (igual a 0) nos instrumentos digitais; • pos_virgula - Número inteiro (0 a 6) para definir a posição da vírgula do valor numérico reconhecido nos instrumentos digitais; • nplinha - Valor inteiro do mínimo de pontos necessários para se ter uma linha (1 a 254) nos instrumentos analógicos; • compreta e largreta - Valor inteiro do comprimento mínimo (1 a 400) largura da reta (1 a 400); • Reconhece - Condição booleana para dizer se o reconhecimento está habilitado (igual a 1) ou não (igual a 0), para os instrumentos analógicos; • Contador - Valor inteiro com o número de valores e ângulos do instrumento analógico inseridos pelo usuário; • CameraSelecionada - Número inteiro com o número da câmera USB selecionada no barramento ou o com o número do serial da câmera DragonFly selecionada, para ambos os tipos de instrumentos; • Digital - Condição booleana para definir se estas configurações são referentes a instrumentos analógicos (igual a 0) ou digitais (igual a 1); • TipoCamera - Condição booleana para dizer se a câmera é USB (igual a 1) ou DragonFly (igual a 0), para ambos os tipos de instrumentos; • invimagem - Condição booleana para dizer se a imagem é invertida horizontalmente (igual a 1) ou não (igual a 0), para ambos os instrumentos. APÊNDICE B. AS TABELAS NOVAS 48 A segunda tabela, AnguloValor, é exclusiva dos instrumentos analógicos, podendo receber várias combinações de ângulos e valores apontados, sendo então relacionada com a tabela PropriedadesCamera de N:1 (leia-se N para 1). Seus elementos, de acordo com a Figura 4.6, são: • idAnguloValor, instrumento e idPropriedadesCamera - Identificadores da tabela AnguloValor e sua respectiva propriedade; • Angulo - Ângulo da leitura inserido; • Valor - Valor da leitura inserido. Utilizando-se os elementos de acordo com suas especificações anteriormente apresentadas, o acesso ao banco de dados permite total manipulação e armazenamento das configurações realizadas para a leitura dos instrumentos digitais e analógicos. Referências [1] KUDO, J. F. Sistema Automatizado Para Calibração de Instrumentos Elétricos de Medição. Projeto de Final de Curso (Graduação) | Escola de Engenharia da Universidade Federal de Minas Gerais, Belo Horizonte, MG, (2007). [2] LIMA, D. A., PEREIRA, G. A. S., and VASCONCELOS, F. H. Visão Computacional para Leitura do Dispositivo Mostrador de Instrumentos de Medição. Seminário Internacional de Metrologia Elétrica, Belo Horizonte, Set. (2007). Anais do 7o Seminário Internacional de Metrologia Elétrica (VIII Semetro), 2007. p. 1-4. [3] ABNT NBR ISO/IEC 10012-2. Requisitos da garantia da qualidade para equipamentos de medição: Parte 2: Diretrizes para controle de processos de medição. ABNT, Rio de Janeiro, (1999). [4] SALLUM, A. T. Sistema Automatizado Para Calibração de Instrumentos Multifuncionais de Medição. Dissertação (Mestrado) | Escola de Engenharia da Universidade Federal de Minas Gerais, Belo Horizonte, MG, (2002). [5] DIAS, J. L. M. Medida, Normalização e qualidade: Aspectos da história da metrologia no Brasil. Ilustrações, Rio de Janeiro, (1998). 282 p. [6] INMETRO Instituto Nacional de Metrologia Normalização e Qualidade Industrial. Disponível em: http://www.inmetro.gov.br/. Acesso em: 7 mai. 2008. [7] PIEPER, J. M. Automatic Measurement Control: A tutorial on scpi and Rohde Schwarz GmbH Co, Munchen, (2004). 295 p. IEEE 488.2. [8] HAYWARD, J. D. Tattl the automated thermal test lab. Semiconductor Thermal and Temperature Measurement Symposium, 1988. SEMI THERM IV, Fourth Annual IEEE, Sunnyvale, Feb. (1988). p. 153-158. [9] KOEMAN, H. Modular electronic instrument system having automated calibration capability. United States Patent, (1990). [10] MAIA, G. C. G., MARTINS, J. A. S., BARROS, A. R. F., SILVA, J. F., and SANTOS, S. C. A. Website, Set. 2003. Disponível em: http://www.ctgas.com.br/informacoes/publicacoes/ desenvolvimento_software.pdf. Acesso em: 28 Mar. 2008. [11] FOIATTO, N., ROECHE, J., and CASTRO, M. Sistema automatizado de calibração para medidores digitais a partir da captura de imagens e interface de comunicação GPIB (IEEE 488). Seminário Internacional de Metrologia Elétrica, Rio de Janeiro, Set. (2005). 332 p. 49 REFERÊNCIAS 50 [12] ALEGRIA, F. C. Calibração automática de aparelhos de medida. Tese de Mestrado | Universidade Técnica de Lisboa, Out. (1997). [13] MENDES, L. T. S. Técnicas de Integração de Dados em Automação Industrial. Universidade Federal de Minas Gerais, Belo Horizonte, (2008). Notas de aula. [14] MICROSOFT CORPORATION. Disponível em: http://support.microsoft.com/. Acesso em: 9 de mai. de 2008. [15] FABFORCE - DBD ESIGNER 4. Disponível em: http://fabforce.net/dbdesigner4/. Acesso em: 25 de ago. de 2008. [16] MYSQL B RASIL. Disponível em: http://www.mysqlbrasil.com.br/. Acesso em: 25 de ago. de 2008. [17] IVI F OUNDATION. Disponível em: http://www.ivifoundation.org/. Acesso em: 30 de ago. de 2008. [18] O PEN CV - O PEN C OMPUTER V ISION L IBRARY (2008). Disponível em: http://www.intel.com/technology/computing/opencv/. Acesso em: 20 de set. de 2008. [19] Costa, C. G. A. Desenvolvimento e avaliação tecnologica de um sistema de prontuario eletronico do paciente, baseado nos paradigmas da World Wide Web e da engenharia de software. Dissertação (Mestrado) | Faculdade de Engenharia Eletrica e de Computação da Universidade Estadual de Campinas, Campinas, SP, (2001). [20] P OINT G REY R ESEARCH I NC . (2008). Disponível em: http://www.ptgrey.com/. Acesso em: 17 de out. de 2008. [21] MORAIS, G. E. Sistema Automatizado de Inspeção Óptica de Displays (LCD). Projeto de Final de Curso (Graduação) | Escola de Engenharia da Universidade Federal de Minas Gerais, Belo Horizonte, (2008).