Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE OURO PRETO
ESCOLA DE MINAS
CECAU - COLEGIADO DE ENGENHARIA DE
CONTROLE E AUTOMAÇÃO
FILIPE DE CARVALHO PEDROSA
MONITORAMENTO ONLINE DE MEDIDOR DEESPESSURA POR RAIOS GAMA EM TREM DELAMINAÇÃO A QUENTE UTILIZANDO-SE DE
PLATAFORMA ANDROID
MONOGRAFIA DE GRADUAÇÃO EMENGENHARIA DE CONTROLE E AUTOMAÇÃO
Ouro Preto, 2014
FILIPE DE CARVALHO PEDROSA
MONITORAMENTO ONLINE DE MEDIDOR DEESPESSURA POR RAIOS GAMA EM TREM DELAMINAÇÃO A QUENTE UTILIZANDO-SE DE
PLATAFORMA ANDROID
Monogra�a apresentada ao Curso de
Engenharia de Controle e Automação
da Universidade Federal de Ouro
Preto como parte dos requisitos para
a obtençãoo do Grau de Engenheiro de
Controle e Automação.
Orientador: Prof Dr. Luiz Fernando
Rispoli Alves
Ouro Preto
Escola de Minas - UFOP
Dezembro/2014
Ficha SISBIN:
Folha de assinaturas:
Dedico este trabalho à minha família, em especial a meu pai, minha fonte de inspiração,
minha mãe pelo apoio e amor incondicional e minha irmã por sempre estar presente.
AGRADECIMENTOS
Gostaria de estender os meus agradecimentos a todos as pessoas diretamente envolvi-
das na minha graduação, em especial aos técnicos administrativos e corpo docente que,
sempre solícitos, sempre se �zeram disponíveis. Um muito obrigado ao meu orientador
professor Dr. Luiz Fernando Rispoli Alves e demais componentes da banca que também
constituem pessoas de suma importância na minha trajetória na graduação.
Agradeço também em especial a Fundação Gorceix pelo apoio ao longo dos anos da
minha graduação, atuando como um forte aliado e parceiro certo nas horas de necessidade.
À Usiminas por me abrir as portas e me conceder a oportunidade de estágio tornando
possível o desenvolvimento deste trabalho.
Agradeço ainda meu supervisor de estágio engenheiro Leandro Rodrigues Albionti
de Castro pela con�ança depositada, garantindo sempre condições necessárias para que
o projeto fosse desenvolvido. Estendo também meus agradecimentos ao meu tutor no
desenvolvimento deste trabalho, MSc. Eliezio Scarabelli Silva pela dedicação e tempo
despendido nas fases de concepção e implementação do projeto.
RESUMO
Neste trabalho é apresentada toda metodologia e descrição de um aplicativo desen-
volvido para dispositivos móveis, rodando em plataforma Android, com o propósito de
monitorar, em tempo real, todas as variáveis de processo do medidor de espessuras do
trem de laminação a quente da área de chapas grossas na unidade da USIMINAS em
Ipatinga-MG. O Aplicativo foi desenvolvido em ambiente Basic4android e tem como su-
porte, para um funcionamento robusto, um banco de dados, servidor OPC, web server
e também lança mão da tecnologia de serviço GCM, gratuitamente disponibilizada pela
Google.
Palavras-chave: Android, GCM, Servidor OPC, Basic4Android, Banco de Dados, Web-
server
ABSTRACT
In this thesis, it is presented the entire methodology and description of the develop-
ment of an application intended for mobile devices, running on Android platform, with
the purpose of monitoring in real time, all the process variables of the hot rolling mill's
thickness gauge at USIMINAS in Ipatinga-MG. The application was developed in Ba-
sic4android environment. It is supported by a database, OPC servers, web server, and
also makes use of the GCM service technology. The latter is available from Google for
free.
Keywords: Android, GCM, OPC Server, Basic4Android, Database, Webserver
SUMÁRIO
SUMÁRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . 11
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.1 Objetivos especí�cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Justi�cativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Elementos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 REVISÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Conformação Mecânica . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Processo de Laminação . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Laminação a Quente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Laminação a Frio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Medidor de Espessuras por Raios Gama . . . . . . . . . . . . . . . . 18
2.4 Sistema de detecção . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Plataforma Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Arquitetura Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 Servidor OPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 Arquitetura OPC e Implementação . . . . . . . . . . . . . . . . . . . 25
2.8.1 Conexões adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9 Basic4Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Google Cloud Messaging - GCM . . . . . . . . . . . . . . . . . . . . 27
3 DESENVOLVIMENTO E MÉTODOS . . . . . . . . . . . . . . . . 30
3.1 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Sistema de Gerenciamento de Banco de Dados (SGBD) . . . . . . 30
3.3 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 PROGRAMAÇÃO ANDROID . . . . . . . . . . . . . . . . . . . . 33
4.1 Desenvolvimento de um Aplicativo . . . . . . . . . . . . . . . . . . . 33
4.2 Componentes de um Aplicativo . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.2 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10
4.2.3 Content Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.4 Broadcast Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5 IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 Sobre o Aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Diagramas ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Relações/Tabelas no Banco de Dados da aplicação . . . . . . . . . 40
5.4 Descrição do aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.1 Primeiro acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.2 Menu principal e data logger . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4.3 Cadastro de novos equipamentos . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.4 Menu secundário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.5 Noti�cações e alerta áudio sensorial . . . . . . . . . . . . . . . . . . . . . 46
5.4.6 PDI's de laminação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4.7 Ranking de falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4.8 Registro de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
LISTA DE FIGURAS
Figura 1 � Tipos de laminadores utilizados na indústria . . . . . . . . . . . . . . . 16
Figura 2 � Processo de LQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figura 3 � Processo de LF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figura 4 � Diagrama da medição de espessura baseada na atenuação de radiação . 19
Figura 5 � Con�guração do medidor de raios gama na Usiminas . . . . . . . . . . 20
Figura 6 � Diagrama do sistema de detecção - Cintilador . . . . . . . . . . . . . . 21
Figura 7 � Arquitetura Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figura 8 � Arquitetura de comunicação do padrão OPC . . . . . . . . . . . . . . . 25
Figura 9 � Conexão típica de um servidor OPC . . . . . . . . . . . . . . . . . . . 26
Figura 10 � Ambiente de programação Basic4Android . . . . . . . . . . . . . . . . 27
Figura 11 � Tipos do serviço de push message . . . . . . . . . . . . . . . . . . . . . 29
Figura 12 � Ambiente de um Sistema de Banco de Dados simpli�cado . . . . . . . . 31
Figura 13 � Relações entre eventos e suas descrições . . . . . . . . . . . . . . . . . 39
Figura 14 � Relacionamento entre setups de laminação e seus detalhamentos . . . . 39
Figura 15 � Relações entre equipamentos e suas descrições nas demais entidades . . 40
Figura 16 � Primeiro acesso de usuário . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 17 � Menu principal e preferências para data logger . . . . . . . . . . . . . . 44
Figura 18 � Gestão de equipamentos de interesse . . . . . . . . . . . . . . . . . . . 45
Figura 19 � Menu secundário e lista de equipamentos de interesse . . . . . . . . . . 46
Figura 20 � Sistema de noti�cações do aplicativo . . . . . . . . . . . . . . . . . . . 46
Figura 21 � Setups de laminação para duas placas A e B distintas . . . . . . . . . . 47
Figura 22 � Top 5 falhas registradas por equipamento . . . . . . . . . . . . . . . . 48
Figura 23 � Registros de falhas por equipamento . . . . . . . . . . . . . . . . . . . 49
Figura 24 � Registros de falhas por equipamento . . . . . . . . . . . . . . . . . . . 49
12
LISTA DE SIGLAS E ABREVIATURAS
GCM: Google Cloud Messaging
OPC: OLE for Process Control
BD: Banco de Dados
SGBD: Sistema de Gerenciamento de Banco de Dados
PC: Personal computer
OHA: Open Handset Alliance
OS: Operating System
LQ: Laminação a quente
LF: Laminação a frio
CLP: Controlador Lógico Programável
SCADA: Supervisory Control and Data Acquisition
IHM: Interface Homem Máquina
TCP: Transmission Control Protocol
RAD: Rapid Application Development
C2DM: Cloud to Device Messaging
APK: Android Application Package File
VM: Virtual Machine
MASI: Manutenção de Sistemas Industriais
ERD: Entity Relationship Diagram
1 INTRODUÇÃO
O processo de laminação, seja ele a quente ou a frio, consiste-se basicamente em um
processo de conformação mecânica de metais, onde estes passam por entre dois rolos
giratórios que os comprimem reduzindo sua seção e aumentando-se o seu comprimento
a dimensões e formas preestabelecidas (ABAL, 2009). Para se obter o produto �nal nas
dimensões e formas preestabelecidas, são necessários vários ciclos de laminação, ditos
passes.
Uma das principais variáveis nestes processos é justamente a força de laminação que
depende fortemente de diversos fatores, tais como: a temperatura do material, o valor da
redução do passe, o atrito entre o material e os cilindros, a velocidade de laminação, a
composição química do aço, a geometria dos canais dos cilindros, a área de contato entre
o material e os cilindros, entre outros (GOUVÊA et al., 2009).
Portanto, dada a importância da quantização dessa variável para o ideal discorrer
do processo, justi�ca-se todo o cuidado com o sistema medidor de espessura que indica
diretamente as ações causadas pelo emprego da força de laminação sobre os cilindros e o
corpo laminado.
1.1 Objetivo Geral
Implementar um aplicativo sobre a plataforma Android que efetue, em tempo real, o
monitoramento de todas as variáveis de processo do medidor de espessuras por raios
gama no setor de laminação de chapas grossas na unidade da Usiminas em Ipatinga-MG.
1.1.1 Objetivos especí�cos
• Desenvolvimento de aplicativo com interface grá�ca con�gurável pelo usuário;
• Apresentar ranking de falhas entre equipamentos;
• Apresentar ranking de falhas por código de equipamentos individualmente;
• Comunicação entre servidor OPC e aplicativo através do Google Cloud Messaging ;
• Apresentar histórico recente de falhas;
• Aplicativo con�gurável de acordo com a necessidade de cada usuário.
14
1.2 Justi�cativa
A relevância do desenvolvimento deste trabalho se baseia, principalmente, na grande im-
portância da correta aplicação da força de laminação em cada passe como escreve (GOU-
VÊA et al., 2009). O desenvolvimento e posterior emprego dessa ferramenta também se
justi�ca pela conquista de novos recursos para gerência da manutenção de sistemas na
Usiminas. A aplicação possibilitará que se programe atividades de inspeção com base em
histórico recente de cada equipamento, além de permitir uma abordagem mais direta para
manutenção corretiva em caso de falhas.
1.3 Metodologia
O presente trabalho é fruto de atividade de estágio no parque industrial da Usiminas em
Ipatinga-MG. Inicialmente foi agendada uma visita às intalações da enpresa para tomada
de conhecimento sobre o problema e estudos sobre abordagem e expectativas/exigências
da empresa.
Numa segunda etapa, de�niu-se o escopo do projeto que, em um todo, é bastante
extenso. Por esta razão, um analista da empresa foi designado a implementar um sistema
para coleta de dados do campo e posterior envio dessas informações ao servidor GCM que
disponibilizará tais mensagens a todos os dispositivos alvo.
Por �m, a abordagem proposta foi implementada de forma a atender as expectativas
e restrições da empresa. Na data de apresentação deste trabalho, o aplicativo encontra-se
em fase de testes e validação na Usiminas.
1.4 Elementos do Trabalho
O presente trabalho está organizado da seguinte forma: o Capítulo 1 apresenta uma breve
introdução ao tema aqui abordado e discorre sobre os objetivos e motivação do projeto.
O Capítulo 2 traz uma revisão teórica sobre os temas abordados e ferramentas utilizadas
nesse trabalho. O Capítulo 3 destaca algumas ferramentas de maior importância na
implementação deste projeto. Já o Capítulo 4 apresentam-se as partes constituintes de
um aplicativo Android. Logo após, no capítulo 5 é discutida toda a implementação do
aplicativo em suas partes mais importantes. Por �m, o Capítulo 6 traz as conclusões,
análises �nais e sugestões para trabalhos futuros.
2 REVISÃO TEÓRICA
2.1 Conformação Mecânica
Conformação Mecânica é o nome genérico que se dá a processos nos quais uma força
externa é aplicada à matéria-prima, obrigando-a a adquirir a forma desejada por defor-
mação no regime plástico. Em outras palavras, são todos os processos que exploram a
deformabilidade plástica dos materiais (HELMAN; CETLIN, 1993). O volume e a massa
do metal (matéria-prima) se conservam nestes processos, mas sua geometria pode sofrer
grandes alterações através de forças aplicadas por ferramentas adequadas que podem va-
riar desde pequenas matrizes até grandes cilindros (como os empregados nos processos de
laminação). Em função da temperatura e do material utilizado, a conformação pode ser
classi�cada como: por trabalhos a frio, a morno e a quente. Cada um desses trabalhos
fornecerá características especiais ao material e à peça obtida. Além disso, os processos
de conformação mecânica, desenvolvidos para aplicações especí�cas, podem ser classi�-
cadas com base em critérios tais como: o tipo de esforço que provoca a deformação do
material, a variação relativa da espessura da peça, o regime de operação de conformação,
o propósito da deformação, etc.
Os processos a quente são caracterizados pelo emprego de tensões de compressão
menores, ausência de encruamento no produto e alta ductilidade da liga na temperatura
de conformação. Por outro lado, os produtos apresentam superfícies contendo carepa,
resultante da oxidação do metal em alta temperatura e tolerâncias dimensionais mais
abertas. Entretanto, a característica mais relevante dos produtos conformados a quente
é o seu elevado grau de sanidade interna (HELMAN; CETLIN, 1993).
Os processos de conformação realizados a frio são caracterizados por elevadas tensões
de compressão, encruamento do produto e ductilidade da liga inferior à dos processos a
quente. A qualidade super�cial e a precisão dimensional dos produtos conformados a frio
são superiores à obtida pelos processos a quente (HELMAN; CETLIN, 1993).
2.2 Processo de Laminação
Laminação é um processo de conformação mecânica que consiste na redução progressiva da
seção transversal de um lingote ou barra por comprimento do metal. Essa transformação
se dá por meio da passagem do material laminado entre dois ou mais cilindros de aço ou
16
ferro fundido com eixos paralelos e de geratrizes retilíneas que giram em torno de si e
em sentidos opostos. O produto da laminação é puxado pelos cilindros sob o efeito das
forças de atrito e, ao passar pelo trem de laminação, sofre deformação plástica. Durante
o processo, as propriedades mecânicas do material são modi�cadas, tendo a resistência
e a dureza aumentada e a ductilidade diminuída. Também é importante ressaltar que,
em diversas etapas, faz-se uso de limitadores laterais que são aparatos instalados nos
laminadores a�m de manter o comprimentos das tiras constante. Atualmente a indústria
lança mão de dois processos tradicionais para laminação: Laminação a Quente (LQ) e
Laminação a Frio (LF). A�gura 1 descreve os principais tipos de laminadores encontrados
na indústria atualmente.
Figura 1 � Tipos de laminadores utilizados na indústriaFonte: (ABAL, 2009)
Os principais produtos laminados são chapas planas ou bobinadas que têm diversas
aplicações em distintos setores na economia como transportes, construção civil, indústria
pesada, bens de consumo, dentre outras.
17
2.2.1 Laminação a Quente
A temperatura de trabalho se situa acima da temperatura de recristalização, que para o
aço de baixo carbono essa temperatura inicia entre 1100 e 1300 ◦C e termina entre 700 e
900 ◦C, de modo a reduzir a resistência à deformação plástica em cada passagem e permitir
a recuperação da estrutura do metal com o propósito de evitar o encruamento para os
passes subsequentes do processo. A laminação a quente, portanto, comumente se aplica
à operações iniciais ou operações de desbaste, onde faz-se necessárias grandes reduções
transversais. A �gura 2 esquematiza o processo de laminação a quente.
Figura 2 � Processo de LQFonte: (ABAL, 2009)
2.2.2 Laminação a Frio
Com a matéria prima oriunda da laminação a quente, a laminação a frio é realizada a
temperaturas bem inferiores às de recristalização do metal, normalmente à temperatura
ambiente. A LF é empregada para produzir folhas e tiras com acabamentos super�ciais
superiores quando comparadas com as tiras produzidas pela LQ. Os trens dos laminadores
a frio podem ser dimensionados para reduções entre 30%− 70% por passe e ainda empre-
gam controles so�sticados de espessura e planicidade. A laminação a frio resulta numa
elevação da resistência à tração, da dureza super�cial, do limite elástico e em redução da
ductilidade. A etapa �nal se caracteriza pelo recozimento com o propósito de restituir-lhe
as propriedades mecânicas e depois, a um passe de encruamento para uniformizar a super-
fície e obter uma dureza homogênea em toda a área. A �gura 3 esquematiza o processo
de laminação a frio.
Figura 3 � Processo de LFFonte: (ABAL, 2009)
18
2.3 Medidor de Espessuras por Raios Gama
Medições precisas de espessuras de tiras e chapas são de fundamental e crítica importância
no controle de processos e controle de qualidade de produtos laminados planos. Através
dos últimos anos, vários métodos (tanto com contato ou sem contato direto) têm sido
desenvolvidos em uma variedade de geometrias e arranjos físicos (ZIPF, 2010).
Um método em particular emprega o entendimento da reação de um metal à incidência
de radiação (primariamente fotônica / raios gama). Dependendo do nível de energia, a ra-
diação incidente interage com as estruturas atômicas do material e ou passa pelo material,
ou é absorvida, espalhada ou envolvida em produções de pares de alta energia. A radia-
ção resultante transmitida aparece como um padrão de feixe disperso, tendo intensidade
atenuada e conteúdo espectral modi�cado. Uma porção da radiação que sai é coletada
por instrumentos de detecção que computam um sinal funcionalmente relacionado com a
integral da intensidade de radiação recebida ao longo da largura de banda espectral do
detector (ZIPF, 2010).
O conhecimento da intensidade da fonte de radiação, conteúdo espectral, composi-
ção química do material e as características de resposta do detector são extremamente
necessários para processar os sinais e tornar a medição de espessura possível, robusta e
con�ável.
Tipicamente, como observa-se na �gura 4, o plano da tira/chapa é orientado horizon-
talmente com a fonte de radiação e o detector é montado acima e abaixo da tira. Há um
certo número de con�gurações diferentes variando-se de fonte estacionária / fonte �sica-
mente �xada e detector acima e abaixo da tira, a con�gurações montadas em C ou O que,
em alguns casos, permitem a medição transversal do per�l da tira. Há também a possibi-
lidade do arranjo com multi-fontes e multi-detectores que provê medidas instantâneas do
per�l da tira. Independentemente do arranjo físico, todos os princípios físicos se aplicam.
Alguns requerimentos fazem-se necessários para o correto funcionamento do sistema de
medição:
1. Deve ser de natureza contínua (Não medições pontuais);
2. Deve-se medir sobre uma área de superfície razoavelmente pequena (círculo de
25mm de diâmetro);
3. Deve-se efetuar medidas enquanto a tira se move (a velocidades não maiores que
1500 mpm);
4. Deve ser de resposta rápida (5-20 ms);
19
5. Deve ser independente ou compensado para variações de ligas;
6. Deve ser compensado para variações das condições ambiente;
7. Deve ser altamente imune à ruídos e interferências externas;
8. Não deve dani�car a superfície da tira.
Figura 4 � Diagrama da medição de espessura baseada na atenuação de radiaçãoFonte: (ZIPF, 2010)
2.4 Sistema de detecção
Omedidor de espessuras por raios gama da Usiminas é fabricado pela Toshiba Corporation
e prevê uma fonte radioativa carregada com Césio 137 como seu elemento radioativo. A
con�guração do medidor, vide �gura 5, pode ser descrita como um arranjo em C e prevê
medições de centro e uma das bordas da tira. As fontes e os detectores estão �sicamente
�xados em um carro sobre trilhos que desloca-se, colocando-se sempre a 150mm da borda
da placa ou tira que está sendo laminada.
Conforme pode ser observado na �gura 5, são tomadas duas medições de espessura na
chapa laminada. Isso se deve a um fenômeno frequentemente observado nos processos de
laminação denominado coroamento. Como a força de laminação é aplicada diretamente
aos mancais no eixo do cilindro de laminação, esse cilindro sofre �exão acarretando em
corpos laminados com coroamento, ou seja, espessuras menores nas bordas que no centro.
20
Como este é um fenômeno extremamente indesejado na produção de produtos laminados
planos, tomam-se medições em pelo menos dois pontos a �m de fornecer aos controladores
informações su�ciente para que ações sejam tomadas no sentido de limitar a ocorrência
deste fenômeno.
Figura 5 � Con�guração do medidor de raios gama na UsiminasFonte: (TOSHIBA, 1990)
21
Um componente de suma importância no processo de medição de espessuras é o cintila-
dor. Quando o feixe de raios gama que representa a porção que passou por toda a extensão
da espessura do corpo sendo laminado atinge o cintilador, um efeito luminoso muito fraco
é observado. Este efeito acontece como resultado da emissão de fótons pelo cintilador na
presença de incidência de radiação ionizante. A intensidade média desse efeito luminoso
é proporcional à intensidade da radiação incidente. Essa luz é, portanto, convertida em
elétrons pelo fotomultiplicador e, então, em um segundo estágio ampli�cada. A saída do
fotomultiplicador é tomada como corrente, que é subsequentemente, convertida em tensão
pelo pré-ampli�cador, alimentando uma caixa de junção de um conversor A/D de 16 bits.
Figura 6 � Diagrama do sistema de detecção - CintiladorFonte: (TOSHIBA, 1990)
2.5 Plataforma Android
O uso da telefonia móvel tem crescido dramaticamente ao longo dos últimos anos. (NTAN-
TOGIAN et al., 2014) apontam que a adoção global dos smartphones e tablets tem
crescido mais rapidamente que qualquer outra tecnologia de consumo na história da hu-
manidade. Globalmente, se uma comparação pode ser feita entre o uso dos computadores
pessoais (PC's) e os smartphones, os dispositivos móveis apresentam, aproximadamente,
3.5 vezes mais uso que os PC's de acordo com (GANDHEWAR; SHEIKH, 2010; MON-
TOYA et al., 2013). Os telefones celulares na sociedade hoje em dia deixaram de ser uma
mera ferramenta para efetuar e/ou receber ligações e trocar mensagens de texto para se
tornar um item pessoal que fornece entretenimento e informações.
A crescente na importância desses dispositivos móveis causou uma intensa competição
entre gigantes empresas relacionadas à artigos tecnológicos, dentre as principais citam-se:
Symbian, Google, Microsoft, Apple e Nokia em uma tentativa de capturar uma maior
fatia do mercado para a plataforma de telefonia móvel.
22
Um dos sistemas operacionais mais populares para smartphones já desenvolvidos é
a plataforma Android, como discorre (CHEN; CHEN; CHANG, 2011; KRISTIAN; AR-
MANTO; FRANS, 2012). Desde 2005 quando foi adquirido pela Google e lançado pela
mesma com a Open Handset Alliance (OHA) como código aberto em novembro de 2007.
O sistema Android se tornou muito popular entre desenvolvedores de software. Android
também fornece um Software Development Kit (SDK) que pode ser baixado livremente
pelo programador a�m de criar e desenvolver aplicações Android. A Google também dis-
ponibiliza o Android Market que pode ser utilizado para comercialização de aplicações
desenvolvidas por qualquer usuário.
Conforme atesta (PAYET; SPOTO, 2012), Android OS é o carro chefe no mercado
de sistemas operacionais para dispositivos móveis e embarcados tais como smartphones,
tablets, câmeras e televisores. É um sistema operacional para tais dispositivos cujas
camadas superiores são escritas em uma linguagem de programação também chamada
Android. Como uma linguagem, Android nada mais é do que Java com uma biblioteca
estendida para aplicações móveis e interativas, portanto, baseado em uma arquitetura
orientada a eventos. Qualquer compilador Java pode compilar aplicativos do Android,
mas o bytecode 1 Java resultante deve ser traduzido em um, muito otimizado, Dalvik
bytecode 2 �nal a ser executado no dispositivo.
A plataforma Android pode ser suscintamente descrita como sendo uma pilha de
softwares para dispositivos móveis que inclui um sistema operacional, middleware e apli-
cativos nativos. Desde o seu lançamento público o�cial, a plataforma Android tem cap-
turado o mais alto interesse de empresas, desenvolvedores e do público em geral. Daquele
momento até hoje, a plataforma sofreu constantes melhorias tanto em termos de funci-
onalidades quanto em termos de suporte de hardware e, ao mesmo tempo, ampliou-se
a extensão de novos tipos de dispositivos diferentes dos que foram originalmente pre-
tendidos (WIDHIASI et al., 2013). A programação Android começou a ser ensinada em
diversas universidades como um dos cursos opcionais em que os alunos podem se registrar.
Com uma enorme gama de recursos e facilidades oferecidas pelo Android, o programador
pode facilmente criar aplicativos que podem ser úteis e desenvolvidos de acordo com a
necessidade de cada um (WANG; QI; PAN, 2012).
2.6 Arquitetura Android
Android é um sistema operacional baseado em Linux projetado, primariamente, para
dispositivos com tecnologia touch screen tal como smartphones e tablets. Desde o seu1 Código compilado para rodar em uma máquina virtual invés de uma CPU2 Bytecode otimizado para as características dos sistemas operacionais para dispositivos móveis
23
surgimento, Android seguiu uma trajetória ascendente com ampla aceitação atingindo
dígito triplo de crescimento em 2012, escreve (NTANTOGIAN et al., 2014). Hoje o
Android OS detém aproximadamente 75% do mercado mundial e, até o momento, já
houveram mais de 48 bilhões de instalações de aplicativos Android em todo o mundo, o
que o caracteriza como o sistema operacional para dispositivos móveis que mais cresce
mundialmente.
O sistema Android utiliza de bibliotecas nativas em C de código aberto para executar
tarefas de sistema, além da linguagem Java para o desenvolvimento de aplicações. Para
a robusta execução de tais aplicações, o Android OS dispõe da arquitetura gra�camente
descrita pela �gura 7. Essa arquitetura, segundo descreve (MAIA; NOGUEIRA; PINHO,
2010), consiste de um número de camadas como Aplicativos, Application Framework,
bibliotecas e Android Runtime além de um Kernel Linux.
Figura 7 � Arquitetura AndroidFonte: (GANDHEWAR; SHEIKH, 2010)
A camada de aplicativos é a camada mais elevada na pilha de software e é essa ca-
mada que provém um conjunto de aplicações diretamente relacionadas ao núcleo, incluindo
Email, mensagens SMS, calendário, mapas, browsers, informações de contatos entre ou-
tros. A Application Framework é um software que é usado para implementar a estrutura
padrão de uma aplicação qualquer para um sistema operacional especí�co. A partir do
uso de gerenciadores, content provider e outros serviços, a Application Framework pode
remontar funções usadas por outras aplicações existentes (MAIA; NOGUEIRA; PINHO,
2010).
As camadas imediatamente inferiores à Application Framework consistem de duas par-
tes compostas por bibliotecas escritas inteiramente de C/C++. Essas bibliotecas serão
acessadas a partir de chamadas de sistema através de uma interface Java. Essa camada in-
24
clui funcionalidades tais como: Surface Manager, grá�cos 2 e 3D, Codecs de mídia, banco
de dados SQLite, além doWebKit. A segunda parte é o que se chama de Runtime Android
que inclui um conjunto de bibliotecas de núcleo, responsáveis pela maioria das funciona-
lidades disponíveis nas bibliotecas de núcleo da linguagem Java (MAIA; NOGUEIRA;
PINHO, 2010).
Cada aplicação Android é executada em seu próprio processo com uma instância pró-
pria da máquina virtual Dalvik, que executa arquivos no formato executável Dalvik (.dex)
que é a forma mais otimizada para um mínimo consumo de memória.
A camada mais baixa é o que se denomina deKernel Linux, haja visto que a plataforma
Android baseia-se na versão Linux 2.6 para serviços de sistema de núcleo tais como:
segurança, gerenciamento de memória, gerenciamento de processos etc. O kernel também
tem essencial importância em atuar como uma camada de abstração entre o hardware
e o resto da pilha de software que compõe a plataforma (MAIA; NOGUEIRA; PINHO,
2010).
2.7 Servidor OPC
Desde o seu primeiro surgimento em 1996, OPC ou simplesmente Object Linking and
Embedding (OLE for Process) tem sido cada vez mais utilizado na indústria. (ZAMAR-
REÑO et al., 2014) a�rmam que hoje em dia OPC é de fato o padrão empregado na
integração de sistemas. Ele facilita a comunicação entre os dispositivos industriais, quais
sejam CLP (Controlador Lógico Programável) e SDC (Sistemas de Controle Distribuído)
e seu escopo também abrange sistemas de automação e controle como IHM's (Interface
Homem Máquina) e SCADA (Supervisory Control and Data Acquisition system) além de
oferecer suporte à sistemas de gerenciamento e aplicações O�ce, como o Excel. Atual-
mente, praticamente todo conjunto de hardware e software desenvolvido para ambientes
industriais incluem a capacidade OPC.
Conforme de�niram (FOUNDATION, 2014; INSTRUMENTS, 2014), um servidor
OPC é uma interface padrão para comunicação de dispositivos no chão de fábrica, equi-
pamentos de laboratório, dispositivos elétricos de sistemas de teste e banco de dados.
Para evitar desnecessários desgastes e esforços para desenvolver protocolos especí�cos por
dispositivos, eliminar inconsistência e incompatibilidade entre dispositivos, prover suporte
para futuras alterações em hardware além de eliminar con�itos de acesso em sistemas de
controle industriais, a OPC Foundation de�niu um conjunto de interfaces padrão para
garantir que qualquer cliente possa acessar um dado dispositivo compatível com a tec-
nologia OPC. Este padrão se compõe de uma série de especi�cações desenvolvidas por
25
fornecedores do setor de automação, usuário �nal bem como desenvolvedores de software.
Tais especi�cações de�nem a interface entre Clientes e Servidores, bem como Servidores
e Servidores, não deixando de lado o acesso à dados em tempo real, monitoramento de
alarmes e eventos, acesso a histórico de dados e outras aplicações. Quase todos os fabri-
cantes de sistemas industriais de aquisição de dados e dispositivos controladores tais como
Controladores Lógicos Programáveis (CLP) são projetados para trabalhar com o padrão
estabelecido pela OPC Foundation.
A maior vantagem desse padrão é que ele é aberto, o que acarreta diretamente em bai-
xos custos para fabricantes e mais opções para usuários. Fabricantes de hardware somente
precisam prover-se de um servidor OPC para seus dispositivos, a�m de comunicarem com
qualquer cliente OPC. Desenvolvedores de software simplesmente precisam incluir recur-
sos de cliente OPC em seus produtos e eles se tornarão, instantaneamente, compatíveis
com milhares de dispositivos de hardware. Por último, o usuário �nal pode apenas esco-
lher qualquer software cliente OPC que queira, atentando-se apenas para especi�cações
de comunicação com o equipamento OPC e vice-versa.
Figura 8 � Arquitetura de comunicação do padrão OPCFonte: (�AHIN; BOLAT, 2009)
2.8 Arquitetura OPC e Implementação
Como mencionado no tópico anterior, o padrão de interfaceamento OPC permite que
aplicações rodando no servidor e um cliente comuniquem entre si. Na verdade, o OPC foi
projetado para atuar como uma camada entre as redes industriais e conjuntos controla-
dores, CLP's. O padrão OPC então especi�ca o comportamento que o interfaceamento é
esperado prover aos clientes, e os clientes recebem os dados do interfaceamento utilizando-
se de chamadas de funções e métodos orientados a eventos. Consequentemente, contanto
que uma aplicação computacional ou mesmo um sistema de aquisição e condicionamento
26
de dados contenha o protocolo cliente OPC, e um dispositivo industrial tenha uma inter-
face OPC associada, as aplicações podem comunicar-se com o dispositivo.
Uma conexão cliente-servidor OPC típica é a apresentada na �gura 9, onde uma
aplicação em ambiente Windows rodando em um computador desktop comunica-se com
um equipamento através de um CLP.
Há ainda outras possibilidades de conexão, das quais citam-se:
• Conexão entre um cliente OPC e múltiplos servidores, denominado Agregação OPC.
• Conexão entre um cliente OPC e um servidor através de uma rede industrial, deno-
minado tunelamento OPC.
• Conexão entre um servidor OPC e outro servidor compartilhando dados, denomi-
nado ponte OPC.
Figura 9 � Conexão típica de um servidor OPCFonte: (DATAHUB, 2014)
2.8.1 Conexões adicionais
O OPC DataHub é uma ferramenta de integração de dados OPC. É unicamente desen-
volvida para fazer todas as tarefas de conexão explicitadas no item anterior. É composta
por uma combinação entre servidor OPC e cliente OPC que suporta múltiplas conexões.
Dessa forma, é possível conectar-se vários servidores OPC simultaneamente, tanto na con-
�guração Agregação OPC como Ponte OPC. Dois OPC DataHub, um em cada ponta,
podem espelhar dados através de uma rede TCP possibilitando assim a comunicação por
Tunelamento OPC (DATAHUB, 2014).
Além de aumentar possibilidades de conexão entre um servidor e cliente OPC, o OPC
DataHub pode também conectar qualquer servidor ou cliente OPC a qualquer aplicação
27
computacional como Excel, Web Browser ou qualquer sistema de gerenciamento de Banco
de Dados. Através dessa ferramenta, permite-se também adquirir e tratar dados OPC em
ambiente Linux e QNX.
2.9 Basic4Android
O ambiente de desenvolvimento Basic4android, demonstrado na �gura 10, é considerada
uma ferramenta Rapid Application Development (RAD) para aplicações nativas Android
desenvolvida e comercializada por Anywhere Software Ltd. A linguagem de programação
utilizada é muito similar ao Visual Basic e Visual Basic.Net, porém é adaptada ao ambi-
ente nativo Android. É uma linguagem desenvolvida e voltada à orientação por objetos e
eventos.
O Basic4android inclui todos os recursos necessários para desenvolver aplicações do
mundo real para Android. Essas aplicações são compiladas e resultam em aplicativos
nativos sem outras dependências ou a necessidade de recursos extras serem executadas.
Além da ferramenta por si só, faz-se também necessário a instalação do Java JDK v7 e
Android SDK.
Figura 10 � Ambiente de programação Basic4Android
2.10 Google Cloud Messaging - GCM
O sistema de noti�cações utilizado na plataforma Android é chamadaGoogle Cloud Messa-
ging for Android (GCM). Esse sistema foi desenvolvido para substituir e eliminar algumas
desvantagens do sistema de noti�cações anterior, o Android Cloud to Device Messaging
28
(C2DM). O serviço de noti�cações GCM possibilita ao desenvolvedor de softwares enviar
dados de um servidor para aplicações em dispositivos Android móveis. O serviço pro-
porciona um mecanismo simples e leve que pode ser utilizado para contactar o servidor
diretamente para buscar dados de atualização ou mesmo dados de usuário. O serviço
GCM lida com todos os aspectos de comunicação manejando o en�leiramento de mensa-
gens e então as entrega às aplicações em execução no(s) dispositivo(s) Android alvo em
tempo oportuno.
Conforme descrito por (ZHAO; BOND; SWEATMAN, 2014), o modelo GCM é bas-
tante similar ao antigo modelo C2DM; ele contém três componentes principais: um servi-
dor de aplicações, um servidor GCM e um dispositivo Android. O servidor de aplicações,
que pode ser implementado na maioria das linguagens de programação, é desenvolvido
pelo usuário provedor da aplicação enquanto que o servidor GCM é disponibilizado pela
Google. Antes de qualquer tentativa de uso do serviço GCM, ambos aplicativo e disposi-
tivo móvel deverão estar registrados no servidor GCM.
Após o registro, quando novos dados estiverem disponíveis, o servidor de aplicações
envia a mensagem para o servidor GCM via HTTP POST. A mensagem enviada do
servidor de aplicações é uma mensagem leve que destina-se a informar ao aplicativo no
dispositivo móvel que novos dados estão disponíveis, mas sem requerer a transferência de
todos os dados para o aplicativo. Quando o servidor GCM recebe a mensagem, ele irá
imediatamente encaminha-la ao dispositivo móvel, se este estiver online. Caso contrário, a
mensagem será mantida no servidor GCM e enviada posteriormente ao dispositivo móvel
assim que este volte ao status online.
Assim que a mensagem é entregue com sucesso ao dispositivo móvel, o aplicativo
iniciará, processará a mensagem e buscará o novo dado do servidor dos provedores de
aplicações. Além disso, o aplicativo móvel deverá ser mantido em execução (foreground
ou background) a�m de receber mensagens via servidor GCM. Quando a aplicação não
estiver rodando, esta não será capaz de receber as mensagens do servidor.
Entre alguns benefícios listados por (FLORES; SRIRAMA, 2014) incluem: vida de
bateria estendida, a melhoria da capacidade de armazenamento e maior poder de pro-
cessamento, enriquecendo, assim, os aplicativos móveis, juntamente com a experiência do
usuário.
Características do serviço GCM:
• Permite que servidores rodando outras aplicações enviem mensagens leves para apli-
cações Android. O serviço de mensagem não é projetado para enviar grandes pacotes
29
de dados via mensagens, mas sim para comunicar à aplicação que há um novo dado
no servidor à disposição da aplicação para buscá-la;
• GCM não garante a entrega ou ordem de entrega das mensagens. Dessa forma,
por exemplo, enquanto pode-se usar esse recurso para contar uma aplicação de
mensagens instantâneas que o usuário tem novas mensagens, muito provavelmente
não se usaria desse serviço para passar as mensagens reais;
• Uma aplicação Android não precisa necessariamente estar em execução para rece-
ber as mensagens. O sistema vai acordar a aplicação via Intent Broadcast quando
a mensagem chegar, desde que a aplicação esteja con�gurada e com as devidas
permissões;
• Não fornece qualquer interface de utilizador ou outra manipulação de dados de
mensagens embutido. GCM simplesmente passa os dados da mensagem recebida
diretamente para o aplicativo, que tem o controle total de como lidar com isso.
Por exemplo, o aplicativo pode postar uma noti�cação, apresentar uma interface do
usuário personalizada, ou dados silenciosamente, etc;
(a) Arquitetura de O�oading
(b) Arquitetura de delegação de tarefas
Figura 11 � Tipos do serviço de push messageFonte: (FLORES; SRIRAMA, 2014)
3 Desenvolvimento e Métodos
3.1 Banco de Dados
Aplicações e tecnologias em sistemas relacionais por banco de dados têm um grandioso
impacto na crescente utilização de sistemas computacionais. É justo dizer que sistemas
de gerenciamento de Banco de Dados representam fatores críticos em quase todas apli-
cações onde computadores são usados, incluindo negócios e �nanças, comércio eletrônico,
engenharia, medicina, genética, direito e legislações, bibliotecas, entre outras. A palavra
Database, ou simplesmente o termo Banco de Dados é tão comumente utilizado que, sem
mais, deve-se primeiramente de�nir o que esse termo representa.
De acordo com (ELMASRI, 2008), um Banco de Dados (BD), numa visão ampla e
generalista, é uma coleção de dados correlacionados. Por dados entende-se fatos conhe-
cidos que podem ser armazenados e que têm signi�cado implícito. Por exemplo, pode-se
listar aqui o nome, número de telefone e endereço de um certo grupo de pessoas. Tais
dados podem ser armazenados em um disco rígido utilizando-se de um computador pro-
vido de softwares como Microsoft Access ou Excel. Esta coleção de dados com signi�cado
implícito é um banco de dados.
A seguir listam-se algumas características desejáveis em um Banco de Dados:
1. Controle de Redundância;
2. Compartilhamento de Dados;
3. Controle de Acesso aos Dados;
4. Múltiplas Interfaces;
5. Representação de Associações Complexas;
6. Garantia de Restrições de integridade;
7. Recuperação de Falhas
3.2 Sistema de Gerenciamento de Banco de Dados (SGBD)
Um Sistema de Gerenciamento de Banco de Dados, ou simplesmente SGBD descrito na
�gura 12, é uma coleção de programas que permite ao usuário criar e manter um BD.
31
Figura 12 � Ambiente de um Sistema de Banco de Dados simpli�cadoFonte: (ELMASRI, 2008)
Um SGBD é um sistema de softwares de propósito geral que facilita o processo de de�-
nição, construção, manipulação e compartilhamento de dados entre usuários e aplicações.
O processo de de�nição de um Banco de Dados envolve especi�cação de tipos de dados,
estruturas, restrições dos dados a serem armazenados pelo banco. A de�nição, ou infor-
mação descritiva do BD é também armazenada pelo SGBD na forma de um catálogo ou
dicionário, o que se chama de metadado (ELMASRI, 2008).
Construir um Banco de Dados é o processo de armazenar dados em algum meio de
armazenamento controlado pelo SGDB. Já o processo de manipulação consiste em utilizar-
se de funções tais como as queries para retornar dados especí�cos sobre o interesse do
usuário. Atualizar um DB é a operação que re�ete mudanças no ambiente que o BD
representa, enquanto que o processo de compartilhamento permite múltiplos usuários
acessar o BD simultaneamente.
Em linhas gerais, uma aplicação acessa um banco de dados enviando ou requisições
diretamente ao SGBD. Uma query tipicamente causa algum dado ser retornado ao usuário
32
que a envia, já uma transação pode causar a leitura ou a escrita de algum conjunto de
dados no banco de dados. Finalizando esta seção de de�nições iniciais, de�ne-se um
Sistema de Banco de Dados o conjunto composto pelo BD em si em conjunto com o
SGDB (ELMASRI, 2008).
3.3 SQLite
SQLite é uma biblioteca de software que implementa um motor de banco de dados tran-
sacional autônomo, sem servidor e sem necessidade de instalação ou con�gurações extras.
Além disso, apresenta suporte nativo no Android o que torna-lhe a escolha natural para
um ambiente em que se preze por desempenho, disponibilidade de memória e praticidade
de uso.
Todos os códigos e documentações sobre o SQLite tem sido dedicado ao domínio
público pelos autores, então qualquer usuário é livre para copiar, modi�car, publicar,
utilizar, compilar, vender ou distribuir o código original do SQLite, tanto em forma de
código fonte ou como um código binário compilado.
4 Programação Android
4.1 Desenvolvimento de um Aplicativo
Aplicativos Android são geralmente escritos em linguagem Java. No caso da IDE Ba-
sic4Android utilizada no desenvolvimento deste projeto, tal IDE inclui um compilador
tradutor de linguagem de Basic para Java. A ferramenta Andoid Software Development
Tool (SDK) compila o código juntamente com quaisquer outras dependências, dados ou
arquivos em recurso. O arquivo gerado é um Android Package (APK) que contém todo o
conteúdo de um aplicativo Android e é o arquivo que todos os dispositivos com Android
OS utilizam para a instalação. Uma vez instalado no dispositivo, cada aplicativo Android
reside em sua própria sandbox de segurança.
• O sistema operacional Android é um sistema Linux multiusuário em que cada apli-
cativo é um usuário diferente.
• Por padrão, o sistema atribui a cada aplicativo um ID de usuário Linux que é único
(a ID é atribuída e utilizada pelo sistema operacional apenas, portanto desconhecido
para o aplicativo). O sistema operacional então de�ne as permissões para todos os
arquivos em um aplicativo de modo que apenas o ID de usuário atribuído a esse
aplicativo pode acessá-los.
• Cada processo tem a sua própria Máquina Virtual (VM), de modo que o código de
um aplicativo é executado isoladamente de outros aplicativos.
• Por padrão, cada aplicativo é executado em seu próprio processo Linux. O Android
OS inicia o processo quando qualquer um dos componentes do aplicativo precisa
ser executado, em seguida, desliga o processo quando ele não é mais necessário ou
quando o sistema deve recuperar a memória para outros aplicativos.
Desta maneira, conforme escreve (ROGERS et al., 2009), o sistema Android imple-
menta o princípio do menor privilégio. Isto é, cada aplicativo, por padrão, tem acesso
somente aos componentes de que precisa para fazer seu trabalho e nada mais. Isso cria
um ambiente muito seguro em que um aplicativo não pode acessar partes do sistema ou
hardware para as quais não lhe é dada a permissão.
34
4.2 Componentes de um Aplicativo
Componentes de aplicativo são blocos de construção essenciais de um aplicativo Android.
Cada componente é um outro ponto através do qual o sistema pode acessar e entrar em
determinado aplicativo. Nem todos os componentes são pontos de entrada reais para
o usuário e alguns dependem um do outro, mas cada um existe como uma identidade
própria e desempenha um papel especí�co, cada um é um bloco de construção único que
ajuda de�nir o comportamento de modo geral de uma aplicação. Lista-se nas subseções
abaixo os quatro tipos de componentes de aplicativos:
4.2.1 Activity
Uma Activity, ou simplesmente Atividade, é um componente do aplicativo que fornece
uma tela com a qual o usuário pode interagir a �m de realizar alguma ação, como por
exemplo fazer uma ligação, tirar uma foto, trocar mensagens e e-mails, etc. A cada
atividade é associada uma janela na qual permite-se desenhar e projetar a interface com
o usuário. Esta janela tipicamente preenche toda a tela, mas pode também ser menor que
a tela do dispositivo ou �utuar sobre outras janelas.
Uma aplicação quase sempre consiste de múltiplas atividades que não intimamente
estão ligadas umas às outras. Normalmente uma atividade em um aplicativo é denominada
Atividade Principal, atividade esta que é apresentada ao usuário pela primeira vez que o
aplicativo é executado. A partir desse ponto, cada atividade pode iniciar outra atividade
a�m de executar ações especí�cas. A cada vez que uma atividade é iniciada, a atividade
anterior é colocada em pausa, mas o sistema operacional preserva uma pilha de atividades,
a back stack ou pilha de volta. Quando uma nova atividade é iniciada, ela é empurrada
na back stack a toma o foco do usuário. A back stack mantem o princípio básico de pilhas
- último a entrar, primeiro a sair − por isso quando o usuário atinge o seu propósito em
uma certa atividade e pressiona o botão voltar, esta atividade corrente é removida da
pilha e destruída. A atividade anterior, portanto, é retomada da back stack sem perda de
conteúdo.
4.2.2 Service
Service ou serviço é um componente de aplicação que pode executar operações de longa
execução em segundo plano não fornecendo nenhuma interface de usuário. Um outro
componente do aplicativo pode iniciar um serviço e ele continuará a ser executado mesmo
quando o usuário fechar ou alternar para outro aplicativo. Um serviço poed lidar com
transações de rede, tocar música, executar arquivos de I/O ou até interagir com um
provedor de conteúdo, tudo a partir do background.
35
Um serviço pode assumir, essencialmente, duas formas:
Started
Um serviço assume essa forma quando inicializado por um componente de aplicação
qualquer, como uma atividade por exemplo. Uma vez inicializado, um serviço pode
rodar no background inde�nitivamente, até mesmo quando o componente que o
inicializou é destruído. Geralmente o serviço inicializado executa e não retorna
nenhum resultado para o componente que o criou. Serviços do tipo started podem
fazer download/upload de um arquivo pela rede. Após a ação ser executada, o
serviço para por si mesmo, ou seja, se autodestrói.
Bound
Um serviço assume a forma bound quando um componente da aplicação liga-se a
ele, dessa forma o serviço sujeita-se ao componente da aplicação. Um serviço bound
oferece uma interface cliente-servidor que permite que componente interajam com
o serviço, enviem requisições, obtenham resultados e até mesmo o façam através de
processos de comunicação entre processos (IPC). Um serviço bound executa somente
enquanto um outro componente de aplicação permaneça ligado a ele. Múltiplos com-
ponentes podem-se ligara ao serviço de uma só vez, mas quando todos componentes
desligarem-se o serviço será destruído.
4.2.3 Content Provider
Content provider ou provedor de conteúdo é o elemento que gerencia o acesso a um con-
junto de dados estruturados. Dados podem ser compartilhados e armazenados no sistema
de arquivos, Banco de Dados SQLite, na internet ou em qualquer meio de armazenamento
consistente que o aplicativo permite acessar. Através do Content Provider, outros aplica-
tivos podem consultar ou até mesmo modi�car os dados, se o provedor de conteúdo assim
o permitir. Eles também encapsulam os dados e fornecem mecanismos para de�nição de
segurança desses dados. Os Content Providers são a interface padrão que conecta dados
em um processo com código em execução em outro processo.
4.2.4 Broadcast Receiver
Um Broadcast Receiver é um componente que responde aos anúncios de todo o sistema
de broadcast. Muitas broadcasts iniciam-se do sistema, por exemplo, uma broadcast indi-
cando que a tela foi deligada, bateria fraca ou uma foto foi capturada. Aplicativos também
podem iniciar broadcasts, por exemplo para permitir que outros aplicativos saibam que
alguns dados foram transferidos para o dispositivo e que, portanto, estão disponíveis para
36
utilização. Apesar de um Broadcast Receiver não exibir uma interface de usuário, ele
pode criar uma barra de noti�cação para alertar o usuário quando um evento de broad-
cast ocorrer. Mais comumente, no entanto, um Broadcast Receiver atua somente como
uma porta de entrada para outros componentes do aplicativo e destina-se a fazer uma
quantidade mínima de trabalho, por exemplo iniciando um serviço para executar algum
trabalho com base em um evento.
5 IMPLEMENTAÇÃO
5.1 Sobre o Aplicativo
A concepção e desenvolvimento deste aplicativo apresenta-se como um projeto em en-
genharia de manutenção idealizado pela equipe de Manutenção de Sistemas Industriais
(MASI) do parque industrial das Usinas Siderúrgicas de Minas Gerais - Usiminas em
Ipatinga/MG. Tal projeto visa monitorar, em tempo real, os equipamentos sob respon-
sabilidade da MASI nas áreas das laminações a quente e a frio. A ferramenta adotada
na bem sucedida implementação do projeto foi a utilização da plataforma Android para
dispositivos móveis assim como outras tecnologias que permitiram a comunicação entre
os instrumentos em campo com os sistemas supervisórios da empresa até, �nalmente,
dispositivos móveis (smartphones) da equipe de manutenção. A implementação e pos-
terior aplicação do projeto resultou primariamente em benefícios imediatos à equipe de
manutenção técnica, dentre tais benefícios destacam-se: manutenção assertiva, pronta
identi�cação da causa da falha, permitirá antecipação da manutenção corretiva, a predi-
ção de falhas (manutenção preditiva), entre outras.
O projeto, devido a sua grande extensão, além de demais restrições �sicas e de acesso
impostas pela empresa e/ou sua infra-estrutura, foi separado em 2 escopos. Considerando
tal separação, as atividades transcorreram de modo que o aluno foi responsável pelo
desenvolvimento da aplicação para os dispositivos móveis Android enquanto um analista
de automação, designado pela Usiminas, foi incumbido da implementação dos sistemas
de aquisição e tratamento de sinais do campo e disponibilização na nuvem para posterior
utilização do aplicativo nos smartphones.
5.2 Diagramas ER
Entity Relationship Diagram (ERD), ou simplesmente diagrama ER é uma representação
visual de diferentes tipos de dados utilizando-se de convenções que descrevem como esses
dados estão relacionados uns com os outros. Enquanto capaz de descrever praticamente
qualquer sistema, diagramas ER são mais frequentemente associados com banco de dados
complexos que são utilizados em engenharia de software e redes de TI. Em particular,
diagramas ER são frequentemente usados no estágio de concepção de um processo de
desenvolvimento, a �m de identi�car os diferentes elementos do sistema e suas relações
uns com os outros (ELMASRI, 2008).
38
Há três elementos básicos em um diagrama ER, quais sejam: entidade, atributo e
relacionamento. Existem mais elementos que são baseados nos três principais já menci-
onados, sendo entidade fraca, atributo multivalorado, atributo derivado, relacionamento
fraco e relacionamento recursivo.
Entidade: pode ser uma pessoa, lugar, evento ou objeto que é relevante para um dado
sistema. Entidades em um diagrama ER é representado por um retangulo e são
rotulados por substantivos simples.
Entidade fraca: é uma entidade que depende da existência de outra entidade. Em ter-
mos mais técnicos, pode ser dee�nida como uma entidade que não pode ser identi�-
cada por seus próprios atributos. Ela utiliza-se de uma chave estrangeira combinada
com seus próprios atributos para formar uma chave primária. Uma entidade fraca,
no diagrama ER, é representada por um retângulo duplo.
Atributo: é uma propriedade, peculiaridade, traço ou característica de uma entidade,
relacionamento ou outro atributo. Uma entidade pode ter quantos atributos quan-
tos forem necessários. Enquanto isso, os atributos também podem ter seus proprios
atributos especí�cos, por exemplo, um atributo endereço poderá apresentar atribu-
tos número, rua e estado. Atributos em um diagrama ER são representados por
formas ovais, sendo os atributos de rótulo sublinhado representante ou pertencente
à chave primária daquela entidade.
Atributo multivalorado: se um atributo pode apresentar mais de um valor, este será
denomidado atributo multivalorado. É importante notar que este tipo de atributo
difere de um atributo que apresenta outros atributos. Um atributo multivalorado é
representado no diagrama ER por dupla forma oval.
Atributo derivado: é um atributo baseado em outro atributo. É muito raramente en-
contrado em diagramas ER. Por exemplo, a idade de uma pessoa poderá ser derivada
de sua data de nascimento. Atributos derivados sõ representados por uma forma
oval com linhas tracejadas.
Relacionamento: descreve como as entidades se relacionam. Por exemplo, a entidade
�pedreiro� pode estar relacionada à entidade �casa� pelo relacionamento �constroi�.
Relacionamentos são representados por losangos e são rotulados usando verbos.
Relacionamento recursivo: se a mesma entidade participa mais de uma vez em um
relacionamento, este é denominado um relacinamento recursivo. Por exemplo, um
funcionário pode ser um supervisor e também ser supervisionado por outro empre-
gado, caracterizando-se assim um relacionamento recursivo.
39
A seguir apresentam-se os diagramas ER das tabelas presente no Banco de Dados da
aplicação descrevendo como essas tabelas relacionam entre si.
Figura 13 � Relações entre eventos e suas descrições
Na �gura 13 pode-se observar o relacionamento entre as tabelas na aplicação que
estão intimamente associandas à eventos. Dessa forma, a tabela ALMCOD através de
sua chave primária relaciona e descreve de forma literal todos os códigos de alarmes e
warnings presentes em ALARMES e WARNINGS. O relacionamento entre estas tabelas
também é de um para muitos, onde uma tupla em ALMCOD pode estar associada a �n�
tuplas em ALARMES e/ou WARNINGS.
Figura 14 � Relacionamento entre setups de laminação e seus detalhamentos
Na �gura 14 pode-se observar o relacionamento entre as tabelas PLACAINFO e PDI.
O relacionamento entre essas tabelas é o de detalhamento onde, para cada placa lami-
nada presente em PDI estão associadas �n� tuplas em PLACAINFO que contém todas as
informações sobre o que aconteceu em cada passe de laminação.
Na �gura 19b observa-se o relacionamento entre a tabela EQUIPAMENTOS e as
demais tabelas presente no BD. O relacionamento entre elas é de descrição, onde a tabela
40
EQUIPAMENTOS, através de sua chave primária Equip_Cod descreve com um nome
literal todas as ocorrências de equipamentos nas outras tabelas através de um código de
equipamento presente nas outras tabelas. Observe também que para uma única ocorrência
em EQUIPAMENTOS pode-se admitir �n� ocorrências nas outras tabelas, ou seja, a tabela
EQUIPAMENTOS possui um relacionamento de um para muitos com as demais tabelas
da aplicação.
Figura 15 � Relações entre equipamentos e suas descrições nas demais entidades
5.3 Relações/Tabelas no Banco de Dados da aplicação
Tabela 1 � EQUIPAMENTOS
Equip_Cod(*) Area Nome
INTEGER INTEGER TEXT
A relação EQUIPAMENTOS contém todo e qualquer equipamento que será cadas-
trado na aplicação por um usuário especí�co em sem smartphone particular. Esta relação
apresenta três atributos, quais sejam Equip_Cod, Area e Nome. Equip_Cod do tipo in-
teiro e que se refere ao código do equipamento em questão. O atributo Area do tipo texto,
ou (VARCHAR[50]) se refere à área em que o equipamento se situa na planta. No caso
da Usiminas, a descrição da área é composta com letras e algarismos, daí a determinação
pelo tipo texto para esse atributo. O último atributo Nome refere-se à descrição literal
do equipamento a ser cadastrado. O atributo Equip_Cod representa uma chave primária
41
nesta relação, tendo em vista que dois ou mais equipamentos não podem ser descritos por
um mesmo código.
Query de criação da relação EQUIPAMENTOS:
CREATE TABLE EQUIPAMENTOS (Equip_Cod INTEGER, Area TEXT, Nome TEXT,
PRIMARY KEY (Equip_Cod))
Tabela 2 � ALMCOD
Cod(*) Descricao EquipCode(*)
INTEGER TEXT INTEGER
A relação ALMCOD contém os códigos e descrições de alarmes para cada equipamento
cadastrado na aplicação. Esta relação também apresenta três atributos, quais sejam: Cod,
Descricao e EquipCode. O atributo Cod do tipo inteiro relaciona os possíveis códigos de
eventos para cada equipamento, o atributo Descricao do tipo texto (VARCHAR[50]) que
vem a seguir é onde registra-se a descrição de cada evento. Por último EquipCode, do
tipo inteiro, de�ne a que equipamento cada código de evento pertence. Os atributos Cod
e EquipCode, conjuntamente, de�nem a chave primária dessa relação. Isto representa que
cada equipamento poderá apresentar apenas uma descrição para cada código de evento.
Query de criação da relação ALMCOD:
CREATE TABLE ALMCOD (Cod INTEGER, Descricao TEXT, EquipCode INTEGER,
PRIMARY KEY (Cod, EquipCode))
Tabela 3 � ALARMES
CodAlarme NumPlaca Area Equip DataHora_Evento Passe
INTEGER INTEGER TEXT INTEGER DATETIME INTEGER
Tabela 4 � WARNINGS
CodWarn NumPlaca Area Equip DataHora_Evento Passe
INTEGER INTEGER TEXT INTEGER DATETIME INTEGER
As relações ALARMES e WARNINGS podem ser analisadas conjuntamente pelo grau
de semelhança e aplicabilidade no projeto. Os atributos CodAlarme e CodWarn, do tipo
inteiro, de�nem os códigos para os eventos de alarme e advertência para cada equipa-
mento. O atributo NumPlaca, do tipo inteiro, de�ne o número de série da placa sendo
laminada no momento em que o evento CodAlarme/CodWarn acontece. Os atributos que
se seguem: Area, Equip e DataHora_Evento de�nem a área de locação do equipamento,
seu código e por �m data e hora em que o evento acontece precisamente. O atributo Passe
42
de�ne em que passe de laminação da placa o evento foi de�agrado.
Queries de criação das relações ALARMES e WARNINGS:
CREATE TABLE ALARMES (CodAlarme INTEGER, NumPlaca INTEGER, Area TEXT,
Equip INTEGER, DataHora_Evento DATETIME, Passe INTEGER, FOREIGN KEY
(Equip, CodAlarme) REFERENCES ALM_CODE (Equip_Code, Cod))
CREATE TABLEWARNINGS (CodWarn INTEGER, NumPlaca INTEGER, Area TEXT,
Equip INTEGER, DataHora_Evento DATETIME, Passe INTEGER, FOREIGN KEY
(Equip, CodWarn) REFERENCES ALM_CODE (Equip_Code, Cod))
Os atributos Equip e CodAlarme/CodWarn representam, conjuntamente, a chave es-
trangeira no relacionamento entre as relações ALARMES/WARNINGS e ALMCOD. O
relacionamento é obtido ao relacionar-se os atributos Equip e CodAlarme/CodWarn de
ALARMES e WARNINGS aos atributos Equip_Code e Cod de ALMCOD.
Tabela 5 � PDI
NumPlaca(*) Area Equip DataHora_Setup EspFinal CodMat PosBorda
INTEGER TEXT INTEGER DATETIME DOUBLE INTEGER INTEGER
A relação PDI descreve todas as placas laminadas listando as características inerentes
a cada uma. Esta relação lista individualmente os dados de cada placa laminada espe-
ci�cando o início do processo de laminação, o código da liga que a compõe, locação na
planta além da posição do carro de borda responsável pelas medições de espessura de
centro e bordas das placas. O atributo EspFinal, do tipo double, especi�ca qual será a
espessura atingida no último passe de laminação da placa, CodMat representa o código da
liga metálica do corpo laminado e PosBorda a posição do carro do medidor de espessuras
em relação ao centro da linha do laminador. Os demais atributos já foram discutidos nos
itens acima. O atributo NumPlaca constitui chave primária desta relação devido ao fato
de que nenhuma placa será laminada mais de uma vez ou terá mais de uma conformação
�nal.
Query de criação da relação PDI:
CREATE TABLE PDI (NumPlaca INTEGER, Area TEXT, Equip INTEGER, DataHora_Setup
DATETIME, EspFinal DOUBLE, CodMat INTEGER, PosBorda INTEGER, PRIMARY
KEY (NumPlaca))
A relação PLACAINFO é de extrema importância para a aplicação, dado que descreve
detalhadamente importantes variáveis de processo para cada passe no trem do lamina-
43
Tabela 6 � PLACAINFO
NumPlaca(*) EspSetup Largura Passe Temperatura
INTEGER DOUBLE INTEGER INTEGER INTEGER
dor. O atributo EspSetup, do tipo double, detalha a espessura da placa em cada passe
e que deverá no �nal do processo convergir para a espessura �nal da placa especi�cada
no setup inicial presente na relação PDI. O atributo Largura, por sua vez, descreve o
comportamento dessa grandeza ao longo do processo que deverá conter alguns passes de
alargamento e depois manter a largura da placa laminada em um valor �xo. O atributo
NumPlaca de PLACAINFO consiste nesta relação uma chave estrangeira que referencia
à NumPlaca de PDI.
Query de criação de PLACAINFO:
CREATE TABLE PLACAINFO (NumPlaca INTEGER, EspSetup DOUBLE, Largura
INTEGER, Passe INTEGER, Temperatura INTEGER, FOREIGN KEY (NumPlaca)
REFERENCES PDI (NumPlaca))
5.4 Descrição do aplicativo
5.4.1 Primeiro acesso
(a) Aplicativo Bloqueado (b) Seção para registro GCM
Figura 16 � Primeiro acesso de usuário
44
Após a instalação, em seu primeiro acesso ao aplicativo, o usuário ainda não é garantido
acesso às funcionalidades do software, dado que os servidores GCM da Google ainda não
assinalaram a este usuário uma identi�cação única para comunicação e recebimento de
dados. Neste ponto o usuário tem apenas o aplicativo instalado em seu dispositivo, mas
não consegue utiliza-lo. Neste modo, conforme descrito pela �gura 16a, o aplicativo �ca
bloqueado e os menus de navegação não têm nenhuma funcionalidade até que o cadastro
seja efetuado com sucesso em uma seção própria no aplicativo para registro GCM, como
mostrado em 16b.
5.4.2 Menu principal e data logger
(a) Menu Principal (b) Setup de data logger
Figura 17 � Menu principal e preferências para data logger
Após se cadastrar, o usuário torna-se disponível para o recebimento de mensagens
e informações acerca de todos os equipamentos sob responsabilidade da MASI. Além
disso, o aplicativo é desbloqueado e o usuário pode navegar pelos menus e iniciar a sua
interação com a ferramenta, vide �gura 17a. Ainda no menu principal, o usuário tem a
opção de setar por quanto tempo, em horas, o aplicativo manterá dados de histórico de
eventos recentes, ou seja, o usuário tem a opção de con�gurar por quanto tempo os dados
relativos a eventos �carão disponíveis na aplicação. O valor default do aplicativo é de 24h.
O aplicativo inclui um serviço agendado que é executado a cada 12h e remove do banco
de dados quaisquer tuplas mais antigas que o valor setado na atividade de preferências de
data logger, �gura 17b.
45
5.4.3 Cadastro de novos equipamentos
(a) Lista de cadastro (b) Cadastrar equipamento (c) Remover equipamento
Figura 18 � Gestão de equipamentos de interesse
Nesta seção do aplicativo, o usuário pode gerenciar os seus equipamentos de interesse
que estão dispostos em uma lista apresentada na �gura 18a. Para cadastro, basta inserir
a TAG ou código do equipamento, o código da área a que pertence e um nome literal
descritivo para o equipamento que está sendo inserido, �gura 18b. Logo após o cadastro,
o aplicativo estará apto a fornecer uma série de dados a respeito do equipamento recém
cadastrado. O usuário também pode remover qualquer equipamento presente na lista de
cadastro, bastando um longo clique sobre o nome do equipamento a ser removido e uma
mensagem de con�rmação aparecerá, vide �gura 18c. O aplicativo não permite que se
remova o equipamento que esteja selecionado como equipamento de interesse atual.
5.4.4 Menu secundário
Este é um menu secundário que pode ser acessado do menu principal. Este menu permite
avaliar diversos dados de um determinado equipamento ou instrumento com mais deta-
lhes. Tais funcionalidades incluem histórico de falhas, con�guração de noti�cação e alerta
áudio-sensorial em caso de falhas sinalisadas como importantes pelo usuário, visualização
de eventos (Alarmes/Advertências) etc. Permite-se também que mostre grá�ca e quali-
tativamente o per�l de variáveis importantes no processo de laminação de cada slab de
acordo com seu setup particular de laminação. Também no menu secundário o usuário
tem a opção de selecionar seu equipamento de interesse presente na lista de equipamentos
cadastrados, �gura 19b. Os dados apresentados em todas as seções do aplicativo são fun-
46
ções do equipamento selecionado como de interesse, portanto variam caso o equipamento
de interesse mude. O menu secundário é mostrado na �gura 19a.
(a) Menu secundário (b) Lista de equipamentos
Figura 19 � Menu secundário e lista de equipamentos de interesse
5.4.5 Noti�cações e alerta áudio sensorial
(a) Lista de eventos (b) Noti�cação contraída (c) Noti�cação expandida
Figura 20 � Sistema de noti�cações do aplicativo
47
Como já antecipado neste trabalho, o aplicativo permite que o usuário escolha entre
a lista de eventos de cada equipamento (alarmes/warnings) aqueles eventos que sejam
críticos ou de seu maior interesse. Desta maneira, o aplicativo através do menu secundário
garante ao usuário acesso à lista de eventos de cada equipamento individualmente dentre
os quais o usuário seta qual(is) evento(s) deseja acompanhar mais cuidadosamente, vide
�gura 20a. Tendo o usuário setado pelo menos um dos eventos listados, a cada ocorrência
de tal falha o aplicativo lançará uma noti�cação juntamente com um alerta áudio sensorial
alertando o usuário, dessa maneira, para a ocorrência de tal evento. Na �gura 20b pode-
se ver o lançamento da noti�cação pelo Android. Para obter mais informações sobre a
noti�cação recebida o usuário ainda pode interagir com a noti�cação na homescreen de
seu dispositivo e expandir a noti�cação, conforme demonstrado em 20c.
5.4.6 PDI's de laminação
(a) PDI de laminação A (b) PDI de laminação B
Figura 21 � Setups de laminação para duas placas A e B distintas
O aplicativo também provê informações em detalhes sobre todos os passes de laminação
para cada placa laminada. Estas informações incluem a identi�cação de cada placa, a
espessura, largura e temperatura em cada passe, o código do material de composição da
placa, bem como o número total de passes efetuados. As �guras 21a e 21b descrevem
os setups de laminação para duas placas distintas quaisquer. Observe como as placas
apresentam per�s de temperatura, largura e espessura diferentes, como são compostas
por materiais diferentes, como apresentam espessuras �nais distintas e são laminadas até
seus estados �nais em diferentes números de passes no laminador.
48
5.4.7 Ranking de falhas
(a) Ranking de falhas - Barra (b) Ranking de falhas - Donut
Figura 22 � Top 5 falhas registradas por equipamento
Para todos os equipamentos cadastrados no aplicativo, o usuário tem a opção de
conferir quais são as falhas mais recorrentes. Para tal, o aplicativo contabiliza todas as
falhas registradas para determinado equipamento e as organiza de forma decrescente em
um ranking de até cinco posições. Como pode ser visualisado na �gura 22, os dados
podem ser apresentados em um grá�co tipo barras, 22a, ou em um grá�co tipo donut,
22b.
5.4.8 Registro de eventos
Todos os eventos registrados são organizados por equipamento e classi�cados entre Alar-
mes e Warnings. O aplicativo apresentará esses dados desde que estes não sejam mais
antigos que o valor con�gurado pela usuário na seção data logger no menu principal. Caso
haja algum registro para o equipamento selecionado, o aplicativo os listará conforme �-
gura 23a. Caso o equipamento selecionado ainda não tenha nehum evento registrado,
uma pequena mensagem informa ao usuário que nenhum evento foi contabilizado, como
em 23b.
Ainda no menu principal, o aplicativo permite ao usuário veri�car quais equipamentos
apresentaram mais falhas em um histórico recente. Para esta funcionalidade, o software
contabiliza todos os registros de falhas recebidas somando-as e depois organiza essas in-
formações em ordem decrescente permitindo a análise e identi�cação dos equipamentos
49
mais faltosos. Como pode ser observado, o usuário ainda pode interagir com a aplicação
e modi�car a forma do grá�co em barras na �gura 24a e pizza na �gura 24b.
(a) Registros de alarmes (b) Registros de warnings
Figura 23 � Registros de falhas por equipamento
(a) Ranking - Barra (b) Ranking - Pizza
Figura 24 � Registros de falhas por equipamento
6 CONCLUSÕES
O projeto, inicialmente idealizado pela equipe de manutenção de sistemas industriais da
Usiminas, depois de implementado, constitui-se como fundamental ferramenta para a En-
genharia de Manutenção. A implementação permitirá que intervenções nos equipamentos
sendo monitorados possam ser programadas preventivamente no sentido de diminuir ou
eliminar faltas graves que acarretariam em paradas extensas de produção. A ferramenta
também permitirá que, no caso em que alguma falha aconteça, tal falha seja identi�cada
de forma instantânea possibilitanto atividades corretivas mais direcionadas e de forma
direta. Tal característica também constitui importante recurso na identi�cação de causas
raíz para falhas recorrentes.
Além das características acima listadas, a aplicativo provê ferramentas grá�cas que
indicam quais falhas são mais recorrentes, além de registros dos eventos de alarmes e
advertências em um histórico recente. Tais funcionalidades constituem importante recur-
sos na identi�cação de tendências, programação de atividades de inspeção e manutenções
preditivas.
O aplicativo mostra-se robusto em seu funcionamento mesmo diante de um recebi-
mento massivo de dados diariamente. Isso se deve ao fato de a aplicação contar com um
serviço agendado para executar a cada 12 horas que retira do banco de dados todas as
tuplas mais antigas que o range de interesse do usuário, conforme descrito com detalhes na
sessão 5.4.2 deste trabalho. O tempo de vida dos dados na aplicação pode ser con�gurado
na atividade de preferências de data logger dentro do menu principal. Tal serviço permite
que a aplicação rode por tempo indeterminado sem esgotar o recurso de armazenamento
de dados com informações muito antigas e já sem interesse ou signi�cância para o usuário.
Neste momento, o aplicativo encontra-se em fase de testes e validação na planta da
Usiminas em Ipatinga e caminha para um emprego efetivo na empresa. Futuras melhorias
e expansões para outras áreas estão sendo estudadas devido a sua grande importância no
processo de gerenciamento de manutenção em sistemas industriais.
REFERÊNCIAS
ABAL. Laminação. 2009. Disponível em: <http://www.abal.org.br/aluminio/processos-de-producao/laminacao/>. Acessado: Nov 4, 2014.
CHEN, M.-C.; CHEN, J.-L.; CHANG, T.-W. Android/osgi-based vehicular networkmanagement system. Computer Communications, Elsevier, v. 34, n. 2, p. 169�183,2011.
DATAHUB, O. What is OPC. 2014. Disponível em: <http://www.opcdatahub.com/WhatIsOPC.html>. Acessado: Nov 4, 2014.
ELMASRI, R. Fundamentals of database systems. [S.l.]: Pearson Education India,2008.
FLORES, H.; SRIRAMA, S. N. Mobile cloud middleware. Journal of Systems andSoftware, Elsevier, v. 92, p. 82�94, 2014.
FOUNDATION, O. What's OPC? 2014. Disponível em: <https://opcfoundation.org/about/what-is-opc/>. Acessado: Nov 4, 2014.
GANDHEWAR, N.; SHEIKH, R. Google android: An emerging software platform formobile devices. International Journal on Computer Science and Engineering,Prentice-Hall, v. 1, n. 1, p. 12�17, 2010.
GOUVÊA, M. R. de et al. Aplicação de inteligência computacional na determinação daforça de laminação. 2009.
HELMAN, H.; CETLIN, P. R. Fundamentos da conformação mecânica dosmetais. [S.l.]: Universidade Federal de Minas Gerais, Escola de Engenharia, FundaçãoChristiano Ottoni, 1993.
INSTRUMENTS, N. Introduction to OPC. 2014. Disponível em: <http://www.ni.com/white-paper/7451/en/>. Acessado: Nov 4, 2014.
KRISTIAN, Y.; ARMANTO, H.; FRANS, M. Utilizing gps and sms for tracking andsecurity lock application on android based phone. Procedia-Social and BehavioralSciences, Elsevier, v. 57, p. 299�305, 2012.
MAIA, C.; NOGUEIRA, L. M.; PINHO, L. M. Evaluating android os for embeddedreal-time systems. IPP Hurray! Research Group, 2010.
MONTOYA, F. G. et al. A monitoring system for intensive agriculture based on meshnetworks and the android system. Computers and Electronics in Agriculture,Elsevier, v. 99, p. 14�20, 2013.
NTANTOGIAN, C. et al. Evaluating the privacy of android mobile applications underforensic analysis. Computers & Security, Elsevier, v. 42, p. 66�76, 2014.
52
PAYET, É.; SPOTO, F. Static analysis of android programs. Information andSoftware Technology, Elsevier, v. 54, n. 11, p. 1192�1201, 2012.
ROGERS, R. et al. Android application development: Programming with theGoogle SDK. [S.l.]: O'Reilly Media, Inc., 2009.
�AHIN, C.; BOLAT, E. D. Development of remote control and monitoring of web-baseddistributed opc system. Computer Standards & Interfaces, Elsevier, v. 31, n. 5, p.984�993, 2009.
TOSHIBA. Cesium gamma-ray thickness measuring device - instruction & operationmanual. 1990.
WANG, Y.; QI, C.; PAN, H. Design of remote monitoring system for aquaculture cagesbased on 3g networks and arm-android embedded system. Procedia Engineering,Elsevier, v. 29, p. 79�83, 2012.
WIDHIASI, A. et al. A feasibility study scheme of an android-based integrated wearableecg monitoring system. Procedia Computer Science, Elsevier, v. 21, p. 407�414,2013.
ZAMARREÑO, J. M. et al. A new plug-in for the creation of opc servers based onecosimpro c© simulation software. Simulation Modelling Practice and Theory,Elsevier, v. 40, p. 86�94, 2014.
ZHAO, Y.; BOND, I.; SWEATMAN, W. An android application for receivingnoti�cations of astrophysical transient events. Astronomy and Computing, Elsevier,2014.
ZIPF, M. E. Radiation transmission-based thickness measurement systems-theory andapplications to �at rolled strip products. 2010.
