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).