caracterizaao fisica do leite condensado

Prévia do material em texto

Revista Engenho, vol.9 – Junho de 2014 
 
 
EDITORIAL 
O objetivo do artigo intitulado A Importância Da Qualidade No 
Desenvolvimento De Software de Cristiane Candido Pereira, Carlos Eduardo Câmara e 
Peter Junior Jandl é o de mostrar através de estudo de caso e aplicação de testes que a 
qualidade do produto é algo extremamente importante, mas o fato é que, garantindo-se a 
qualidade do processo é que se pode adquirir a qualidade no produto. 
O artigo Monitoramento De Vibrações Em Mancais Com Acelerômetro de 
Jefferson Peró Ormonde, Valter Roberto Pinesi e Mario Mollo Neto descreve o 
desenvolvimento de um protótipo microprocessado que diagnostica vibrações de 
sistemas movimentados por motores elétricos fornecendo informações importantes para 
a manutenção preditiva. 
Vanderlei Inácio de Paula e Denis Rafael de Souza Lima no artigo Uso De 
Análise De Imagens Para Quantificação De Compostos utilizam um celular Samsung 
Galaxy fit para obter imagens e analisá-las no programa de código aberto ImageJ (v 
1.47) desenvolvido por Wayne Rasband em plataforma Java. Os autores propõem o uso 
desta metodologia para a quantificação de espécies presentes em água e efluentes, em 
métodos baseados em reações químicas desde que seja possível a formação de cor pelos 
reativos em análise 
 Influência Dos Tratamentos Superficiais Na Adesão De Polipropileno, 
Utilizando Adesivo Base Poliuretano de Fernando Beltrame Costa, Hipólito Alberto 
da Silva Gomes e Ailton Cavalli avaliam o comprotamento do adesivo a base de 
poliuretano em substratos de polipropileno, termosplastico quimicamente inerte, os 
autores concluem que a adesao pode aumetar e 451% se a superfície do substrato for ser 
limpa e preparada com primer. 
Caroline Patrícia Bedim e Juliano José Fiori no artigo Caracterização Física De 
Amostras De Leite Condensado Comercializadas Em Jundiaí-Sp comparam cinco 
marcas de leite condensado analisando as propriedades: teor de sólidos solúveis – °Brix, 
viscosidade aparente e identificação de cristais. Os autores concluem que houve uma 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
relativa variação entre amostras de diferentes marcas e que as amostras analisadas 
possuem pouca quantidade de cristais aparentes e perceptíveis pelo tato bucal 
Uma revisão, sobre a microtoxina aflatoxina, assim como os estudos realizados 
para desenvolver métodos eficazes no combate a esta microtoxina no Brasil e no 
mundo, é escrita por Conceição Batista da Silva e Jonh Dalton de Castro Martins no 
artigo Aflatoxina em Amendoin 
 
Ailton Cavalli 
Editor 
 
ÍNDICE 
 
A IMPORTÂNCIA DA QUALIDADE NO DESENVOLVIMENTO DE SOFTWARE 
 1 
 
MONITORAMENTO DE VIBRAÇÕES EM MANCAIS COM ACELEROMETRO 
 27 
 
USO DE ANÁLISE DE IMAGENS PARA QUANTIFICAÇÃO DE COMPOSTOS 
63 
 
INFLUÊNCIA DOS TRATAMENTOS SUPERFICIAIS NA ADESÃO DE 
POLIPROPILENO, UTILIZANDO ADESIVO BASE POLIURETANO. 
78 
 
CARACTERIZAÇÃO FÍSICA DE AMOSTRAS DE LEITE CONDENSADO 
COMERCIALIZADAS EM JUNDIAÍ-SP 
91 
 
AFLATOXINA EM AMEDOIM 
105 
 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
A IMPORTÂNCIA DA QUALIDADE NO DESENVOLVIMENTO 
DE SOFTWARE 
CRISTIANE CANDIDO PEREIRA 
Centro Universitário Padre Anchieta 
Ane.cpereira@gmail.com 
 
CARLOS EDUARDO CÂMARA 
Centro Universitário Padre Anchieta 
ccamara@anchieta.br 
 
PETER JUNIOR JANDL 
Centro Universitário Padre Anchieta 
pjandl@anchieta.br 
 
RESUMO 
Qualidade no desenvolvimento de software é relacionada ao antecipar, satisfazer, estar 
em conformidade com os requisitos necessários para o cliente, porem não basta ela 
existir, ela deve também ser reconhecida pelo cliente. Para isso acontecer, não é apenas o 
ato de desenvolver um software, este deve seguir regras, normas ou padrões, o 
desenvolvedor precisa entender que o problema não está no software em si, mas sim na 
forma como ele é desenvolvido, que é preciso aplicar os conceitos de qualidade. O 
objetivo da presente pesquisa é o de mostrar através de estudo de caso e aplicação de 
testes que a qualidade do produto é algo extremamente importante, mas o fato é que, 
garantindo-se a qualidade do processo é que se pode adquirir a qualidade no produto. 
Palavras-Chave: engenharia de software; qualidade de software; testes de software. 
 
ABSTRACT 
Quality in software development is related to anticipate, satisfy, 
comply with the requirements for the client, however it simply does 
not exist, it must also be recognized the client. For this to happen, not 
just develop software, this must follow rules, norms or standards, the 
developer needs to understand that this problem is not the software 
itself, but in how it is developed, it is necessary to apply the concepts 
of quality. The objective of this research is to show product quality is 
extremely important, but the fact is, that ensuring the quality of the 
process is that one can acquire quality product. 
Keywords: software engineering; software quality; software testing. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
 
 
 
 
 
 
 
 
INTRODUÇÃO 
Atualmente as empresas desenvolvedoras de software buscam um objetivo comum que é 
produzir software com alto nível de qualidade. A preocupação com a qualidade deixou de ser 
um diferencial competitivo e passou a ser um pré-requisito básico para participação ativa no 
mercado, afinal um único sistema é capaz de integrar todos os departamentos de uma empresa e 
o cliente deseja um sistema que traga solução rápida e eficiente. ”A importância de um projeto 
de software pode ser definida com uma única palavra – Qualidade” (Pressman, 2006). 
É exatamente nesse contexto que a engenharia de software tem ganho espaço dentro das 
empresas, contribuindo com métodos, ferramentas e metodologias avançadas para obter maior 
nível de qualidade. Ela muda continuamente à medida que novos métodos, melhores análises e 
o mais amplo entendimento evolui, aprimorando o projeto. 
Segundo Paula (2009) “O que decide a qualidade é a comparação com os respectivos 
requisitos: O confronto entre a promessa e a realização de cada produto”, porém qualidade é 
algo relativo. O que é qualidade para uma pessoa pode ser uma falha para outra. Por esse 
relativismo que atender os requisitos do cliente é importante e para que a qualidade seja 
alcançada são utilizadas técnicas como validação e verificação de software e testes de sistema 
que são imprescindíveis para atingir a qualidade no software. 
A qualidade no software utilizando dessas técnicas traz benefícios a empresa como aumento da 
produtividade, reduz os possíveis defeitos no sistema, o retrabalho é menor e o índice de 
satisfação do cliente maior. Não basta que a qualidade exista, ela deve ser reconhecida pelo 
cliente. 
A qualidade de software se inicia no levantamento de requisitos que é uma parte de grande 
importância no desenvolvimento, segundo Mello “é entender aquilo que o cliente deseja ou o 
que o cliente acredita que precisa e as regras do negocio ou processos do negocio” , pois é 
desse ponto que se inicia a qualidade de um software. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Partindo dessa necessidade de conhecer essas técnicas, neste trabalho foram realizadas análises 
com bases em pesquisas procurando focar nos processos de verificação, validação e teste de 
software. Com o objetivo e a intensão de mostrar quais procedimentos devem ser tomados, 
quais opções existem e como podem ser realizados e apresentando estudo de caso utilizando 
como base essaanálise, aplicando algumas opções e procedimentos que foram pesquisados, 
apresentados e aplicados. 
VALIDAÇÃO E VERIFICAÇÃO DE SOFTWARE 
“A validação tem como finalidade verificar se o sistema está de acordo com sua especificação. 
Se o sistema atende ás expectativas do cliente, ou seja, a validação avalia se a construção 
segue os requisitos pré-estabelecidos” (Kosciansk, 2006). 
A verificação se refere aos conjuntos de atividades para garantir que o software seja 
implementado corretamente, ela identifica defeitos e possíveis problemas. 
“Esses processos envolvem verificar por meio de inspeção e revisão, em cada estágio, desde a 
definição dos requisitos dos usuários até o desenvolvimento do programa “(Sommerville, 
2003). 
Essa atividade pode utilizar técnicas propostas pela norma IEEE (Institute of Eletrical and 
Eletronics Engineers) Standard for Software Test Documentation STD 829 – 1998, que é uma 
terminologia padrão de Engenharia de Software e com ela é possível identificar as tarefas 
mínimas e documentos recomendados para cada nível de integridade de software. 
Nível de integridade pode ser entendido como criticidade e complexidade do software. 
A utilização dos documentos de teste facilita na padronização e organização da execução do 
processo além de facilitar o trabalho do testador, existem várias formas de criar esses 
documentos, podem ser encontrados modelos em site como IEEE. 
Essa norma descreve oito documentos para a atividade de teste de um programa de software, 
esses documentos são usados em três áreas: no planejamento (Plano de teste), na execução 
(Especificação de teste) e nos relatos (Relatórios de teste). 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Plano de Teste: Identifica as funcionalidades a serem testadas com ênfase nas 
datas, pessoas envolvidas e riscos. A figura 1 mostra algumas informações básicas para 
um plano de teste, a tabela foi criada através dos modelos IEEE. 
 
Figura 1. Plano de Teste (tabela desenvolvida através dos modelos IEEE) 
Especificação de Teste: “As especificações de teste são artefatos que contêm os 
detalhes dos testes a serem realizados. Uma especificação é reaproveitada quando 
testes similares e são realizados de diferentes marcos de um projeto. Tipicamente uma 
especialização é desenhada apenas uma vez, mas o teste que ela descreve pode ser 
executado muitas vezes” (Paula, 2009). A figura 2 mostra uma estrutura para o relatório 
de especificação, com as informações a serem preenchidas de acordo com as 
especificações, conforme o modelo IEEE. 
 
Figura 2. Especificação de Teste (tabela desenvolvida através dos modelos do site IEEE) 
Conforme Blanco (2012) “Especificação Projeto de Teste: Identifica os casos, os 
procedimentos e critérios de aprovação. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Especificação Casos de Teste: Dados de entrada, resultados esperados, ações e condições 
gerais para executar o teste, o que interessa nesse caso é o que é obtida no final, a 
confiabilidade depende da qualidade do teste. 
Especificação de Procedimento de Teste: Identifica quais passos são seguidos para executar o 
teste. 
Relatório de Incidente: Documenta qualquer evento que ocorra durante a atividade de teste e 
que necessite de análise posterior (erros). A figura 3 mostra um modelo de estrutura e 
informações necessárias para preenchimento, conforme o modelo IEEE. 
 
Figura 3. Relatório de Incidente (tabela desenvolvida através dos modelos do site IEEE) 
Relatório de Resumo: Mostra um resumo dos resultados das atividades associados à 
especificação projeto de teste. A figura 4 mostra as informações que podem ser usadas como 
preenchimento do relatório de teste conforme o modelo IEEE. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 4. Relatório de Teste (tabela desenvolvida através dos modelos do site IEEE) 
 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Diário de teste: Registro cronológico dos dados relevantes. 
Relatório de Encaminhamento de Item: Identifica os itens encaminhados para testes no caso de 
equipes distintas serem responsáveis pelas tarefas ”. 
Visando facilitar a documentação, pode ser feita uma união dos documentos de Plano de Teste, 
Especificação de Teste, Especificação de Projeto de Teste e Especificação dos Casos de Teste. 
De acordo com Myers, citado por Blanco (2012)” Infelizmente não é possível testar todas as 
entradas de dados e suas centenas ou milhares de combinações possíveis. Criar casos de testes 
para todas essas possibilidades é impraticável, pois levaria muito tempo e seria 
economicamente inviável “. 
A verificação e validação revisam e analisam o software nas diversas fases dos processos de 
desenvolvimento, abrangem nos documentos de requisitos, os diagramas de análise de projetos 
e o próprio código fonte, as revisões são consideradas técnicas estáticas por não envolverem a 
execução do produto. 
TESTES DE SOFTWARE 
Teste é uma atividade fundamental para a qualidade ser assumida no software, o principal 
objetivo é revelar falhas, um teste bem sucedido identifica defeitos que ainda não foram 
descobertos e que podem ser corrigidos pelo programador, um teste bem eficiente é aquele que é 
projetado para descobrir o maior número de erros possíveis. 
Segundo Sommerville (2003), “teste de software consiste em um processo que é utilizado com o 
intuito de descobrir evidencias de problemas de software”. 
Para definir essas evidencias, é preciso saber as diferenças dos conceitos relacionados aos testes, 
conforme Dias (2007): 
“Defeito: É um ato inconsistente cometido por um individuo ao tentar entender uma 
determinada informação, resolver um problema ou utilizar um método ou uma ferramenta, 
exemplo uma instrução ou comando incorreto. 
Erro: É uma manifestação concreta de um defeito num artefato de software, diferença entre o 
valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado 
inesperado na execução constitui um erro. Isso pode ser causado por desvio da especificação, 
modelagem mal feita, erro de programação, pressão de tempo, especificação de requisitos. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 Falha: É o comportamento operacional do software diferente do esperado, um 
processamento incorreto, uma falha pode ser causada por diversos erros e alguns erros 
podem nunca causar uma falha.” 
A figura 5 mostra a diferença entre esses conceitos. 
 
Figura 5. Defeito x Erro x Falha (revista Qualidade de Software) 
 
“Teste de sistema é na verdade uma série de diferentes testes cuja finalidade principal é 
exercitar por completo o sistema baseado em computador. Apesar de cada teste ter uma 
finalidade distinta, todos trabalham para verificar se os elementos do sistema formam 
adequadamente integrados e executam as funções a eles alocados” (Pressman, 2006), algumas 
finalidades do teste podem ser de : 
“Teste de recuperação: No qual o software é forçado de diversos modos a falhar para verificar 
se a recuperação é adequadamente realizada. 
Teste de segurança: São feitas várias invasões impróprias no sistema ou alterações dos 
arquivos gerados pelo sistema e verificam-se os mecanismos de proteção são capazes de 
protegê-lo” (Pressman, 2006). 
Testes de stress: Executa no sistema uma quantidade de recursos anormais em grande volume 
para verificar o quanto o sistema é sensível. 
Teste de desempenho: É analisado o desempenho do sistema durante a execução, verificando 
qual é o comportamento integrado entre o software e o hardware. 
Teste Funcional: Verifica se todosos requisitos foram cumpridos de acordo com as regras de 
negocio, garantindo de que não existam diferenças entre os requisitos funcionais e o 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
comportamento do software construído, o teste não se preocupa com o código em si, eles são 
realizados a partir da seleção dos Casos de Uso baseados na especificação. 
TÉCNICAS EM TESTE DE SOFTWARE 
O teste de software é uma das técnicas mais custosas do desenvolvimento, porém o rigor e o 
custo depende da criticidade da aplicação, essas técnicas são classificadas de acordo com a 
origem das informações utilizadas para estabelecer os requisitos de testes, essas técnicas podem 
ser classificadas como funcional e estrutural. 
A técnica estrutural conhecida também como teste de caixa branca trabalha diretamente com o 
código fonte, avalia aspectos como: teste de condição fluxo de dados, caminhos lógicos, laços; 
“Os aspectos nessa técnica dependem da complexidade do componente de software” 
(Dias,2007), ela permite uma verificação mais precisa de comportamento ela é realizada durante 
todo o processo de desenvolvimento. 
A técnica funcional ou teste de caixa preta “identifica erros de interface, acesso ao banco de 
dados, desempenho e velocidade” (Kosciansk,2006); Os dados de entrada são fornecidos e o 
resultado é comparado a resultados previamente conhecidos, haverá sucesso se o resultado 
recebido foi igual ao esperado, ela é aplicável em todos os níveis de teste. 
Existe também a definição de teste de caixa cinza no qual são focados os mecanismos dos 
componentes e não do sistema em si, ele ignora os componentes internos e focaliza apenas as 
saídas geradas em resposta a entrada e condições de execução selecionadas. 
Conforme Sommerville (2003) “o processo de teste deve evoluir em estágios, os testes devem 
ser realizados incrementalmente, em conjunto com a implantação do sistema”. 
Esses processos podem ser divididos em estágios: 
Teste de Unidade: Explora a menor unidade do projeto, procura falhas ocasionadas por defeitos 
de lógica e de implementação de cada modulo,” são testados individualmente ou em grupos de 
unidades para garantir que eles operam corretamente” (Sommerville, 2003), podem ser 
baseados nas especificações de classes e na codificação do código. 
Teste de Módulos (Subsistema): São executados procedimentos em componentes dependentes, 
como uma classe de objetos que foram integrados. 
Teste de Integração: Provoca falhas associando entre os módulos quando eles são integrados, 
testa quais componentes são combinados e avalia a interação entre eles, esse teste geralmente é 
executado durante o desenvolvimento. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Teste de Sistema: Busca falhas por meio de utilização como se fosse o usuário final, verifica se 
o produto satisfaz os requisitos funcionais e não funcionais e testa as propriedades emergências 
do sistema, identifica possíveis erros entre o hardware, o software e o banco de dados, é 
baseado no projeto e na arquitetura do software. 
Teste de Aceitação: Costuma ser o estágio final do processo de teste do sistema e simulando 
rotinas de operações de modo a verificar se seu comportamento está de acordo com o solicitado, 
“ele pode revelar erros e omissões nas definições de requisitos, quando os recursos na verdade 
não atendem ás necessidades dos usuários ou quando o desempenho do sistema é inaceitável” 
(Sommerville, 2003). 
Teste de Regressão: “Consiste em aplicar todos os testes já aplicados nas versões anteriores 
em todos os ciclos e atualizações”, (Dias, 2007), verifica se as alterações não causam nenhum 
efeito indesejado e se o sistema mantém a conformidade com os requisitos especificados, são 
mais utilizados na manutenção do sistema. 
Técnicas de testes devem ser vistas como complementares e a questão está em como as utilizar 
de forma que as vantagens de cada uma seja melhor explorada em uma estratégia que leve a 
uma atividade de teste de boa qualidade, que seja eficaz e de baixo custo. 
O objetivo central de toda metodologia de teste é maximizar a sua cobertura e a quantidade 
potencial de defeitos que podem ser por ela detectados. 
TESTES AUTOMATIZADOS 
Conforme Souza,2013 “Automação de teste é o uso de software para controlar a execução do 
teste de software, a comparação dos resultados esperados com os resultados reais, a 
configuração das pré-condições de teste e outras funções de controle e relatório de testes”, é 
testar um software com outro software. 
São usados scripts padronizados que podem ser mais rápidos na execução dos testes e na 
detecção dos erros do que a forma de teste manual. 
Utilizando testes automatizados é possível aumentar a consistência e abrangência, reduzir o 
tempo ou esforço, diminuir o custo, aumentar a qualidade do produto final. 
O ideal é automatizar tarefas repetitivas, cálculos matemáticos, testes de regressão e 
funcionalidades criticas no sistema. 
Funcionalidades pouco usadas, protótipos e funcionalidades que exigem inspeção visual são 
pouco recomendadas. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Existem ferramentas comerciais e OpenSource disponíveis para auxiliar o desenvolvimento de 
automação de software, ferramentas específicas para cada tipo de teste e software: 
Selenium: É usado para automatizar navegadores em várias plataformas, realizando 
testes funcionais. 
JUnit: É um framework simples para escrever testes repetíveis, orientado a Java, realiza 
testes de unidade. 
JMeter: Projetado para testar aplicações web, mas expandiu para outras funções de teste, 
realizado para teste de desempenho (performance). 
MODELOS DE TESTE 
Modelo TMAP: O modelo teste TMAP (Test Management Approach) é uma abordagem 
que pode ser aplicada em todas as situações de teste e em combinação com qualquer outra 
metodologia de desenvolvimento de sistema, ele oferece ao testador uma série de elementos 
para seu teste como técnicas de especificação de teste, infraestrutura de teste, estratégia de teste, 
organização de teste, ferramentas de teste, entre outros. 
TMap é composto das seguintes fases e etapas, conforme a figura 6 mostra: 
 
Figura 6. Fases e Etapas TMap (Gerencia de projeto de teste Segundo o Modelo do PMI por 
Emerson Rios,2003 ) 
 Segundo Rios 2003, “as etapas de Planejamento e Controle e Preparação 
seguem em paralelo as demais etapas, pois continuam em andamento durante todo o 
projeto. O produto da fase de planejamento, uma vez concluído, deve ser acompanhado 
e controlado. Na etapa de preparação os ambientes de gerencia de mudanças e de 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
gerencia de configuração são adequados ao projeto de testes, além de ser preparada a 
infraestrutura a ser utilizada no projeto (Hardware, Software e Pessoal)”. 
Modelo V: A estrutura do modelo em V é uma aproximação estruturada de teste que 
pode ser usada em todas as metodologias de desenvolvimento. Segundo Silva “o modelo que foi 
definido por Paul Rook em 1980, foi apresentado como um modelo alternativo ao modelo 
Waterfall e enfatizava a importância nos testes em todo o processo de desenvolvimento e não 
somente ao término do processo”. 
Este modelo introduz a criação de testes de dados e cenários de teste durante o ciclo de 
desenvolvimento do software, em geral, reforça a ideia de que o teste não é uma fase, mas uma 
parte integrante do ciclo de desenvolvimento do software, o qual trabalha com diferentes níveis 
de teste como: teste de unidade, teste integração, teste de sistema e teste de aceitação. 
A principal ideia é sempre testar a mesma coisa, porém com focos diferentes,o modelo 
em V possui dois “lados”, um lado é especifico para verificação que é o ciclo de vida de 
desenvolvimento e o outro é especifico para a validação que é o ciclo de testes. Basicamente o 
modelo segue as fases citadas na figura 7: 
 
Figura 7. Fases e Etapas “V” (Técnicas de Teste no Ciclo de 
Desenvolvimento de Software por Camilo Ribeiro ,2010) 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
A vantagem nesse modelo é que segundo Camilo Ribeiro “a fase de teste começa no inicio do 
ciclo, os planos de teste são detalhados em cada fase do ciclo o que ajuda a compreender 
melhor qual a origem do problema”. 
A desvantagem, segundo o mesmo autor “é que apesar da sua implementação em todas as 
fases continua a não ser flexível suficiente e é necessário maior número de feedback entre todas 
as fases do ciclo”. 
ESTUDO DE CASO – LIBRE OFFICE 
Libre Office é um pacote de componentes para escritório gratuito, é desenvolvido por 
voluntários do mundo todo através de fundações sem fins lucrativos. É uma extensão aberta do 
StarOffice e uma continuação de desenvolvimento da suíte OpenOffice. Seus componentes são: 
processador de textos (Write), planilha de cálculo (Calc), apresentações (Impress), gráficos 
vetoriais (Draw), banco de dados (Base), editor de fórmulas matemáticas (Math), o pacote 
possui inúmeras vantagens entre elas: sem taxas de licenciamento, código aberto, 
multiplataforma, extenso suporte a idiomas, é compatível com vários Sistemas Operacionais 
(como Windows, Linux e MAC OS). 
Possui grande compatibilidade com extensões de arquivos, suporte online gratuito, entre outras 
inúmeras vantagens (Tutorial LibreOffice). 
Esse estudo de caso visa testar algumas funções do componente processamento de texto Write, 
que além dos recursos usuais de um processador de texto, fornece também características como, 
exportação para PDF, integração de banco de dados, ferramentas de desenho incluídas, entre 
outras funções muito similar ao MS Word. 
 Para verificar a finalidade do software foi utilizado o teste funcional das funções de cartão de 
visitas, envelopes, abrir documentos salvos no Word. Na função de recuperação de documentos 
foi aplicado o teste de recuperação, com objetivo de verificar se essas funções funcionam 
corretamente. E finalmente, validar o uso das mesmas. 
Os modelos dos relatórios foram desenvolvidos através dos modelos sugeridos site IEEE e o site 
do Grupo de Testadores de Software (Blog editado por Anne Caroline, mestre em Ciência da 
Computação pela UFCG). 
Hipótese Abrir Documentos Salvos no Word: Como muitos documentos são salvos em Word é 
importante que o Libre Office abra os documentos, sem alterar formatações que foram 
estabelecidas no Word (veja resultado na figura 9). 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Hipótese Recuperação de Dados: Como existem riscos é importante que quando o sistema 
fechar de forma inesperada, ele recupere todos os dados e as formatações do documento (veja 
resultado nas figuras 10, 11,12 e 13). 
Hipótese Cartão de Visita: Independente de que forma que ele seja feito, num cartão de visita é 
importante que a impressão seja de acordo com o que foi estabelecido na configuração, 
respeitando o tamanho, layout e os dados informados (veja resultado nas figuras 14 e 15). 
Hipótese Envelopes: A impressão do envelope deve ser correta, com o endereço legível, posição 
aceitável e que tamanho das letras seja legível (veja resultado nas figuras 16 e 17). 
Hipótese Personalizar Barra de Ferramentas: A barra deve ser criada conforme foi feita a 
personalização, os atalhos criados devem funcionar corretamente e deve ser possível alterar a 
barra personalizada (veja resultado nas figuras 18, 19). 
Hipótese Conversor de Documentos: Arquivos com extensão doc devem ser convertidos sem 
alterações ou erros para o formato oxps (veja resultado nas figuras 20, 21). 
Foi escrito um relatório de plano de teste (veja resultado na figura 8) para cada função do 
sistema testado, esse plano de teste foi respeitado e executado com êxito, os resultados 
negativos foram registrados no relatório de incidentes, informando quais foram os erros. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 8. Plano de teste executado (tabela desenvolvida para teste do Libre Office) 
Foram encontradas divergências e dificuldades nas funções de cartões de visita, abrir 
documentos salvos pelo Word e na Recuperação de documentos, as divergências foram: 
 A função de abrir documentos no Word não respeita algumas formatações como 
tabelas, que abrem fora de formatação, cortando algumas colunas da tabela (veja 
resultado na figura 9). 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 9. Tabela de relatório de Incidente (tabela desenvolvida para teste do Libre Office) 
 A função de recuperação de dados não funciona, pois não recupera dados 
que não foram salvos (veja resultado na figura 10, 11, 12 e 13). 
 
Figura 10. Imagem do texto a ser recuperado (Imagem desenvolvida para teste do Libre 
Office) 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 11. Tela para iniciar a recuperação de dados (Libre Office) 
 
Figura 12. Tela informando os dados recuperados (Libre Office) 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 13. Imagem com texto recuperado (Imagem desenvolvida para teste do Libre Office) 
 Na função cartões de visitas, alguns campos são confusos e não existe formatação 
e nem validação para as informações como CEP, telefone e e-mail, a visualização 
da impressão é difícil e a impressão não é econômica, pois fica muito espaço sem 
aproveitamento na folha e ao visualizar impressão não aparece as informações 
(veja resultado na figura 14 e 15). 
 
 
Figura 14. Tela para preenchimento cartão de visita (Libre Office) 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 15. Tela de impressão dos cartões de visita (Libre Office) 
 A função de envelope não apresentou divergências (veja resultado na 
figura 16 e 17). 
 
Figura 16. Tela de preenchimento para envelope (Libre Office) 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 17. Envelope impresso (Libre Office) 
 A função de personalização de barra de ferramentas não apresentou 
divergências (veja resultado na figura 18 e 19) 
 
 
Figura 18. Criando barra de ferramentas (Libre Office) 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 19. Barra de ferramentas criada (Libre Office) 
 A função conversor de documentos não apresentou divergências (veja 
resultado na figura 20 e 21) 
 
 
Figura 20. Tela para selecionar tio de documento (Libre Office) 
 
 
Figura 21. Tela com o tipo de documento alterado (Libre Office) 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Todas as divergências encontradas foram documentadas no relatório de incidentes, conforme a 
figura 22 mostra. 
 
Figura 22. Relatório de teste preenchido (tabela desenvolvida para teste do Libre Office) 
Utilizadas nos testes as técnicas de unidade e sistema, verifica se cada função atende as 
hipóteses esperadas. O relatório de teste é preenchido informando a quantidade de validações 
realizadas, quantas foram bem sucedidas ou mal sucedidas, os casos de teste são preenchidos de 
acordo com as validações que são informadas no plano teste, o resultado é apresentado na figura 
23. 
 
 Revista Engenho,vol.9 – Junho de 2014 
 
 
Figura 23. Relatório de Teste (tabela desenvolvida para teste do Libre Office) 
 
CONCLUSÕES 
Uma das formas importantes para ter qualidade no software é realizar o processo de teste 
corretamente: criar um plano de teste a ser seguido, preencher os relatórios de incidente e 
relatórios de teste. 
Uma documentação de plano de teste bem elaborada e especificada é indispensável, para que o 
testador possa executar todos os passos e que o mesmo consiga validar e reportar os erros de 
todas as definições estabelecidas junto ao cliente. 
É importante também que o grupo de testes siga a metodologia e a cumpra para que a 
produtividade e qualidade aumente, além disso as equipes de teste e desenvolvimento devem ser 
distintas, “pois conforme algumas experiências realizadas é muito difícil um desenvolvedor 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
realizar as duas funções (desenvolver e testar), podendo estes encobrirem seus próprios 
enganos de modo que a eficácia dos testes seja praticamente nula” (Rocha,2011). 
Utilizando corretamente as regras pré-definidas e respeitando a técnica de teste é possível 
atender a real necessidade do cliente e atingir a qualidade no software, porém para que isso seja 
bem feito é necessário tempo, detalhe de extrema importância que a maioria dos projetos não 
possui. 
Teste de software não é um processo barato, pelo contrário é um dos processos mais caros, 
porém em num software bem testado o custo de manutenção é menor, quanto antes o erro for 
descoberto no processo, menor o custo, o que leva a uma grande economia, redução no custo e a 
confiança e satisfação do cliente. 
No estudo de caso desta pesquisa foi utilizado como técnica principal, o teste de sistema, no 
qual foram encontrados diversas falhas, defeitos e alguns pontos que podem ser melhorados. 
A área de teste será uma área de grande evolução e disseminação no mercado, dificilmente em 
uma fábrica de software de grandes empresas não haverá a necessidade de testadores no meio de 
milhares de desenvolvedores. 
A qualidade de software não deve ser vista como algo simples e de nenhum interesse, mas sim 
como sendo uma área de grande valor para o mercado e principalmente para que clientes 
possam estar criando sistemas ágeis, rápidos e com qualidade. 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
AMARAL, Davi; GOMES, Renato; JESUS, Rodrigo Passos; ARAUJO, Tiago Marques; 
GOULART, Elias E. . Metodologias de Teste de Software. Disponível em 
<http://seer.uscs.edu.br/index.php/revista_informatica_aplicada/article/view/993>. 
Acessado em 03/11/2013. 
 
BLANCO, Mariana Zanuzzio. Documentação de teste baseado na Norma IEE 829 – estudo de 
caso: “Sistema de apoio a tomada de decisão, 2012. Disponível em 
< http://revistatis.dc.ufscar.br/index.php/revista/article/view/18 >. Acessado em 03/11/2013. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
CAMPOS, Fabio Martinho Campos. TMap Next Test Management Approach – As 4 Essências 
do TMap Next. Disponível em: < http://www.linhadecodigo.com.br/artigo/3221/tmap-next-test-
management-approach-as-4-essencias-do-tmap-next-parte-3.aspx >. Acessado em 29/09/2013. 
 
CAROLINE, Anne. Grupo Testadores de Software - Modelo de Roteiro de Testes. Disponível 
em < http://gtsw.blogspot.com.br/2009/08/modelo-de-roteiro-de-testes.html>. Acessado em 
03/11/2013. 
 
DIAS, Arilo Claudio Dias, Neto. Introdução a Teste de Software. Engenharia de Software 
Magazine. Edição 01. Editora SQL Magazine, 2007. 
 
DIAS, Arilo Claudio Dias, Neto. Planejamento de teste a partir de casos de uso. Engenharia de 
Software Magazine. Edição 06. Editora SQL Magazine, 2008. 
 
IEEE Standard for Software Test Documentation. Disponível em 
<http://faculty.ksu.edu.sa/mohamedbatouche/SWE%20434/IEEE%20Std%20829%20-
%201998.pdf>. Acessado em: 12/11/2013. 
 
HOHN, Erila Nina; MALDONADO, Jose Carlos; FABBRI, Sandra C.P.F. Um estudo de caso 
do arcabouço de conhecimento e melhoria de processo de teste – KITest. 
Disponível em < 
http://www.icmc.usp.br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_RT_366.pdf>. 
Acessado em 03/11/2013. 
 
JMETER, The Apache Software Foundation. Disponível em < http://jmeter.apache.org/>. 
 Acessado em 10/11/2013. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
JUNIT. Disponível em < http://junit.org/>. Acessado em 10/11/2013. 
 
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software. Ed. 2. Editora 
Novatec, 2006. 
 
LIBRE OFFICE. The Document Foundation. Disponível em: <http://www.libreoffice.org/>. 
Acessado em 15/10/2013. 
 
MELLO, Leandro Cicero da Silva. Levantamentos de requisitos. Disponível em: < 
http://www.ice.edu.br/TNX/storage/webdisco/2011/03/11/outros/7799b4179c3e64b7f8ab3ec4cf
dbea22.pdf>. Acessado em 05/12/2013. 
OLIVEIRA. Sandro R. Bezerra. Conceitos Fundamentais de Qualidade de Software. Disponível 
em 
<http://www.ufpa.br/srbo/Disciplinas/CBCC_CBSI_Mestrado_Qualidade/Aulas/Aula02.pdf>. 
Acessado em: 14/11/2013. 
 
PAULA, Wilson de Pádua, Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. 
Disponível em: http://aulasprof.6te.net/Arquivos_Aulas/07-
Proces_Desen_Soft/Livro_Eng_Soft_Fund_Met_Padroes.pdf, recuperado em 21/08/2013. 
 
PAULA, Wilson de Padua, Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. 
Ed. 3. Editora LTC, 2009. 
 
PRESSMAN, Roger S. Engenharia de Software. Ed.6. Editora McGraw – Hill Interamericana, 
2006. 
 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
PRIMÃO, Aline Pacheco; RIBEIRO, Patric da Silva; KREUTZ, Diego Luis. Estudo de Caso: 
Técnicas de Teste como parte do Ciclo de Desenvolvimento de Software. Disponível em < 
http://www.sirc.unifra.br/artigos2010/4.pdf>. Acessado em 03/11/2013. 
 
RIBEIRO, Camilo. Técnicas de Teste no Ciclo de Desenvolvimento de Software,2010. 
Disponível em <http://www.slideshare.net/camiloribeiro/tcnicas-de-teste>. Acessado em: 
12/11/2013. 
 
RIOS, Emerson. Gerencia de Projeto de Testes Segundo o Modelo do PMI, 2003. Disponível 
em: <http://www.bfpug.com.br/islig-rio/Downloads/Gerencia_Projeto_Testes_PMI.pdf >. 
Acessado em 14/04/2014. 
 
ROCHA, Camila. Estudo de caso da qualidade de software na Metodologia V-Model e sua 
interação com metodologias ágeis, 2011. Disponível em: 
<http://www.fatecsp.br/dti/tcc/tcc0028.pdf>. Acessado em 12/11/2013. 
 
SELENIUM HQ, Browser Automation. Disponível em < http://www.seleniumhq.org/>. 
Acessado em 10/11/2013. 
 
SILVA, Fernando Rodrigues. Testes de software – Níveis de testes. Disponível em 
<http://www.devmedia.com.br/testes-de-software-niveis-de-testes/22282>. 
Acessado em 12/11/2013. 
 
SOMMERVILLE, Ian. Engenharia de Software. Ed.6. Editora Pearson Education Limited, 
2003. 
 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
SOMMERVILLE, Ian. Engenharia de Software. Ed.8. Editora Pearson Education Limited, 
2007. 
 
SOUZA, Eduardo Freitas. Introdução a Automação de Teste de Software. Centro de estudos 
avançados Intellecta. Disponível em: < http://www.slideshare.net/eduardofsouza9/automacao-
de-testes-de-softwares>. 
Acessado em 22/09/2013. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
MONITORAMENTO DE VIBRAÇÕES EM MANCAIS COM 
ACELEROMETRO 
 
Jefferson Peró Ormonde 
Centro Universitário Padre Anchieta 
jefferson.pero@hotmail.com 
 
Valter RobertoPinezi 
Centro Universitário Padre Anchieta 
vrpinezi@yahoo.com.br 
 
Mario Mollo Neto 
Centro Universitário Padre Anchieta 
mariomollo@gmail.com 
RESUMO 
Este artigo descreve o desenvolvimento de um protótipo, microprocessado e de 
tamanho reduzido, que proporciona a coleta de informações provenientes de vibrações 
mecânicas (eixos X, Y, Z) causadas por sistemas movimentados por motores elétricos 
baseados em suportes com mancais de rolamentos durante a realização de trabalho, 
enviando as informações em tempo real diretamente para uma Interface Homem 
Maquina (IHM), composta por uma placa de aquisição de dados e um computador 
pessoal, possibilitando a análise de forma fácil e amigável dos sinais coletados no 
campo. Através desta pesquisa notamos a possibilidade de utilizar a eletrônica 
embarcada e as ferramentas de software substituindo análises empíricas, que às vezes 
podem não trazer um diagnóstico verdadeiro, fornecendo base para tomada de decisão, 
através de manutenção preditiva. 
Palavras chaves: Vibrações; Motores Elétricos; Acelerômetro; Manutenção Preditiva. 
 
ABSTRACT 
This article describes the development of a small size microprocessor prototype 
and, which provides a collection of information from mechanical vibrations (X, Y, Z) 
caused by moved electric motors systems based on media roller bearings while 
performing work by sending the information in real time directly to a Human Machine 
Interface (HMI), consisting of a data acquisition card and a personal computer, 
enabling the analysis in an easy and friendly signals collected in the field. Through this 
study, we detected the possibility of using the embedded electronics and software tools 
replacing empirical analyzes, which sometimes cannot bring a true diagnosis, providing 
a basis for decision-making, through predictive maintenance. 
Keywords: Vibrations; Electric Motors; Accelerometer; Predictive Maintenance. 
 
 
 
 
 
 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
 INTRODUÇÃO 
Esta pesquisa propõe a construção e desenvolvimento de um dispositivo 
composto por microcontrolador, conversores e sensores capazes de mensurar as 
vibrações e excitações provocadas por movimentos e oscilações em três eixos em 
mancais de máquinas rotativas industriais, e enviar as informações coletadas para um 
computador e modelar seus dados. Este protótipo focaliza a construção de um 
dispositivo capaz de captar grandezas como vibrações e seu devido comportamento, 
para identificar possíveis anomalias no funcionamento destes componentes de 
transmissão de movimento. Segundo Lamin Filho (2003) a maioria das maquinas 
modernas opera a partir de motores elétricos, que com o uso contínuo podem 
desenvolver falhas e essas falhas podem causar paradas na máquina. 
É proposto o desenvolvimento de uma placa de aquisição que contém um sensor 
medidor de aceleração gravitacional, que converte a força da gravidade em um dado 
ponto em capacitância, em seguida para um conversor de capacitância para nível de 
tensão possibilitando que essa informação posteriormente seja processada por um 
microcontrolador, em seguida a informação é convertida de nível TTL (Transistor 
Transistor Lógic) para uma porta de comunicação serial RS232 onde, o dispositivo que 
processa e trata esses dados para um formato amigável é um computador portátil que 
incorpora um software gráfico que possibilita a amostragem da informação em tempo 
real para os usuários. 
A constante busca das indústrias em reduzir o tempo de parada provocado pelas 
quebras em equipamentos e paradas em seu processo produtivo ocasionado por falta de 
manutenção preventiva e preditiva tem crescido constantemente. No atual ambiente 
onde a busca pela redução de custos de produção é mandatório para a sobrevivência das 
empresas de todos os ramos de atividades, a eficiência dos equipamentos é tratada com 
grande importância. 
O protótipo proposto neste trabalho faz a aquisição de dados em tempo real das 
curvas características de vibração em máquinas rotativas, possibilitando ao usuário fazer 
leituras da vibração de um equipamento, permitindo a criação de um banco de dados 
para análise futura em diversos intervalos de tempo. O que facilita o acompanhamento 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
do estado geral de funcionamento comparado a medições anteriores, no caso das leituras 
serem diferentes no mesmo equipamento e no mesmo ponto, é possível identificar uma 
anomalia que talvez seja imperceptível perceber somente com os cinco sentidos ou com 
os dispositivos de sinalização tradicionais. 
Os equipamentos comercializados para este fim possuem maior precisão, porém, 
com custo de aquisição muito maior, o que impede a instalação de mais unidades para 
monitoramento fixo em determinadas máquinas consideradas chave para a produção. 
Além da grande vantagem de fazer predições, o equipamento proposto apresenta 
componentes de fácil aquisição, baixo custo e uso de poucos componentes eletrônicos, 
além da integração com microcomputadores do tipo PC´s e notebooks que hoje são de 
fácil acesso na grande maioria dos estabelecimentos produtivos. Isto permite a aplicação 
de várias unidades deste dispositivo no ambiente fabril, de forma a manter um 
monitoramento distribuído e, quando algum dos equipamentos monitorados apresente 
indicações de problemas, o mesmo poderá ser avaliado com a instalação de um único 
instrumento de precisão para uma melhor avaliação ou até que seja sanada a falha. 
REVISÃO BIBLIOGRÁFICA 
Vibrações 
A noção de vibração começa com a ideia do equilíbrio. Um sistema está em 
equilíbrio quando a resultante de todas as forças atuantes sobre mesmo é nula. Qualquer 
sistema que esteja sob esta condição somente sairá dela quando alguma perturbação 
externa atuar sobre o mesmo. A oscilação irá ocorrer quando, após a perturbação atuar, 
o sistema apresentar a tendência a retornar à sua posição de equilíbrio. Ao se conceder 
ao pêndulo um ângulo inicial pequeno o mesmo entrará em movimento tendendo a 
retornar à sua posição de equilíbrio inicial. Ao passar por ela o movimento não se 
interrompe porque a massa do pêndulo possui velocidade, portanto energia cinética. 
Enquanto esta energia permanecer presente no sistema o movimento oscilatório 
continuará. Se, entretanto, a energia inicial concedida for muito elevada, o pêndulo 
entrará em movimento rotativo. Situação semelhante ocorre com uma bola rolando 
dentro de uma superfície circular (LARANJA, 2005). 
Segundo o mesmo autor, o movimento do pêndulo se produz na direção em que 
o mesmo é permitido. Em se tratando de um pêndulo simples o movimento é plano 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
sendo necessária apenas uma única variável para descrevê-lo (o ângulo). Diz-se, então 
que ele possui um grau de liberdade ou mobilidade. Se fosse permitido ao mesmo girar 
em torno de um eixo vertical, o mesmo possuiria dois graus de liberdade. 
O número de graus de liberdade de um sistema, como destaca o autor, é o 
número mínimo de coordenadas capazes de representar completamente o movimento do 
mesmo (estas coordenadas são chamadas coordenadas generalizadas). 
Se um sistema possui pelo menos um grau de liberdade, os valores das variáveis 
que descrevem o estado do sistema (posição, velocidade, aceleração) devem ser 
especificados. Para isto é necessário que se escolha um sistema de coordenadas, a figura 
1 ilustra os sistemas com um grau de liberdade e com dois graus de liberdade. 
 
Figura 1 Sistema com um (a) grau de liberdade e (b) dois graus de liberdade. Fonte: (LARANJA, 
2005).Defeitos comuns em mancais de rolamentos. 
Falhas em rolamentos podem ser previstas através da análise de vibrações, 
detectando-se componentes espectrais com frequências características dos defeitos e 
suas harmônicas e bandas laterais. O prognóstico da falha se baseia não só na 
intensidade dessas componentes, como também no padrão de distribuição de energia 
pelas diversas bandas espectrais, o que permite identificar o estágio de degradação do 
rolamento (SCHILTZ, 1990). 
As causas mais comuns de defeitos em rolamentos são: seleção incorreta, 
sobrecarga, defeito de fabricação, desalinhamento, "jambragem", montagem incorreta, 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
estocagem inadequada, lubrificação inadequada, excessiva ou insuficiente, falha de 
vedação e descargas elétricas através dos mancais (SCHILTZ, 1990). 
Geralmente, os defeitos em rolamentos evoluem com certa lentidão e emitem 
sinais com bastante antecedência da falha final, que pode ocorrer por travamento ou 
ruptura dos componentes. Defeitos típicos que evoluem dessa forma são: escamamento, 
descascamento (pelling), arranhadura, escorregamento, fratura, trincas, gaiola 
danificada, impressões, pitting, desgaste, corrosão por contato, esmagamento (falso 
brinel), deslizamento, superaquecimento, corrosão elétrica, oxidação elétrica, falha de 
instalação, alteração de coloração (PIERRI, 2004). A figura 2 demonstra um dos tipos 
de falhas que acontecem em rolamentos. 
 
Figura 2 Escamamento. Fonte: (NSK BEARING DOCTOR, 2001). 
 
Componente: Anel interno de rolamento de contato angular. 
Sintoma: Escamamento ao longo da pista. 
Causa: Desalinhamento na instalação. 
 
Frequências Básicas Geradas por Defeitos de Rolamentos 
Segundo Taylor (1994) as frequências características de falha de rolamentos 
possuem uma peculiaridade especial: elas são não síncronas, isto é, não são múltiplas 
inteiras da velocidade de rotação do eixo. Isso pode permitir a sua identificação, mesmo 
quando não se conhece qual o rolamento instalado na máquina monitorada. 
As quatro frequências básicas geradas por defeitos de rolamentos são 
relacionadas com o comportamento dinâmico de seus principais componentes, ou seja: 
 Frequência de passagem de elementos rolantes por um ponto da Pista Interna 
(geralmente indicada por BPFI do inglês Ball Pass Frequency Inner Race), 
associada a defeitos na pista interna. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 Frequência de passagem de elementos rolantes por um ponto da Pista Externa 
(geralmente indicada por BPFO do inglês Ball Pass Frequency Outer Race), 
associada a defeitos na pista externa. 
 Frequência de giro dos elementos (geralmente indicada por BSF do inglês Ball 
Spin Frequency), associada a defeitos nos elementos rolantes (rolos ou esferas). 
 Frequência de giro da gaiola ou do conjunto (trem) de elementos rolantes 
(geralmente indicada por FTF do inglês Fundamental Train Frequency), 
associada a defeitos na gaiola e a defeitos em alguns dos elementos rolantes. 
É importante ressaltar que, ao contrario da maioria das frequências de vibração 
geradas por componentes mecânicos, essas frequências são verdadeiramente frequências 
de defeito. Isto é, elas só estarão presentes nos espectros de vibração quando os 
rolamentos estiverem realmente defeituosos ou, pelo menos, quando seus componentes 
estiverem sujeitos a tensões e deformações excessivas que poderão induzir uma falha 
(TAYLOR, 1994). 
 
 Equações de frequências 
Segundo Taylor, (1994), as frequências básicas de defeitos em rolamentos podem 
ser calculadas através das equações 1 A 4: 
Rotação da Gaiola 
Para pista externa estacionária, para pista interna estacionária: 
 
 
 
 
( 
 
 
 ) ( ) 
Rotação do Elemento Rolante: 
 
 
 
 
 
 
 
[ (
 
 
 )
 
] ( ) 
 
Passagem de Elementos pela Pista Externa: 
 
 
 
 
( 
 
 
 ) ( ) 
 
Passagem de Elementos pela Pista Interna: 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
 
 
 
( 
 
 
 ) ( ) 
 
Onde: 
S = Si - Se 
Se = frequência de rotação da pista externa 
Si = frequência de rotação da pista interna 
d = diâmetro dos elementos rolantes 
D = diâmetro primitivo 
n = nº de elementos rolantes 
Ø = ângulo de contato 
 
As frequências de defeitos dos rolamentos comerciais podem ser obtidas de varias 
fontes, como através de distribuidores dos fabricantes de rolamentos, bancos de dados 
disponíveis comercialmente, etc. 
 
TÉCNICAS DOMÍNIO DO TEMPO 
Pela praticidade no desenvolvimento do software supervisório deste protótipo, 
foi a técnica adotada para a análise dos dados coletados nesta pesquisa, uma das 
abordagens de detecção e diagnóstico é analisar o sinal de vibração medido no domínio 
do tempo. Outras abordagens mais sofisticadas podem ser usadas, como as aplicadas 
por Dyer e Stewart, (1978); Swansson e Favaloro (1984); e por Alfredson e Mathew 
(1985), como o cálculo da tendência de parâmetros estatísticos em domínio de tempo. 
Podem-se definir vários parâmetros estatísticos como RMS, pico, fator de crista, 
Curtose como aplicado por Dyer e Stewart (1978); Lai (1990) e Khan (1991), fator de 
folga, fator de impulso, fator de forma segundo Li et al.,(1991), e o fator de defeito 
segundo aplicação realizada por Garlipp (2001). 
A técnica de se visualizar o sinal no tempo não é tão fácil, pois uma enorme 
quantidade de informação pode ser obtida desta maneira, como a presença de 
modulações, componentes de frequência do eixo, desbalanceamento do eixo, 
transitórios, componentes de frequência mais alta, frequências de defeitos e outros 
(ALMEIDA e ALMEIDA, 2005). 
Podem ser usados parâmetros estatísticos em domínio de tempo e de tendência 
em uma tentativa de se detectar a presença de danos incipientes do rolamento. Os 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
parâmetros estatísticos mais usados são o pico, RMS, fator de crista, fator de forma, 
fator de impulso, fator de defeito, pico a pico, fator de folga e Curtose. Estes parâmetros 
podem ser definidos para um sinal discreto e são formas tradicionais de se quantificar 
um sinal dinâmico (ALMEIDA e ALMEIDA, 2005). 
O parâmetro Pico é o valor de zero a pico, ou seja, um valor medido de zero até o pico 
mais alto da onda (Equação 5). 
 
 
 
 
{ [ ( )] [ ( )]} ( ) 
 
O valor Pico é útil na medida das respostas dos sistemas a choques mecânicos. 
O parâmetro RMS é o valor eficaz ou o valor médio quadrático. Ele se relaciona 
diretamente com a energia do sinal, ou seja, com a capacidade destrutiva da vibração 
(Equação 6). 
 
 √
 
 
∑ [ ( ) ]̅ ( ) 
 
O fator de crista permite detectar falhas em rolamentos através de relações de 
amplitudes dos sinais de vibrações. É definido como a relação do valor do pico de 
vibraçãopelo valor de RMS medido dentro de uma banda de freqüência (Equação 7). 
 
 
 
 
 
 ( ) 
 
O método de Curtose utiliza-se a análise estatística para detectar falhas em rolamentos 
através de um fator de Curtose designado por K. É baseado no sinal do domínio do 
tempo e usa-se o quarto momento central de um sinal (Equação 8). 
 
 
 
 
 
∑ [ ( ) ]̅̅̅ 
 
 ( ) 
 
Na prática observou-se que para K=3 é o caso para um rolamento sem defeito e quando 
o K>3 tem-se defeitos correspondentes aos sinais em forma de pulso de curta duração. 
O Fator de Defeito é um parâmetro para a avaliação de defeitos em rolamentos através 
da evolução na diferença entre os picos e os valores RMS do sinal de vibração do 
rolamento (Equação 9). 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
 
 ( ) 
 
O valor Pico-a-Pico é o valor medido entre os extremos da onda (distância do 
maior pico negativo até o maior pico positivo), (Equação 10). 
 
 
 { [ ( )] [ ( )]} ( ) 
 
O valor pico a pico indica o trajeto total do elemento e é útil nas considerações 
de folgas e tensões dinâmicas geradas pela vibração. Onde x denota o valor médio do 
sinal de tempo discreto x(t) com N pontos de dados. 
Podem-se usar duas abordagens para estatística em domínio de tempo. A 
primeira é computar os parâmetros estatísticos para toda a faixa de frequência do sinal 
conforme digitalizado, e a segunda é decompor o sinal em faixas discretas de frequência 
e obter os parâmetros para cada faixa (DYER e STEWART, 1978). 
 
Existe um grande número de estudos para investigar o uso destes parâmetros 
para detecção dos danos do rolamento e para cálculo de tendência, para determinar seu 
comportamento com o aumento dos danos do rolamento (DYER e STEWART, 1978; 
SWANSSON e FAVALORO, 1984; LAI, 1990; KHAN, 1991; KIRAL e 
KARAGULLE, 2006). 
Outros parâmetros em domínio de tempo podem ser definidos tais como fator de 
folga, fator de impulso e fator de forma, conforme desenvolvido por Li et al. (1991). Os 
fatores de Folga e de Impulso são os mais úteis. O fator de Folga é o mais sensível e 
geralmente robusto para detecção de fragmentação por fadiga incipiente. 
 
TÉCNICA DOMÍNIO DA FREQÜÊNCIA 
 
Na maior parte das medidas de vibração é mais fácil trabalhar no domínio das 
frequências que no domínio do tempo (BREITENBACH, 1999). 
Segundo o autor, o sinal no domínio da frequência ou espectro de frequência é 
um gráfico de amplitude da resposta de vibrações pela frequência e pode ser derivado 
utilizando-se a transformada rápida de Fourier (FFT) da forma de onda no tempo. O 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
espectro de frequência fornece uma informação valiosa sobre a condição de uma 
máquina. 
Desde que as forças de excitação sejam constantes ou variem de uma pequena 
quantidade, os níveis de vibrações medidos da máquina também permanecem 
constantes ou variam de uma pequena quantidade. Entretanto, a partir do momento que 
as máquinas começam a apresentar defeitos, seu nível de vibrações e, portanto, o 
formato do espectro de frequência muda. Através da comparação do espectro de 
frequência das máquinas danificadas com um espectro de frequência de referência 
correspondente a uma máquina sem danos, a natureza e a localização das falhas podem 
ser detectadas (NEPOMUCENO, 1989). 
Ainda segundo Nepomuceno (1989), outra característica importante de um 
espectro é que cada elemento rotativo em uma máquina gera frequências identificáveis, 
onde se vê a relação entre os componentes de uma máquina e seu correspondente 
espectro de vibrações. Portanto, mudanças no espectro em uma determinada frequência 
podem ser associadas diretamente com o correspondente componente da máquina. Uma 
vez que mudanças no espectro são mais facilmente detectadas comparadas com 
mudanças nos níveis globais de vibrações, esta é uma característica que ajuda muito na 
detecção de defeito na prática. 
 
TRANSFORMADA DE FOURIER 
Transformada contínua 
 
Sinais periódicos contínuos podem ser representados como uma série (a série de 
Fourier). Para existir a série de Fourier é necessário ao sinal satisfazer as seguintes 
condições: 
- ser finito 
- possuir um número finito de descontinuidades 
- possuir um número finito de máximos e mínimos em um ciclo (SPIEGEL, 1971). 
Segundo o Spiegel (1971), qualquer sinal periódico limitado pode ser 
representado pela série de Fourier. A vibração de uma estrutura, assumida como 
periódica no tempo e de período T, pode ser considerada que satisfaz essas condições, e, 
portanto escrita como a seguinte série infinita: 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
 ( ) ∑ ( 
 
 
 
 
 
) ( )
 
 
 
onde “ao/2” é o nível DC do sinal, e “an” e “bn" podem ser obtidos a partir de x(t), 
previamente conhecido, através das seguintes relações:' 
 
 
 
 
∫ ( ) (
 
 
) 
 
 
 ( ) 
 
 
 
 
∫ ( ) (
 
 
) ( )
 
 
 
 
Os coeficientes “an” e “bn" são chamados genericamente de coeficientes de 
Fourier (ou coeficientes espectrais) para a função x(t), e a equação (14) é a Série de 
Fourier. 
Considerando a fórmula de Euler e que a soma de uma senóide e uma cosenóide 
de mesma freqüência pode ser escrita da seguinte maneira: 
 A cos(wt) + B sin(wt) = C sin(wt + ) 
(14) 
onde 
 √ e = tan-1(A/B) 
(15) 
 
Pode-se escrever a série de Fourier para sinais contínuos da seguinte forma: 
 
 ( ) 
∑ ( 
 
 ) ( ) 
 
onde 
 
 
 
 
∫ ( ) ( 
 
 
 ) 
 
 
 ( ) 
 
Para sinais não-periódicos (período infinito), a série de Fourier se transforma na 
Transformada de Fourier, definida como: 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
 ( ) ∫ ( ) ( ) ( )
 
 
 
A equação acima pode ser obtida a partir das anteriores, considerando que o 
período do sinal tende a infinito. A Transformada de Fourier existe para as funções para 
as quais a integral acima converge, o que em geral é verdade para os sinais provenientes 
de vibrações (SPIEGEL, 1971). 
 
Transformada discreta FFT 
Os analisadores de Fourier modernos são baseados em microcomputadores 
digitais, sendo necessário, portanto, para a análise de vibrações mecânicas, que os sinais 
sejam convertidos de contínuos para discretos, através do processo de amostragem e 
digitalização. Nesse caso, há a necessidade da Transformada de Fourier Discreta (FFT), 
uma vez que os sinais foram convertidos. Assim, x(t) passa a ser uma função discreta no 
tempo xk = x(k t) definida somente para um conjuntode N valores de (tk= k t, k= 
1,N), igualmente espaçados no tempo de t. A série de Fourier transforma-se então na 
seguinte série finita: 
 ( ) ∑ ( 
 
 
 
 
 
)
 
 
 k=1,N 
(19) 
De forma semelhante ao caso contínuo, pode-se definir a transformada discreta, a partir 
da série, como: 
 
 ( ) 
 
 
∑ 
 
 
 ( ) 
 
A transformada de Fourier é, portanto uma transformação do domínio de análise 
que possibilita uma visualização melhor das propriedades espectrais contidas no sinal de 
vibração. 
 
 
 
SENSOR DE ACELERAÇÃO GRAVITACIONAL 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
O sensor de aceleração gravitacional denominado acelerômetro usado no 
protótipo é o circuito integrado MMA7361L ±1.5g, ±6g Three Axis Low-g 
Micromachined Accelerometer da Freescale. 
Segundo Rueda et al. (2005), sensores são dispositivos que mudam seu 
comportamento sob a ação de uma grandeza física, podendo fornecer diretamente ou 
indiretamente um sinal que indica esta grandeza. 
O sensor MMA7361L figura 3 é um é um sensor capacitivo com processamento 
de sinal onde qualquer inclinação nos eixos faz com que a capacitância do sensor se 
altere, assim o conversor de capacitância para nível de tensão faz a conversão 
simultânea, além disso, os sensores são de baixo consumo de energia e são 
encapsulados no mesmo chip fechado hermeticamente. 
 
Figura 3 Acelerômetro em SMD acoplado na placa com capacitores de filtro. Fonte: 
(FREESCALE, 2008). 
 
A célula gravitacional (G-Cell) é formada por materiais semicondutores 
(polysilicon), fixados em um ponto central de massa que se move entre as paredes 
internas do chip, a medição da distância entre esses materiais determina a aceleração da 
gravidade (mV/g), como o centro se move com a aceleração, o valor de capacitância 
também mudará, pois é dado pela equação 21 onde A é a área, ε é a constante dielétrica 
e d é a distância. 
 
d
A
C
.

 
(21) 
Para esse protótipo adotamos o sensor MMA 7361L experimentalmente, devido 
a sua vasta aplicação, características adequadas para respostas às entradas e facilidade 
de aquisição no mercado. A figura 4 apresenta o diagrama de blocos do MMA761L, 
para melhor entendimento. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
 Figura 4 Diagrama de blocos do MMA7361L. Fonte: (FREESCALE, 2008). 
 
 
MICROCONTROLADOR 
Um Microcontrolador pode ser definido como: Um pequeno componente 
eletrônico, dotado de uma “inteligência programável”, utilizado nos controles de 
processos lógicos segundo (SOUZA, 1999). A base para o funcionamento e 
processamento do protótipo é um microcontrolador da família PIC18F, de fabricação da 
MICROCHIP, o modelo utilizado é o PIC18F4520, que possui 32 Kbytes para 
programação interna 1536 bytes de memória RAM (Random Access Memory) de dados, 
13 canais configuráveis A/D de 10 bits de resolução e retenção de dados na memória 
flash que pode armazenar dados por até 40 anos. 
Os Microcontroladores PIC18F possuem uma resolução de 10 bits para os canais 
analógicos sendo assim é necessário utilizar alguns registradores para controle dos 
PORT´s, nessa versão usamos o controle ADCON1 que é responsável por dizer quais 
serão os pinos que irão ser canais analógicos. Para execução da conversão compara-se a 
tensão de entrada do canal A/D com a tensão de referencia Vref+ & Vref-, considerando 
que a Vref+ é igual a 1023 e Vref – é igual a 0. 
O funcionamento do processo de conversão é baseado em um capacitor interno 
do microcontrolador de 25 pF, quando a leitura é iniciada, o capacitor desconecta e a 
tensão do capacitor mantém constante, esse capacitor mantém a tensão enquanto o 
processo de conversão é feito, e caso haja ruídos na conversão, o mesmo não será lido 
devido ao microcontrolador priorizar a tensão no capacitor. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
O capacitor é ligado e durante o processo de conversão é desligado, o tempo 
mínimo para carga dos 5 V é de 1.4 µs com impedância até 2500Ω, após conversão o 
capacitor é desligado do circuito de entrada esse processo dura 100 ns o TAD (Tempo 
de Aquisição de Dados) é um o tempo que determina a frequência de trabalho do 
conversor A/D esse tempo depende da configuração dos registradores, após conversão o 
capacitor é desligado, após o término do processo o capacitor é ligado na entrada 
analógica. O registrador que configura o TAD é o ADCON2 que pode configurar para 
0,7 µs e 25µs. 
 
FONTES DE ALIMENTAÇÃO 
Para alimentação do Microcontrolador PIC18F4520 e também do CI MAX232 
são necessários tensão de 5 Volts DC. 
O PIC18F consome cerca de 200 mA em seu consumo máximo, e o CI MAX232 
consome cerca de 10 mA. Sendo assim como base para esse projeto optamos pelo uso 
do CI LM7805 que é um regulador de voltagem de 3 pinos, para fornecer 5 V DC/1A 
para alimentação do PIC e também do MAX 232. 
 
 Figura 5 Fonte com saída de 5 V DC. Fonte: (KEC SEMICONDUTOR, 2010). 
 
 Para o Acelerômetro utilizamos o CI LM317 que também é um regulador de 
voltagem de 3 pinos, onde foi dimensionado por divisor de tensão de forma a fornecer 
3.3 V DC que irá alimentar o Acelerômetro MMA7361 onde o consumo médio é da 
ordem de 600 µA. 
Com o uso do CI LM317 da National, podemos construir uma fonte regulável 
entre 3 e 40 Volts com limites de até 3,4 A de corrente, através da equação da figura 6 
podemos trabalhar com diversos valores saída de tensão. Para esse projeto utilizamos 
um resistor de referencia de 480 Ω e como R2 um trimpot de 1,2K, ajustando a 
resistência até chegar a +/- 780Ω tendo V out de 3,3 Volts. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 6 Fonte regulável com uso do LM317. Fonte: (NATIONAL SEMICONDUTOR, 2004). 
 
Na concepção das fontes internas consideramos as diversas flutuações que 
podem acontecer na operação do circuito, sendo assim utilizamos para efeito de cálculo 
o fator de ripple. Como a alimentação do microcontrolador deve estar entre 4,2 Volts e 
5,5 Volts para uma frequência de trabalho de 40Hz, optamos por manter o ripple o 
menor possível, esse filtro de rejeição de ripple possui efeitos até a faixa de 120 Hz. 
Sendo assim pela equação 22: 
 
 
Vm
Vdc
Cf
IdcppVr
rmsVr
..3.43.2
).(
)( 


 
(22) 
 Obtivemos para o circuito um valor menor que 0,5%, esse cálculo de ripple foi 
aplicado para ambas as fontes. 
 
COMUNICAÇÃO SERIAL 
 O CI MAX232 foi adotado para esse protótipo devido a sua versatilidade, baixo 
custo e alta funcionalidade (TEXAS INSTRUMENTS, 1989). 
Este CI é um conversor de tensão de nível TTL para RS232, ele é composto por 
um circuito interno formado por capacitores que geram tensões de -15 a +15 Volts a 
partir de uma fonte de 5 V DC, sua função é conectar o microcontrolador a porta serial 
do PC através dos pinos de RX e TX. 
Segundo a Texas Instruments (1989), comunicação serial é o tipo de 
comunicação onde à mensagem é convertida em pacotes de bits e enviados por um 
canal, um a um em sequencia, cada bit é a representação da parte de uma mensagem e 
quando recebidos pelo receptor, são reordenados. O LSB (Less Significative Bit) é o 
 
 Revista Engenho, vol.9 – Junho de 2014primeiro bit, o protocolo RS232. O controle do clock é feito pelo transmissor e receptor 
por se tratar de um protocolo assíncrono. Quando existe controle por hardware o 
protocolo usa os sinais de controle RTS (ready to send) e o CTS (clear to send) para 
controle de fluxo. Para iniciar um envio o transmissor ativa o pino RTS e o receptor 
prepara o pino CTS após receber a confirmação de que o CTS do transmissor esta ativo 
estabelece a transmissão. Cada byte possui bits de start e stop, sendo o bit 1 start e o 
último bit o de stop. 
No caso desse protótipo utilizamos o principio de comunicação assíncrona com 
controle por software, onde utilizamos a taxa de 9600 bps (Bits por segundo) no 
Microcontrolador e também no receptor. 
É enviado um bit de start, em seguida aguarda-se um tempo e envia-se o 
conjunto de 8 bits e mais o bit de stop, com mesmo intervalo de tempo. 
O receptor por sua vez percebe a borda de descida (de nível lógico 1 para nível 
lógico 0) recebe os 8 bits e aguarda o bit de stop, como tem a velocidade de transmissão 
conhecida, ele efetua a leitura. 
 
Figura 7 Esquema de pinos do CI MAX232. Fonte: (Texas, 2002). 
 
Na RS232 o nível lógico 1 representa uma tensão de -30 V e o nível lógico 0 
representa uma tensão de +30 V, para o protocolo é considerado nível de transição as 
tensões de -3 V e + 3 V ou seja o sinal será indefinido. 
Ocorre a transição de sinal por bit, entretanto a taxa de transferência e a bit rate 
são idênticas essas taxas são mensuradas por transição elétrica por segundo. 
 
MATERIAIS E MÉTODOS 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
A pesquisa baseou-se inicialmente na exploração bibliográfica de conteúdos 
relacionados à fundamentação sobre o fenômeno físico da vibração e para o 
desenvolvimento das funcionalidades do sistema embarcado proposto, que deram 
direcionamento inicial para a elaboração do projeto e consequentemente a constituição 
do protótipo, realizando o levantamento de componentes básicos, tecnologia a ser 
utilizada e funcionamento do sistema. 
Esse sistema conta com um sensor de aceleração gravitacional, um 
microcontrolador, uma fonte de alimentação, um sistema de comunicação serial e um 
software para aquisição de dados no computador. 
 
Figura 8 Diagrama de blocos do protótipo. Fonte: (Construído pelos autores.) 
 
O projeto tem como base um sensor de aceleração gravitacional de 3 eixos, que 
converte a aceleração da gravidade em capacitância e em seguida em nível de tensão, 
que por sua vez é lido por um chip (microcontrolador). O dispositivo processa os sinais 
referentes aos 3 eixos (X, Y, Z), faz a filtragem referentes a ruídos e os amplifica 
dobrando os valores lidos, por meio de varredura em alta velocidade aproximadamente 
100ms (milissegundos), convertendo em valores de 0 a 1023 que é equivalente a 
resolução do canal analógico de 10 bits. Esses valores são enviados na ordem X, Y, Z 
convertidos para base alfanumérica e enviados para o conversor serial chip MAX232 
que faz a conversão do nível de tensão TTL (Transistor to Transistor Logic) para o 
padrão serial RS232 que é enviado para o microcomputador onde temos o software de 
leitura que promove a aquisição de dados escrito em linguagem C# que faz a exibição 
de 3 gráficos de tensão x tempo referente aos eixos X, Y, Z. 
Ao mesmo tempo em que o software faz a aquisição dos dados através do 
protocolo serial RS232, ele armazena as leituras em um arquivo extensão -txt, que pode 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
ser aberto e tratado por softwares de modelagem de dados e estatística assim como o 
Microsoft Excel. 
O protótipo foi montado em placa perfurada para devidos testes e construção. 
Após a elaboração e confecção do protótipo foram realizados diversos testes e 
ajustes, com a finalidade de aumentar a precisão das medições e a eliminação de ruído 
térmico. 
Para verificação das funcionalidades deste protótipo foram feitas três leituras 
comparativas e em seguida suas respectivas análises. 
Nesta atual configuração o protótipo é capaz de realizar 20 leituras por segundo, 
ou seja, onde se levar em consideração que são coletadas 3 leituras instantâneas X, Y, Z, 
temos essa quantidade triplicada (30 leituras por segundo e 1800 leituras por minuto). 
Primeiramente verificamos o ruído térmico presente no protótipo, para essa 
medição deixamos o conjunto de testes (motor e mancal) completamente desligados e 
notamos que o nível de ruído presente é irrelevante, para a faixa de frequência que 
desejamos verificar, pois os gráficos exibidos na tela demonstram pouca oscilação, que 
é basicamente influencia do ruído térmico proveniente do chaveamento interno dos 
componentes e capacitâncias do circuito. 
 
Figura 9 Ruído térmico gerado pelo sistema. Fonte: Fonte: (Autores.) 
 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
Em seguida fizemos a leitura de dois mancais em diferentes estados de 
conservação, sendo um novo e o outro já com metade da sua vida útil, onde visualmente 
não é possível perceber seu real estado de operação. 
As leituras realizadas foram trabalhadas no software Microsoft Excel que 
recebeu a análise estatística e, onde foi possível fazer as devidas análises de cada 
mancal analisado. 
 
FASE 1 – CONSTRUÇÃO E PROJETO DO PROTÓTIPO 
Circuito eletrônico Projetado 
A figura 10 apresenta o diagrama eletrônico projetado para o protótipo da 
pesquisa e a figura 11 exibe o protótipo construído em placa padrão perfurada: 
 
Figura 10 Circuito eletrônico projetado com hardware do protótipo para testes de validação da 
pesquisa. Fonte: (Construída pelos autores.) 
 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
Figura 11 Foto do protótipo montado em placa perfurada. Fonte: (Construída pelos autores.) 
 
Programação Do Firmware Do Microcontrolador 
Na criação do firmware do microcontrolador, utilizamos a ferramenta MicroC 
Pro for PIC, baseando se na linguagem de programação em C para Microcontroladores. 
Como as leituras executadas pelo acelerômetro são sinais analógicos de nível de 
tensão em relação ao tempo, optamos por usar o PIC18F4520 que possui internamente 
recursos de conversão A/D e uma resolução de até 10 bits para conversão, 
possibilitando uma resposta mais precisa em relação à leitura realizada. A figura 12 
demonstra em forma de fluxograma todo funcionamento do firmware do 
Microcontrolador. 
 
 Revista Engenho, vol.9 – Junho de 2014 
 
 
 
 
Neste Firmware utilizamos para o ADCON1 as seguintes características: 
 Seleção de “Clock” do conversor: divisão da frequência externa por 4; 
 Formato do resultado: justificado a direita; 
 TAD (Tempo de aquisição): 6 TAD; 
 Canal utilizado: canal AN0, AN1, AN2. 
 Interrupção da conversão A/D: desligada; 
 Tensão de referência: interna baseada nos valores de Vdd e Vss 
Em seguida usamos a função “Adc_read(canal)” para salvar os valores de 
conversão AD de cada canal, como a resolução é de 10 bits devemos utilizar uma 
variável do tipo inteiro “int” para armazenar o valor do canal A/D. 
Quando o acelerômetro está no ponto de “0” gravidade, ou seja, quando está 
posicionado em algum dos ângulos em relação a gravidade, ele apresenta diferentes 
níveis de tensão. Como o acelerômetro pode detectar acelerações nos 3 eixo diferentes 
(x, y, z), isso determina os níveis de tensão para cada ângulo de inclinação é necessário 
possuir uma referencia para o ponto de zero aceleração, sendo assim no software 
supervisório tratamos todas as variáveis.