Sistema de manutenção preditiva para equipamentos industriais utilizando redes BLE e Wi-Fi com aprendizado de máquina

INSTITUTO FEDERAL DE SANTA CATARINA
VITOR MANOEL DA SILVEIRA
SISTEMA DE MANUTENÇÃO PREDITIVA

UTILIZANDO REDES BLE E WI-FI COM
APRENDIZADO DE MÁQUINA
São José - SC
Julho/2019
SISTEMA DE MANUTENÇÃO PREDITIVA UTILIZANDO REDES
BLE E WI-FI COM APRENDIZADO DE MÁQUINA
Trabalho de conclusão de curso apresentado à

Coordenadoria do Curso de Engenharia de Tele-
comunicações do campus São José do Instituto
Federal de Santa Catarina para a obtenção do
diploma de Engenheiro de Telecomunicações.
Orientador: Mario de Noronha Neto
São José - SC
Julho/2019
Vitor Manoel da Silveira
SISTEMA DE MANUTENÇÃO PREDITIVA UTILIZANDO REDES BLE E WI-FI COM
APRENDIZADO DE MÁQUINA/ Vitor Manoel da Silveira. – São José - SC, Julho/2019-
62 p. : il. (algumas color.) ; 30 cm.
Orientador: Mario de Noronha Neto
Monografia (Graduação) – Instituto Federal de Santa Catarina – IFSC

Campus São José
Engenharia de Telecomunicações, Julho/2019.
Palavras-chave: Condition-based maintenance. Aprendizado de máquina. Predição de falhas.
Bluetooth low energy.
1. Condition-based maintenance. 2. Aprendizado de máquina. 3. Predição de falhas. 4.
Bluetooth low energy I. Orientador. II. Instituto Federal de Santa Catarina. III. Campus São
José. IV. Sistema de manutenção preditiva utilizando redes BLE e Wi-Fi com aprendizado de
máquina.
VITOR MANOEL DA SILVEIRA
SISTEMA DE MANUTENÇÃO PREDITIVA UTILIZANDO REDES

BLE E WI-FI COM APRENDIZADO DE MÁQUINA
Este trabalho foi julgado adequado para obtenção do título de Engenheiro de Telecomunicações,
pelo Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina, e aprovado na sua
forma final pela comissão avaliadora abaixo indicada.
São José - SC, 09 de julho de 2019:
Mario de Noronha Neto, Dr.

Orientador
Instituto Federal de Santa Catarina
Valdir Noll, Dr.

Coorientador
Roberto de Matos, Dr.

Roberto Dias, Dr.

AGRADECIMENTOS
A minha mãe, por todos os conselhos, paciência, atenção e por sempre estar ao meu lado
dando todo o apoio necessário.
A minha namorada, Marina Souza, por todo o apoio e determinação em não me deixar
desistir. Muito obrigado!
Às amizades que construí ao longo do curso.
Aos professores do IFSC-SJ que, desde o curso técnico integrado em telecomunicações,

disseminaram seus conhecimentos e me fizeram evoluir tanto pessoal quanto intelectualmente. Em
especial ao meu orientador Mario de Noronha Neto, por todos os seus conselhos e sua dedicação
em me auxiliar durante o desenvolvimento deste trabalho.
E a Intelbras, empresa onde trabalho e que me proporcionou todo o suporte e flexibilidade

no decorrer do curso.
“Não importa quanto a vida possa ser ruim, sempre existe algo que você pode fazer, e triunfar.
Enquanto há vida, há esperança.”
(Stephen Hawking)
RESUMO
Um dos principais problemas encontrados nas grandes indústrias são os defeitos apresentados em
equipamentos cujo valor monetário é significativamente alto, resultando em grandes custos por
interrupção na produção e reposição de peças. Para evitar tal situação e ter certa previsibilidade
de quando os problemas ocorrerão, cada vez mais empresas estão procurando integrar seus
equipamentos às redes Internet of things (IoT) devido aos diversos benefícios que esta traz
quando aliada à técnicas de aprendizado de máquina e Condition-based maintenance (CBM).
Neste documento consta uma introdução sobre o tema e a fundamentação teórica para sustentar
a proposta de implementar um sistema que colete informações do motor elétrico de equipamentos
industriais e, com base nisto, gere um alerta para que a manutenção seja efetuada previamente,
evitando danos aos equipamentos, paradas desnecessárias na produção e aumentando a vida útil
das máquinas. No desenvolvimento do endpoint foram utilizados a plataforma Arduino Nano e
os módulos Bluetooth low energy (BLE) AT-09 e MPU-6050, que conta com um acelerômetro
e um sensor de temperatura, enquanto o papel do gateway foi desempenhado pela plataforma
ESP-32. Utilizou-se o algoritmo K-means para a predição de falhas no motor e obteve-se um
resultado satisfatório com relação a precisão da classificação das amostras coletadas.
Palavras-chave: Condition-based maintenance. Aprendizado de máquina. Predição de falhas.

Bluetooth low energy.
ABSTRACT
One of the main problems encountered in large industries is the defects presented in equipment
whose monetary value is significantly high, resulting in large costs due to the interruption in the
production and replacement of parts. To avoid this and to be predictable when problems occur,
more and more companies are looking to integrate their equipment into IoT networks because
of the many benefits that brings when combined with machine learning and CBM techniques.
This document presents an introduction on the subject and the theoretical basis to support the
proposal to implement a system that collects information from the electric motor of industrial
equipment and, based on this, generates an alert so that the maintenance is carried out previously,
avoiding damages to the equipment, unnecessary downtime in production and increased machine
life. In the development of the endpoint we used the Arduino Nano platform and the modules
BLE AT-09 and MPU-6050, which has an accelerometer and a temperature sensor, while the
role of gateway was played by the platform ESP-32. The K-means algorithm was used to predict
motor failures and a satisfactory result was obtained in relation to the classification accuracy of
the collected samples.
Keywords: Condition-based maintenance. Machine learning. Fault predictiont. Bluetooth low

energy.
LISTA DE ILUSTRAÇÕES
Figura 1 – Procedimento para a abordagem da CBM . . . . . . . . . . . . . . . . . . . . 28

Figura 2 – Canais de comunicação utilizados pelo BLE. Os canais 37, 38 e 39 são os de
anúncio, sendo que os demais são utilizados para a transferência de dados . . 31
Figura 3 – Pilha de protocolos da tecnologia BLE. . . . . . . . . . . . . . . . . . . . . . 32
Figura 4 – Exemplo de funcionamento do algoritmo K-means. . . . . . . . . . . . . . . . 36
Figura 5 – Diagrama do sistema proposto . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 6 – Componentes do endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 7 – Representação do circuito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 8 – Fluxograma do funcionamento do endpoint . . . . . . . . . . . . . . . . . . . 39
Figura 9 – Montagem do endpoint em uma protoboard . . . . . . . . . . . . . . . . . . . 40
Figura 10 – Módulo de desenvolvimento ESP32 . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 11 – Diagrama Extended Entity-Relationship (EER) do banco de dados . . . . . . 42
Figura 12 – Cenário de coletas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 13 – Eixo X da aceleração em função do tempo . . . . . . . . . . . . . . . . . . . . 49
Figura 14 – Eixo Y da aceleração em função do tempo . . . . . . . . . . . . . . . . . . . . 50
Figura 15 – Eixo Z da aceleração em função do tempo . . . . . . . . . . . . . . . . . . . . 51
Figura 16 – Dispersão entre os valores pico a pico e Root Mean Square (RMS) . . . . . . 52
Figura 17 – Temperatura do motor em função do tempo . . . . . . . . . . . . . . . . . . . 53
Figura 18 – Clusterização dos dados através do algoritmo K-means . . . . . . . . . . . . . 54
Figura 19 – Capturas de tela dos gráficos de dispersão no aplicativo . . . . . . . . . . . . 55
Figura 20 – Capturas de tela dos gráficos dos valores pico a pico e temperatura em função
do tempo no aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 21 – Captura de tela da central de notificações exibindo o alerta de temperatura . 57
Figura 22 – Captura de tela da central de notificações exibindo o alerta de detecção de
comportamento anômalo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
LISTA DE TABELAS
Tabela 1 – Precisão da predição do K-means por eixo . . . . . . . . . . . . . . . . . . . . 54

LISTA DE ABREVIATURAS E SIGLAS
AFH Adaptative frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ATT Attribute Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
AWS Amazon web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
BLE Bluetooth low energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CBM Condition-based maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
CRC Cyclic redundancy code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
FFT Fast Fourier transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
FHSS Frequency-hopping spread spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
GAP Generic Access Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
GATT Generic Attribute Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
GFSK Gaussian frequency shift keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
HCI Host Controller Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IoT Internet of things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
L2CAP Logical Link Control and Adaptation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
LL Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
LPWAN Low power wide area network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
LTE Long term evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
M2M Machine-to-machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
NFC Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
PDU Protocol data unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
PHY Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
SIG Special Interest Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
SMP Security Manager Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
UUID Universally Unique Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
I2C Inter-Integrated Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
RMS Root Mean Square . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
JSON JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
MAC Media Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
URL Uniform Resource Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
HTTP HyperText Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
URI Uniform Resource Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
EER Extended Entity-Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ID Identificador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
FCM Firebase Cloud Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
REST Representation State Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
IDE Integrated Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
RX Receptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
TX Transmissor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
CSV Comma-separated values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 Condition-based maintenance (CBM) . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Internet of things (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Bluetooth low energy (BLE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Parâmetros da tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 Pilha de protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Aprendizado de máquina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.1 K-means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1 Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.1 Montagem do hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.1 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.3 Implementação do algoritmo K-means . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Aplicativo mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1 Testes de clusterização utilizando o algoritmo K-means . . . . . . . . . . . 53
4.2 Exibição dos resultados no aplicativo mobile . . . . . . . . . . . . . . . . . . 55
5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
23
1 INTRODUÇÃO
O mercado está cada vez mais competitivo, o que resulta em uma busca contínua por
parte das industrias em melhorar seu processo produtivo e minimizar os custos. Para tal, não
basta apenas desenvolver produtos de alta qualidade ou prestar um serviço com excelência, é
preciso também reduzir gastos, o que pode ser alcançado evitando paradas desnecessárias na linha
de produção devido à problemas em equipamentos, afinal, quase 70% dos gastos em operações
de manufatura podem ser atribuídos à defeitos decorrentes da falta de manutenção (Tse; Wang,
1996).
Tempos atrás, sem o auxílio da tecnologia, os equipamentos industriais eram substituídos

apenas quando apresentavam algum defeito. Depois, passou-se a executar manutenções agendadas,
de acordo com determinado período de tempo, o que permitiu maior sobrevida às máquinas.
Com o decorrer dos anos, o avanço tecnológico das comunicações sem fio e da Internet tornou
possível prever, com certa antecedência, quando um equipamento apresentará algum problema.
Isso faz com que o equipamento só seja parado quando realmente necessário e permite que a
manutenção seja efetuada nos primeiros indícios do defeito.
Neste contexto, a CBM visa possibilitar a identificação e o reparo de problemas em

equipamentos, proporcionando maior durabilidade e grande redução de custos, tendo em vista
que boa parte deles possuem alto valor agregado. De forma geral, a CBM pode ser vista como
um método usado para reduzir a incerteza das atividades de manutenção e é realizada de acordo
com as condições dos equipamentos (SHIN; JUN, 2015).
Além disso, como os equipamentos industriais possuem certa complexidade e sua manu-
tenção necessita de conhecimentos específicos, deseja-se que os dispositivos responsáveis pela
coleta dos dados possam ser instalados de forma não intrusiva, ou seja, acoplados na parte
externa dos equipamentos dos quais coletarão as informações, tornando assim muito mais simples
a instalação, evitando paradas desnecessárias da produção e a desmontagem dos equipamentos.
Contudo, levando em consideração o fato de que os sensores são os responsáveis pela

obtenção de um determinado dado de interesse, é preciso fornecer algum meio de comunicação
para que tais dados possam ser coletados e analisados remotamente. Com o avanço das tecno-
logias de comunicação sem fio, existem diversas opções que podem atender essa demanda por
conectividade: ZigBee, Wi-Fi, LoRa, Sigfox, BLE, entre outras. Cada uma dessas tecnologias
possui características e benefícios específicos, sendo necessária uma avaliação do cenário para
que a melhor decisão seja efetuada.
Atualmente, existem no mercado empresas que se propõem a fornecer um sistema completo

para a obtenção, envio, armazenamento e análise dos dados, como é o caso da Bluvision (2018),
que oferece três linhas de produtos para o monitoramento das condições dos equipamentos: os
endpoints (chamados de beacons) para a coleta dos dados, os gateways (chamados de BluFi)
para o encaminhamento dos dados provenientes da rede BLE para a rede Wi-Fi e a plataforma
24 Capítulo 1. Introdução
online Bluzone, que armazena, gerencia e analisa os dados.
É importante ressaltar que este projeto não visa competir com os sistemas já comercializa-
dos atualmente, mas sim demonstrar a viabilidade da implementação de um sistema composto por
componentes de baixo custo e softwares livres, possibilitando maior flexibilidade e customização,
conforme o cenário.
Outro fator importante a ser mencionado é que este trabalho não tem como pretensão
descobrir qual é exatamente o defeito da máquina, mas sim detectar comportamentos anômalos,
que deem indícios de que seu motor não está operando de forma convencional. Isto se deve ao
fato de que seria necessário um acelerômetro muito preciso e capaz de obter amostras a uma
taxa de, pelo menos, o dobro da maior frequência de operação do motor, para que fosse possível
atender ao teorema de Nyquist e então realizar a Fast Fourier transform (FFT) do sinal. Isso
porque a análise do espectro da frequência da vibração permite não somente predizer o problema,
mas também prescrevê-lo e possibilitar sua prevenção.
Dessa forma, buscando simplicidade e possibilidade de utilização de sensores de baixo

custo, decidiu-se analisar a vibração apenas no domínio do tempo utilizando os valores RMS
e pico a pico como parâmetros. Afinal, o valor RMS retrata a energia da vibração e o pico a
pico representa a variação de sua amplitude em um determinado período. Além de analisar estes
parâmetros em função do tempo, também avaliou-se o comportamento do motor através da
dispersão entre as medidas, a fim de formar clusters de funcionamento, que possuem formato
bem específico para cada comportamento do motor.
1.1 Objetivos
Este trabalho tem como principal objetivo desenvolver um sistema de manutenção
preditiva utilizando técnicas de aprendizado de máquina com base em dados coletados por um
sensor de vibração (acelerômetro) conectado à rede IoT composta pelas tecnologias BLE e Wi-Fi.
Para alcançar tal meta, definiu-se os seguintes objetivos específicos:
• Desenvolvimento do endpoint e gateway;
• Implementação do servidor em nuvem para armazenamento e gerenciamento dos dados

(backend);
• Aplicação de técnicas de aprendizado de máquina para predição de falhas em motores

elétricos;
• Desenvolvimento de um aplicativo mobile para acompanhamento dos dados coletados e

recebimento dos alertas em casos de detecção de anomalias.
1.2 Organização do texto

Este documento está organizado da seguinte maneira: no Capítulo 2 é apresentada uma
descrição sucinta do conceito de CBM e algumas de suas aplicações; são abordadas características
1.2. Organização do texto 25
de redes IoT e possíveis tecnologias que podem ser utilizadas neste cenário; a tecnologia BLE é
vista com maior profundidade e é realizada uma visão geral do que é aprendizado de máquina, além
de uma abordagem sobre o algoritmo K-means. No Capítulo 3 é apresentado o desenvolvimento
de todo o trabalho, descrevendo os módulos endpoint, gateway, backend e aplicativo mobile. No
Capítulo 4 são apresentados e discutidos os resultados obtidos na coleta da vibração do motor
a partir do acelerômetro. Por fim, o Capítulo 5 apresenta as conclusões deste projeto e sugere
alternativas de implementações para trabalhos futuros.
27
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são abordados os temas que servem como base teórica para que o objetivo
proposto possa ser alcançado. Na seção 2.1 é descrito o conceito de CBM e são citadas algumas
aplicações em que ela pode ser inserida. Já na seção 2.2 é feita uma revisão sobre as redes IoT e as
tecnologias que podem ser utilizadas para compô-la. Na seção 2.3 são detalhados os parâmetros e
a pilha de protocolos de tecnologia BLE, que foi a escolhida para prover a conectividade para os
dispositivos neste projeto. E, por fim, a seção 2.4 apresenta uma visão geral sobre aprendizado de
máquina e K-means, que é um dos principais algoritmos utilizados para manutenção preditiva.
2.1 Condition-based maintenance (CBM)
No contexto das indústrias, existem algumas categorias de manutenção de equipamentos,

sendo que as três principais serão abordadas nesta seção. A primeira, mais simples e comum, é
a manutenção corretiva, que ocorre apenas após o equipamento ter apresentado alguma falha,
sendo que a ação tomada é o conserto ou a troca. A segunda, também bastante utilizada, é
conhecida como manutenção preventiva, que tem como premissa a checagem dos equipamentos
a cada determinado período de tempo. Desta forma, é possível efetuar a troca e/ou reparo de
peças desgastadas, garantindo um aumento na vida útil do equipamento.
A terceira e última, Condition-based maintenance (CBM), pode ser semelhante à manu-

tenção preventiva, no sentido de que seu objetivo é prevenir anomalias no equipamento antes
que elas ocorram. Contudo, a abordagem da CBM é diferente, pois o foco deste método é
prever o processo de degradação de um produto, que baseia-se na hipótese de que a maioria dos
comportamentos anômalos não ocorrem instantaneamente, mas sim de forma gradual. Sendo
assim, diferentemente das categorias acima, a CBM não foca somente na detecção de falhas e
diagnóstico dos componentes, mas também no monitoramento da degradação e predição de falhas
do equipamento (SHIN; JUN, 2015).
O conceito de CBM foi criado pela empresa Rio Grande Railway Company no final da
década de 40 e foi inicialmente chamado de “manutenção preditivia”. Analisando mudanças
de temperatura e pressão, a companhia ferroviária utilizava as técnicas de CBM para detectar
vazamentos de fluídos refrigerantes, óleo e combustível do motor. Tais técnicas tiveram grande
sucesso em termos de reduzir os impactos de falhas não planejadas e identificar quando consertar
um vazamento ou reabastecer um fluído ou o reservatório de óleo (PRAJAPATI; BECHTEL;
GANESAN, 2012).
Desde então, diversas definições surgiram com o intuito de descrever o que é a CBM. Para
os autores Shin e Jun (2015), que citam várias dessas definições em seu artigo, Condition-based
maintenance (CBM) pode ser considerada como uma política de manutenção que executa uma
ação antes que as falhas no equipamento aconteçam, por meio da avaliação das condições do
equipamento e do ambiente operacional, prevendo o risco de falhas em tempo real com base nos
28 Capítulo 2. Fundamentação Teórica
dados coletados do equipamento.
As técnicas de CBM possuem uma ampla área de aplicação, como em fábricas de

manufatura, indústrias, setores militar e naval, veículos da força aérea, infraestrutura de tecnologia
e informação, veículos comerciais e aviação (PRAJAPATI; BECHTEL; GANESAN, 2012).
Dentre estes exemplos, os autores Prajapati, Bechtel e Ganesan (2012) destacam que,
no contexto das indústrias, a CBM é uma abordagem alternativa que reduz significativamente
o tempo de inatividade, prevendo falhas de forma antecipada com base na análise de vibração,
sendo capaz de, inclusive, determinar a vida útil restante do equipamento. Esta vibração é
obtida por meio de sensores que podem ser montados em qualquer peça crítica como motores,
ventiladores, caixas de câmbio, bombas, rolamentos e outros meios rotativos. Com o decorrer do
tempo, a deterioração do equipamento aumenta e o padrão de vibração muda, o que pode ser
facilmente detectado por uma análise de FFT da vibração de um determinado componente.
É importante ressaltar que as técnicas de CBM não são aplicadas somente com a
observação da vibração de um equipamento. Esta análise é apenas uma forma de fazer isso. E
existem diversas outras, como por exemplo o monitoramento de temperatura, tensão e corrente
elétrica, entre outras.
Segundo Shin e Jun (2015), a Figura 1 exibe um procedimento genérico para a imple-
mentação da CBM.
Figura 1 – Procedimento para a abordagem da CBM
Fonte: Adaptada de Shin e Jun (2015).
Com isso, esta técnica nos permite identificar e resolver possíveis defeitos nos produtos
antes mesmos de ocorrerem. Tendo em vista que qualquer problema em equipamentos industriais
pode resultar em grandes perdas, a CBM é um método bastante atrativo para as indústrias em
geral.
2.2 Internet of things (IoT)

Cada vez mais, um crescente número de dispositivos eletrônicos vêm se conectando à
Internet, idealizando o conceito das redes IoT. Um exemplo muito comum são as casas inteligentes,
que possuem diversos equipamentos conectados entre si, capazes de monitorar o ambiente e
tomar decisões de forma autônoma, de acordo com os dados coletados.
2.2. Internet of things (IoT) 29
Existem também outros ambientes em que as redes IoT podem ter um ótimo desempenho
e facilitar as nossas vidas. Essas aplicações incluem o transporte, saúde, situações de emergência
provocadas por desastres naturais e até mesmo pelo homem, além da automação industrial.
Dessa forma, espera-se que com o passar do tempo, as redes IoT tenham ainda mais impacto,
aumentado a qualidade de vida das pessoas e fazendo crescer a economia mundial (AL-FUQAHA
et al., 2015).
Ainda segundo Al-Fuqaha et al. (2015), estima-se que até o final de 2020 existam mais de
212 bilhões de dispositivos IoT espalhados pelo mundo. Mais além, em 2022, a previsão é de que
45% de todo o tráfego da Internet seja constituído por comunicações Machine-to-machine (M2M)
que, para Xiao et al. (2016), é o termo utilizado para tecnologias que permitem as máquinas
e os dispositivos móveis estabelecerem enlaces entre si de forma autônoma, visando a troca de
informações.
Aplicação foco deste trabalho e citada por Samie, Bauer e Henkel (2016), as indústrias
inteligentes também contam com as redes IoT, que proporcionam soluções para automação,
controle e monitoramento objetivando reduzir o custo de operação e manutenção, além de
aumentar a qualidade do serviço oferecido. Um exemplo disso é o monitoramento remoto das
máquinas para realizar a Condition-based maintenance (CBM).
2.2.1 Tecnologias
Por ser uma rede muito ampla e possuir tantas aplicações, é preciso levar em conta alguns
parâmetros para definir a melhor tecnologia de comunicação a ser utilizada em um determinado
cenário. Esse ponto também é abordado por Samie, Bauer e Henkel (2016), onde é feita uma
breve descrição das seguintes tecnologias:
• Near Field Communication (NFC): É uma tecnologia de comunicação sem fio de

pequeno alcance, que permite a troca de informações entre dispositivo fisicamente próximos
(aproximadamente 20 centímetros). Os dados são armazenados em tags, sendo que estas
podem ser apenas para leitura ou regraváveis.
• Low power wide area network (LPWAN): São tecnologias que focam no baixo
consumo energético e transmissão em altas distâncias. Chegam a suportar mais de 10
quilômetros de distância entre o gateway e os endpoints. Contudo, as taxas de transmissão
de dados são extremamente baixas, geralmente menores do que 1 Kbps. Além disso,
operam em faixas de frequências próximas de GHz, cujo espectro é amplamente utilizado
globalmente.
• Redes celular: Redes móveis muito difundidas, como o 3G e o Long term evolution (LTE),
que proveem altas taxas de transmissão. Contudo, em geral, exigem alto consumo energético.
• Wi-Fi: As principais vantagens são a grande largura de banda e sua disponibilidade nas
áreas urbanas. Também conta com alto consumo de potência.
• ZigBee: Rede de baixo custo, baixo consumo energético e fisicamente pequena, capaz de
suportar diferentes topologias, como por exemplo, mesh, árvore e estrela. Oferece amplo
alcance de transmissão, dependendo da potência utilizada. Contudo, enfrenta algumas

barreiras no mercado, principalmente relacionadas a outra tecnologia emergente, que conta
com maior largura de banda e um menor custo de energia, conhecida como BLE.
• Bluetooth low energy (BLE): A tecnologia Bluetooth já é bastante conhecida e muito

utilizada em diversos dispositivos eletrônicos, para as mais variadas finalidades. Oferece
taxas de transferência e largura de banda suficientes para o tráfego de streams, como o
áudio. Porém, possui diversas limitações quanto ao número de nodos conectados à rede
(um dispositivo mestre e até sete escravos). A tecnologia BLE, também conhecida como
Bluetooth Smart, foi desenvolvida para alcançar curtas distâncias, utilizar uma pequena
largura de banda e obter baixas latências para aplicações IoT. As vantagens do BLE sobre o
Bluetooth convencional, também chamado de Bluetooth Clássico, incluem menor consumo
de potência, menor tempo de configuração dos dispositivos e o suporte às topologias estrela
e mesh com um ilimitado número de nodos.
Tendo em vista que a aplicação deste trabalho não requer ampla cobertura de rede e nem
altas taxas de transmissão, a tecnologia de comunicação escolhida foi a BLE, por ter um baixo
consumo energético e permitir a conexão de um número ilimitado de nodos em uma mesma rede,
além do fato de que tanto os endpoints quanto os gateways possuem baixo custo.
Na seção a seguir, serão abordadas, de maneira mais detalhada, as características e

propriedades da tecnologia BLE, escolhida para prover a conectividade neste projeto.
2.3 Bluetooth low energy (BLE)

Anunciada pela primeira vez em 2010, a tecnologia BLE tem como principal objetivo
expandir o uso do Bluetooth para aplicações que possuem restrições de energia, como controles
e sensores wireless. Também são características dessas aplicações a baixa quantidade de dados
transmitidos e a comunicação que ocorre com pouca frequência. Essas são as maiores diferenças se
comparadas às aplicações do Bluetooth convencional, como a transmissão de áudio e dados, que
trafegam grande quantidade de dados e frequente interação entre os dispositivos de comunicação.
2.3.1 Parâmetros da tecnologia
Para a transmissão dos dados, o BLE utiliza a modulação Gaussian frequency shift
keying (GFSK) que reduz os picos de consumo de energia, de acordo com Čabarkapa, Grujić
e Pavlović (2015). Com relação à taxa de transferência, a camada física do BLE pode atingir
até 1Mbps, porém, a máxima vazão na camada de aplicação é de apenas 236,7kbps (GOMEZ;
OLLER; PARADELLS, 2012).
Com o objetivo de atenuar a interferência em uma faixa de frequência tão sobrecarregada,

o BLE utiliza a técnica Frequency-hopping spread spectrum (FHSS), mas, em contraste com
o Bluetooth Clássico, o BLE permanece mais tempo no mesmo canal e torna os requisitos de
tempo mais flexíveis em comparação ao Bluetooth Clássico (CHANG, 2014).
2.3. Bluetooth low energy (BLE) 31
Enquanto o Bluetooth Clássico conta com 79 canais de comunicação, cada um com 1Mhz
de largura de banda, a tecnologia BLE utiliza o dobro de largura, porém, devido à isso, no BLE
existem apenas 40 canais de comunicação, sendo três destes para anúncio e o restante para
transferência de dados. A Figura 2 ilustra como são distribuídos os canais do BLE em função
das faixas de frequência.
Figura 2 – Canais de comunicação utilizados pelo BLE. Os canais 37, 38 e 39 são os de anúncio,
sendo que os demais são utilizados para a transferência de dados
Fonte: Adaptada de Chang (2014).
Os canais de anúncio têm a função de facilitar a descoberta e o estabelecimento da

comunicação entre dois dispositivos, o que inclui a negociação dos parâmetros a serem utilizados.
Uma vez conectados, a transferência das informações é feita através dos canais de dados. Como a
robustez dos canais de anúncio é de extrema importância para a inicialização da comunicação e,
tendo em vista que o BLE ocupa algumas faixas de frequência utilizadas pelo Wi-Fi, tais canais
são escolhidos para operarem nas bandas que sofrem menos interferências pelas redes Wi-Fi.
Além disso, para evitar a interferência e o desvanecimento com outras comunicações sem
fio na mesma banda de frequência, como o Wi-Fi, o BLE implementa o Adaptative frequency
hopping (AFH), que é responsável por definir, de maneira psuedo-aleatória, o canal de comunicação
a ser utilizado pelos dispositivos (TOSI et al., 2017) .
Segundo Chang (2014), o BLE foi projetado para que dois dispositivos possam se conectar
rapidamente, já que os pacotes de anúncio transmitidos possuem apenas 1 byte de preâmbulo,
4 bytes de códigos de acesso, 3 bytes de Cyclic redundancy code (CRC) e um Protocol data
unit (PDU) contendo de 2 a 39 bytes, sendo que, o menor pacote pode ser transmitido em 80
µs e o maior em 300 µs. Com um pequeno tamanho de pacote, o BLE atende aos requisitos de
baixo duty-cycle, o que é muito importante para aplicações de redes de sensores sem fio.
2.3.2 Pilha de protocolos
A pilha de protocolos da tecnologia BLE é composta por três blocos principais, conforme
mostra a Figura 3.
Figura 3 – Pilha de protocolos da tecnologia BLE.
Fonte: Adaptada de Tosi et al. (2017).
Estes blocos e suas camadas são descritos a seguir de acordo com Tosi et al. (2017). A
Aplicação é o bloco mais alto da pilha e representa a interface direta com o usuário. É ela
quem define alguns perfis que permitem a interoperabilidade entre diferentes aplicações, os quais
são definidos pelo Bluetooth Special Interest Group (SIG). A especificação Bluetooth também
permite estabelecer perfis específicos de fornecedores para casos de uso não cobertos pelos padrões
definidos pelo SIG.
Já o bloco Host inclui algumas camadas, sendo que o Generic Access Profile (GAP) faz
interface diretamente com a camada de aplicação e, portanto, com o usuário, que pode definir
todos os parâmetros que a rede necessita. É o protocolo responsável por implementar e controlar
todas as camadas inferiores da pilha. Além disso, especifica papéis, modos e procedimentos do
dispositivo, bem como o de gerenciar o estabelecimento da conexão e a segurança. O Generic
Attribute Profile (GATT) encapsula a camada Attribute Protocol (ATT) e sua função principal
é estabelecer como trocar informações e dados de todos os perfis em um enlace BLE. Os perfis
são definições de possíveis aplicações e especificam comportamentos gerais que os dispositivos
BLE usam para se comunicar com outros dispositivos BLE, além de definir mais claramente
que tipo de dados um módulo BLE está transmitindo. Esses dados são organizados em uma
estrutura hierárquica composta de seções chamadas serviços, que, por sua vez, agrupam os dados
em contêineres chamados de características.
O GATT define as duas funções, cliente e servidor, em uma conexão. O Bluetooth SIG
define alguns serviços e características padrão, representados em um formato de endereço de 16
2.4. Aprendizado de máquina 33
bits, mas o BLE permite que os fabricantes definam seus próprios serviços usando um Universally
Unique Identifier (UUID) de 128 bits para adaptar a tecnologia à novas e originais aplicações.
Durante o estabelecimento da conexão, o servidor informa ao cliente quais são os seus serviços
e características com o objetivo de definir como a conexão será estruturada. Um serviço é
basicamente um contêiner que conceitualmente agrupa os atributos relacionados, enquanto as
características são os atributos incluídos em um serviço, e cada um deles é usado para comunicar
um tipo específico de dados, como por exemplo, temperatura, umidade, corrente elétrica, vibração,
entre outros.
O protocolo Logical Link Control and Adaptation Protocol (L2CAP) atua como um
multiplexador. Manipula os dados das camadas inferiores e os encapsula no formato de pacote
padrão, de acordo com as camadas superiores e vice-versa. Estes processos são chamados
respectivamente de recombinação (ou encapsulamento) e fragmentação.
O Attribute Protocol (ATT) define as funções de uma arquitetura cliente-servidor,

onde o cliente é aquele que solicita dados do servidor, que, por sua vez, envia dados para os
clientes. Normalmente, essas funções correspondem respectivamente ao mestre e ao escravo
definidos na camada de elance. O ATT também executa a organização de dados em atributos, aos
quais é atribuído um índice, um UUID, um conjunto de permissões e um valor. Esse protocolo é
encapsulado no GATT, que usa as funções definidas no ATT para realizar conexões. A subcamada
Security Manager Protocol (SMP) cuida do emparelhamento de dispositivos, da distribuição das
chaves de segurança e é projetado para minimizar os requisitos de recursos para os dispositivos
escravos, deslocando a carga de trabalho para dispositivos mestres que possuem maior capacidade
de processamento.
A responsabilidade de padronizar a comunicação entre o controlador o host fica por conta

do Host Controller Interface (HCI), que é um bloco intermediário dentre estes dois.
O Controlador, último bloco da pilha de protocolos BLE, é implementado em hardware

e composto pelos subblocos Link Layer (LL) e Physical Layer (PHY), sendo que a primeira é a
camada de enlace, que provê o acesso ao meio, controle de erro e de fluxo e o estabelecimento da
conexão entre os dispositivos. Já a PHY se trata da camada física e tem como responsabilidade
a transmissão e recepção dos dados.
No contexto deste trabalho, o módulo BLE (servidor) presente no endpoint será utilizado
para transferir os dados coletados a partir do sensor de vibração para o gateway BLE (cliente)
que, por sua vez, encaminhará os dados para a nuvem, onde serão inseridos em um modelo de
aprendizado de máquina, a fim de analisá-los e alertar aos responsáveis, caso os dados representem
um comportamento anômalo.
2.4 Aprendizado de máquina

Uma definição formal de aprendizado de máquina proposta pelo cientista da computação
Tom M. Mitchell afirma que uma máquina aprende sempre que é capaz de utilizar sua experiência
de tal forma que seu desempenho melhore em experiências semelhantes no futuro. Apesar de esta
definição ser intuitiva, ela ignora completamente o processo de como exatamente uma experiência
pode ser traduzida em ação futura. Embora o cérebro humano seja naturalmente capaz de
aprender desde o nascimento, as condições necessárias para que os computadores aprendam
devem ser explicitadas (LANTZ, 2015).
De acordo com esta definição, podemos concluir que as técnicas de aprendizado de

máquina podem ser utilizadas para ensinar um computador a tomar decisões futuras baseadas em
experiências semelhantes passadas e em um determinado conjunto de dados. Para Amruthnath e
Gupta (2018), tais técnicas podem ser classificadas como supervisionadas, não supervisionadas,
semi-supervisionadas e por reforço, sendo que as mais comumente utilizadas para manutenção
preditiva são as supervisionadas e não-supervisionadas.
As técnicas de aprendizado supervisionado são utilizadas para treinar um modelo preditivo

que, por sua vez, tem como objetivo prever um valor usando outros valores de um mesmo conjunto
de dados que possui uma ou mais variáveis independentes (entradas) e uma ou mais variáveis
dependentes (saídas), sendo que tanto as entradas quanto as saídas são conhecidas. Estas técnicas
podem ser aplicadas em problemas de regressão, onde se deseja prever dados numéricos, ou em
problemas de classificação, para prever categorias (LANTZ, 2015). O termo “supervisionado” se
deve ao fato de que o treinamento de um algoritmo com um determinado conjunto de dados pode
ser considerado como um professor que supervisiona o processo de aprendizado. Afinal, como as
respostas corretas são conhecidas, o algoritmo faz iterativamente previsões sobre os dados de
treinamento e é corrigido pelo professor. O ciclo só é encerrado quando o algoritmo obtém um
desempenho aceitável. Geralmente, os modelos de classificação de aprendizagem supervisionada
devem executar as seguintes etapas: coleta de dados, extração de características, seleção de um
algoritmo de aprendizado de máquina, construção do modelo usando o algoritmo selecionado e,
por fim, avaliação da precisão do algoritmo (ALFIAN et al., 2018).
Por outro lado, as técnicas de aprendizado não-supervisionado são aplicadas no treina-

mento de modelos descritivos, cujo conjunto de dados é caracterizado por não fornecer variáveis
de saída. Portanto, faz parte do aprendizado realizar inferências a partir das variáveis de en-
tradas para determinar padrões (HASTIE; TIBSHIRANI; FRIEDMAN, 2009). Tais técnicas
podem ser aplicadas em problemas de clusterização, onde se deseja descobrir agrupamentos
inerentes aos dados ou em problemas de associação, buscando o descobrimento de regras que
descrevam grande parte de um conjunto de dados. Analogamente ao aprendizado anterior, o
termo “não-supervisionado” se refere ao fato de que não há um professor e nem respostas corretas.
Neste projeto, não há o objetivo de testar várias técnicas de aprendizado de máquina e

nem definir a melhor técnica para o conjunto de dados a ser analisado. Visando a validação do
sistema como um todo, decidiu-se testar apenas uma técnica de aprendizado de máquina e a
escolhida foi o K-means, que é um algoritmo do tipo não-supervisionado e comumente utilizado
para problemas de clusterização (ou agrupamento).
O motivo pelo qual o K-means foi escolhido se deve ao fato de ser um dos algoritmos
não-supervisionados mais simples e amplamente utilizado para este tipo de aplicação, como
constatado através da revisão bibliográfica de diversos autores, como Strangas, Aviyente e Zaidi
(2008), Liu et al. (2018), Harrou et al. (2018) e Amruthnath e Gupta (2018).
2.4. Aprendizado de máquina 35
2.4.1 K-means
O algoritmo K-means é o mais comum dentre os métodos de clusterização e bastante
utilizado na detecção de falhas e predição das classes de falhas em técnicas de aprendizado
não-supervisionado. Esse algoritmo geralmente usa a distância euclidiana entre as amostras para
formar os clusters (AMRUTHNATH; GUPTA, 2018).
Segundo Lantz (2015), o algoritmo K-means começa escolhendo, de forma aleatória,

k pontos no espaço de recursos para serem os centros dos clusters que, por sua vez, são os
catalisadores que estimulam as amostras restantes a se agruparem. Existem diferentes métodos
para determinar quais serão os centros iniciais, que propõem a diminuição do efeito randômico
sobre o resultado final. Após escolher os centros iniciais dos clusters, as outras amostras são
aproximadas destes centros de acordo com a função de distância, que tradicionalmente é a
euclidiana, mas também podem ser utilizadas as distâncias de Manhattan e Minkowski. Se
considerarmos que n é o número de amostras, é possível determinar a distância euclidiana entre
uma amostra x e uma amostra y através da Equação 2.1:
v
u n
dist(x, y) = t (xi − yi )2
uX
(2.1)
i=1
Ainda de acordo com Lantz (2015), após a fase de atribuição inicial ser concluída, o
algoritmo K-means prossegue para a fase de atualização. A primeira etapa da atualização dos
clusters envolve a mudança dos centros iniciais para um novo local, conhecido como centroide,
que é calculado a partir da posição média dos pontos atualmente atribuídos a esse cluster. Esse
processo é repetido ciclicamente, a fim de aumentar a precisão com relação às amostras e ao
cluster em que estão inseridas, conforme ilustra a Figura 18.
Figura 4 – Exemplo de funcionamento do algoritmo K-means.
Fonte: Adaptada de Hastie, Tibshirani e Friedman (2009).

37
3 DESENVOLVIMENTO
O trabalho proposto teve como objetivo desenvolver um sistema capaz de implementar

os conceitos de CBM, apresentados na seção 2.1, para a predição de falhas em motores elétricos
utilizados em equipamentos industriais. Para tal, foi acoplado um endpoint na parte externa
de um destes equipamentos a fim de coletar as informações referentes à vibração do motor e
enviá-las, através de uma rede BLE, para um gateway cuja principal função é encaminhar esses
dados para um backend remoto, hospedado na Amazon web services (AWS).
O backend, por sua vez, armazena os dados obtidos em um banco de dados MySQL
executa um script desenvolvido em Python responsável pela aplicação do algoritmo de aprendi-
zado de máquina citado na subseção 2.4.1, o qual é treinado para que seja capaz de detectar
comportamentos anômalos, baseando-se na vibração do motor. Por fim, os dados armazenados
são consumidos por uma aplicação mobile que exibe as coletas em forma de gráficos e alerta o
usuário nos casos em que o algoritmo de aprendizado de máquina observa algo incomum. Além
das atribuições mencionadas ao backend, nele também é definida a Application Programming
Interface (API) para viabilizar sua comunicação tanto com o gateway quanto com a aplicação. A
Figura 5 ilustra a interação entre todos os módulos do sistema.
Figura 5 – Diagrama do sistema proposto
Fonte: Criada pelo autor.
Buscando alcançar um sistema de baixo custo e que utilizasse os recursos disponíveis

na instituição, optou-se por utilizar softwares livres e hardwares acessíveis na composição dos
módulos do subsistema de coletas (endpoint e gateway). O desenvolvimento de cada uma destas
etapas é detalhado neste capítulo e todos os códigos fontes implementados e utilizados neste
projeto estão presentes no Github 1 do autor.
1
https://github.com/vitors95/TCC
38 Capítulo 3. Desenvolvimento
3.1 Endpoint
O hardware do endpoint é constituído pela plataforma de desenvolvimento Arduino

Nano2 , um módulo MPU-60503 e um módulo BLE AT-09 que utiliza o microcontrolador CC25414
e os mesmos são exibidos na Figura 6.
Figura 6 – Componentes do endpoint
(a) Arduino Nano (b) Módulo MPU-6050 (c) Módulo BLE
Fonte: Adaptada de Filipeflop
A configuração dos módulos foi feita através do Arduino Nano, que por sua vez faz
uso de uma conexão serial com o computador para receber os dados do programa desenvolvido
utilizando sua própria Integrated Development Environment (IDE). Como o Arduino Nano possui
apenas uma porta serial, para conectá-lo ao módulo AT-09 foi necessário utilizar a biblioteca
SoftwareSerial, nativa da plataforma, que possibilita a comunicação serial através de outros pinos
digitais, fazendo com que estes assumam os papeis de Transmissor (TX) e Receptor (RX). Por
outro lado, não foi preciso adotar tal abordagem no que se refere à comunicação com o módulo
MPU-6050, já que este utiliza o protocolo Inter-Integrated Circuit (I2C). As conexões físicas
entre os dispositivos que compõem o endpoint são ilustradas na Figura 7.
Figura 7 – Representação do circuito
2
https://www.arduino.cc/en/Main/Products
3
https://www.invensense.com/products/motion-tracking/6-axis/mpu-6050/
4
http://www.ti.com/product/CC2541
3.1. Endpoint 39
O Arduino Nano obtém os dados do acelerômetro GY-521, presente no módulo MPU-

6050, e faz uso do AT-09 para enviar as informações ao gateway, cuja conexão é inicializada
pelos pacotes de anúncio, frequentemente enviados à rede pelo módulo BLE. Após a conexão
ser estabelecida, o endpoint assume o papel de servidor e envia os dados para o gateway, que
neste contexto é o cliente. O fluxograma apresentado na Figura 8 visa facilitar o entendimento e
detalhar o funcionamento do endpoint.
Figura 8 – Fluxograma do funcionamento do endpoint
No setup do programa do Arduino é inicializada a comunicação serial com o módulo

BLE e também com o módulo MPU-6050, sendo que este último faz uso do protocolo I2C. Após
isso, é atribuído o valor zero aos registradores 0x6B e 0x1C do MPU-6050 que, respectivamente,
fazem com que o sensor retorne do modo de economia de energia (sleep) e configure sua escala
de valores de vibração para ±2g e seu fator de sensibilidade para 16384.
Após as configurações iniciais, o Arduino Nano passa a executar a seção loop do programa,
que consiste em adquirir do sensor a temperatura e os valores brutos da aceleração nos eixos X,
Y e Z a cada 3 segundos. Estes valores são armazenados em variáveis auxiliares até que sejam
obtidas 20 amostras, para que então seja calculado o valor RMS, a média da temperatura e
também o valor pico a pico através da diferença entre o máximo e o mínimo dentre as amostras.
A fórmula utilizada para definir o valor RMS é apresentada na Equação 3.1:
v
u
u1 XN
RM S = t x2i (3.1)
N i=1
Tendo os valores, o Arduino os envia sequencialmente ao gateway através do módulo

BLE AT-09 e, logo em seguida, o ciclo é reiniciado. Sendo assim, a cada 1 minuto são enviados
14 bytes, já que são necessários 16 bits para representar cada valor.
3.1.1 Montagem do hardware
O endpoint foi montado em uma protoboard conforme a Figura 7, com exceção do

módulo MPU-6050, que necessita estar em contato com a máquina para captar sua vibração com
maior eficiência. Todavia, devido ao modo como o acelerômetro é disposto no MPU-6050, não foi
possível simplesmente acoplá-lo à máquina, já que os terminais do módulo entrariam em curto e
provavelmente a trepidação o danificaria. Sendo assim, foi confeccionado um case para o módulo,
o que possibilitou que o mesmo pudesse ser diretamente fixado à máquina.
Para prover certa resistência mecânica e tornar o módulo mais protegido, um case de
sensor de abertura foi adaptado para suportar o módulo MPU-6050 em seu interior. A fixação do
módulo no case foi feita através de cola quente, tendo sido inserido uma pequena peça plástica
entre ambos, com o objetivo de facilitar o manuseio e uma possível remoção do módulo. Em
contrapartida, o processo de utilização de um suporte plástico, cola quente e um case resultou em
uma absorção da vibração, tornando o módulo menos sensível. Nos testes realizados, percebeu-se
que a aceleração captada pelo sensor era praticamente nula quando sob uma superfície plana e
estática. Porém, ao acoplá-lo em algum equipamento em operação, notou-se que o sensor ainda
captava as variações de acordo com a intensidade da vibração. Uma imagem do resultado final
do endpoint é exibida na Figura 9.
Figura 9 – Montagem do endpoint em uma protoboard

3.2. Gateway 41
3.2 Gateway
Por ser compatível nativamente tanto com a tecnologia de comunicação sem fio Wi-Fi
(padrões IEEE 802.11 b/g/n) quanto com o BLE e possuir um valor bastante acessível, o módulo
de desenvolvimento ESP32, exibido na Figura 10, foi o escolhido para realizar o papel de gateway
do sistema.
Figura 10 – Módulo de desenvolvimento ESP32
No setup da ESP32 é feita a configuração do scanner BLE, que consiste em inicializar

scan, definir a função de callback a ser executada sempre que um novo pacote de anúncio é
recebido, ou seja, quando algum dispositivo BLE for encontrado e configurar a duração do
scanner que, neste caso, foi de 30 segundos. A função de callback analisa se o pacote de anúncio
possui algum UUID de serviço e se este é válido. Caso seja, o scanner BLE é encerrado e a
ESP32 conecta-se ao módulo BLE AT-09. Após realizada a conexão, o gateway obtém os UUID
de serviço e da característica do pacote de dados enviado pelo endpoint. Caso estes não sejam
nulos, ou seja, alguma informação de fato foi enviada pelo endpoint, é definido uma função de
callback de notificações, que lida com os dados oriundos do endpoint. Neste callback é feito o
tratamento do array de 14 bytes enviado pelo endpoint, sendo feita uma separação a cada 2
bytes, que respectivamente representam a temperatura, os valores da aceleração instantânea nos
eixos X, Y e Z, e os valores RMS nos eixos X, Y e Z.
Após obter os valores, o gateway encerra a comunicação BLE com o endpoint e inicia mais
um processo de conexão, porém, desta vez com o backend através da rede Wi-Fi. Primeiramente, a
ESP32 tenta se conectar ao Wi-Fi e, caso consiga, monta um JavaScript Object Notation (JSON)
contendo os dados obtidos pelo sensor, o seu próprio Media Access Control (MAC) e também
o MAC do endpoint e transmite para o backend através da Uniform Resource Locator (URL)
http://ec2-34-215-199-111.us-west-2.compute.amazonaws.com:5000/collect, utilizando o método
HyperText Transfer Protocol (HTTP) POST. Ao término da transmissão dos dados, a ESP32
se desconecta da rede Wi-Fi e reinicia o scanner BLE, até que um novo pacote de anúncio seja
recebido, repetindo de forma indefinida todo o processo descrito.
O motivo pelo o qual o gateway não mantém conexão com o backend e com o endpoint
se deve ao fato de que a ESP32 utiliza a mesma antena para as conexões BLE e Wi-Fi, tornando
necessária a desconexão após o envio e/ou recebimento dos dados.
No decorrer da implementação do gateway, percebeu-se algumas instabilidades no que se

refere a sua conectividade, em ambas as redes BLE e Wi-Fi, o que ocasionava loops indefinidos.
Para contornar este problema, foi introduzido um watchdog, garantindo que a ESP32 se reinicie
automaticamente caso o programa não tenha nenhum progresso dentro de um período de 30

segundos. Após esta melhoria, mesmo que alguma anormalidade aconteça com o gateway, ele
voltará ao seu funcionamento normal de forma completamente automática, sem necessitar de
qualquer intervenção humana. Porém, é possível que algumas coletas sejam perdidas durante o
período em que o gateway entrou em loop e, em seguida, se reiniciou.
3.3 Backend
O backend é responsável por receber os dados enviados pelo gateway, armazená-los e
disponibilizá-los à aplicação mobile, além de realizar a análise do comportamento da vibração
do motor através do algoritmo K-means, apresentado na subseção 2.4.1. Tendo em vista que o
processamento necessário para tratar as requisições ao backend é relativamente baixo e procurando
facilitar o desenvolvimento do projeto, optou-se por hospedar o backend em um servidor remoto,
utilizando o plano gratuito da AWS que provê, por um período de 1 ano, 750 horas mensais de
uso de instância t2.micro5 .
A descrição detalhada dos submódulos que compõem o backend é feita a seguir.
3.3.1 Banco de dados

O banco de dados utilizado neste projeto foi o MySQL e sua modelagem foi realizada
através da ferramenta MySQL Workbench6 , cujo diagrama EER é exibido na Figura 11.
Figura 11 – Diagrama EER do banco de dados
5
https://aws.amazon.com/pt/free/
6
https://www.mysql.com/products/workbench/
3.3. Backend 43
A tabela Collect é responsável por armazenar os valores da aceleração e temperatura

obtidos pelo sensor, além dos endereços MAC do Arduino Nano (referente ao endpoint que
realizou a coleta), da ESP32 (gateway que recebeu os dados através do BLE) e da data e hora
em que os dados foram recebidos pelo web service. É ela também que relaciona a tabela Gateway,
que contém apenas o MAC da ESP32, com a tabela Place, que possui o local onde o endpoint
foi instalado e mantém relacionamento com as tabelas Equipment e Endpoint.
A ideia proposta é que um equipamento possa ser associado a um único local, mas
em um mesmo equipamento possam ser instalados mais de um endpoint, tornando possível o
monitoramento dos equipamentos através de múltiplos endpoints, aumentando a credibilidade
dos dados obtidos.
Outro ponto importante a se notar é que um local só pode ser criado desde que um
equipamento tenha sido previamente cadastrado. Analogamente, um endpoint só pode ser
adicionado à tabela caso já exista um local para que seja associado.
3.3.2 Web Service
Tem como principal função a implementação da API utilizada na comunicação com o

gateway e com a aplicação mobile. Seu desenvolvimento foi feito utilizando a linguagem de
programação Python e o framework Flask. Vale ressaltar que a API projetada segue os conceitos
da arquitetura Representation State Transfer (REST) e toda a troca de informações é feita
utilizando a formatação JSON.
Para tratar as requisições feitas pelo gateway e pela aplicação, diferentes métodos foram
desenvolvidos. A função handleCollect() é chamada quando uma requisição HTTP POST ou
GET é feita para a Uniform Resource Identifier (URI) /collect. Seu objetivo para requisições
do tipo POST (oriundas do gateway) é consultar no banco de dados a existência do gateway e
do endpoint através de seus endereços MAC e, em caso de sucesso, as informações coletadas a
partir do sensor são gravadas na tabela Collect. Para as requisições do tipo GET (feitas pela
aplicação), o web service recebe também o parâmetro placeID, que identifica unicamente um
local na tabela Place e seleciona no banco de dados todas as coletas referentes à este local e as
retorna ao aplicativo.
O método responsável por tratar as requisições GET e POST relacionados à URI

/equipment, é o handleEquipment(). Para o primeiro tipo, são retornadas todas as informações
contidas na tabela Equipment. Contudo, para o tipo POST, o web service grava na tabela
Equipment o nome do equipamento recebido. Da mesma maneira que foi implementada a função
anterior, o handleEndpoint() também retorna todas as informações da tabela Endpoint quando
é recebida uma requisição GET e armazena na mesma tabela os dados do endpoint ao receber
uma requisição POST na URI /endpoints.
Por último, o handlePlace() trata cria os locais na tabela Place ao receber requisições
POST na URI /places e retorna os dados da mesma tabela e também o nome e o Identificador (ID)
do equipamento associado ao respectivo local quando recebe um GET. Para facilitar e agilizar a
implementação e os testes do web service, foi utilizada a ferramenta Postman7 , que tem como
objetivo a construção de requisições HTTP para testar as URIs de APIs.
Para que o backend pudesse alertar a aplicação quando um comportamento anômalo fosse
descoberto, utilizou-se o serviço Firebase Cloud Messaging (FCM)8 da Google, cuja funcionalidade
é prover um mecanismo de envio e recebimento de notificações de push. Sua integração com o
backend foi feita através da biblioteca pyfcm9 , que abstrai complexidade da implementação, de tal
forma que seu uso é bastante simples. Logo na inicialização do backend é criada uma instância do
FCM utilizando a chave da API do projeto previamente criado na página do console do Firebase
e caso o algoritmo K-means detecte algo incomum nos dados coletados, uma notificação de push
é enviada para todos os usuários que estiverem inscritos no tópico utilizado pelo backend.
3.3.3 Implementação do algoritmo K-means
Visando facilitar a integração da implementação do algoritmo de aprendizado de máquina

com o backend, nesta etapa também foi utilizada a linguagem de programação Python e por conta
da revisão bibliográfica feita na seção 2.4, optou-se pela implementação apenas do algoritmo não-
supervisionado K-means. Tendo em vista que este trabalho não tem a pretensão de desenvolver
um algoritmo de aprendizado de máquina, utilizou-se a biblioteca Scikit-learn10 que já possui tal
implementação para diversos algoritmos, sejam eles supervisionados ou não.
Além desta, também foram utilizadas as bibliotecas Pandas 11 para a manipulação dos
datasets formatados em .Comma-separated values (CSV), Matplotlib 12 para a geração dos gráficos
e Numpy 13 para a realização de cálculos matemáticos. Estes datasets foram gerados a partir de
um outro script implementado também em Python, que tem como objetivo conectar-se ao banco
de dados hospedado na AWS, obter todas as informações da tabela Collect e convertê-las para
o formato .CSV, o que é facilmente realizado com o auxílio da biblioteca Pandas. Contudo,para
mensurar a precisão da classificação dos clusters do algoritmo K-means, foi necessário adicionar
uma nova coluna ao dataset, chamada de status, em que o número 0 atribuído à ela representa que
a respectiva medida é referente ao funcionamento normal e o número 1 indica o funcionamento
anormal do motor.
A aplicação do algoritmo K-means foi realizada individualmente por cada eixo, ou seja,
levando em consideração apenas os valores pico a pico e RMS correspondentes ao eixo em questão.
Devido ao motor vibrar de forma distinta em cada eixo da aceleração, optou-se por não analisar
o conjunto de dados como um todo, pois isto traria imprecisões ao algoritmo. Na instanciação da
classe K-means foram definidas algumas propriedades do algoritmo, como o número máximo de
iterações, tolerância para convergência, número de vezes em que o algoritmo é executado com
diferentes centroides, entre outros. Contudo, a alteração destes atributos não proporcionaram
nenhuma modificação no resultado final. Já o número de clusters foi definido de forma arbitrária,
7
https://www.getpostman.com/
8
https://firebase.google.com/docs/cloud-messaging
9
https://pypi.org/project/pyfcm/
10
https://scikit-learn.org/
11
https://pandas.pydata.org
12
https://matplotlib.org/
13
https://www.numpy.org
3.4. Aplicativo mobile 45
afinal, neste cenário foram considerados apenas as situações em que o motor estava operando
normalmente e de forma desbalanceada. Portanto, utilizou-se apenas 2 clusters.
Tendo em vista que a instância t2.micro da AWS possui certas limitações de recursos,
decidiu-se realizar a análise do algoritmo K-means a cada 5 coletas recebidas de um mesmo
endpoint, ou seja, aproximadamente a cada 5 minutos. Este fluxo de execução inicia-se com um
contador zerado e que é incrementado a cada coleta recebida de um mesmo endpoint, identificado
pelo seu endereço MAC. Assim que o contador atinge o valor 5, o método prediction() do backend
seleciona as últimas 5 linhas da tabela Collect e as anexa ao dataset previamente construído,
em que metade dos valores é referente ao funcionamento normal do motor e o restante representa
o funcionamento anormal. Em seguida, o K-means determina o centroide de cada um dos clusters
e classifica cada amostra com base na menor distância euclidiana entre elas e os centroides. Vale
ressaltar que a classificação é feita com base na dispersão dos valores pico a pico e RMS em
cada eixo da aceleração. Por fim, o backend verifica se ao menos 3 amostras de qualquer eixo
foram alocadas no cluster referente ao funcionamento anormal e, caso isto ocorra, é enviada
uma notificação de push ao usuário informando sobre a detecção de comportamento anômalo no
equipamento.
3.4 Aplicativo mobile

O aplicativo foi desenvolvido para a plataforma Android, utilizando a IDE Android
Studio 14 e a linguagem de programação Kotlin15 , que foi criado pela Jetbrains e oficialmente
suportado pela Google para desenvolvimento mobile no Android desde o lançamento do Android
Studio 3.0, em outubro de 2017. No desenvolvimento do aplicativo foram utilizadas as seguintes
bibliotecas de terceiros:
• Retrofit16 : ferramenta que visa facilitar a construção de requisições HTTP;
• RxKotlin17 : biblioteca de programação reativa, baseada em eventos;
• MPAndroidChart18 : biblioteca de visualização de gráficos para Android, suportando gráficos

de linha, barra, radar, bolha e castiçal, bem como dimensionamento, arrastamento e
animações.
Na inicialização do aplicativo é feita a criação e configuração da instância do Firebase,

de tal forma que o dispositivo mobile de registre no mesmo tópico de notificações utilizado pelo
backend, viabilizando o recebimento dos alertas gerados quando comportamentos anormais nos
equipamentos são identificados. É neste ponto que também é criado o client HTTP através da
biblioteca Retrofit e, logo em seguida, são feitas chamadas assíncronas utilizando o RxKotlin
para executar as requisições HTTP ao web service.
14
https://developer.android.com/studio
15
https://kotlinlang.org/
16
https://square.github.io/retrofit/
17
https://github.com/ReactiveX/RxKotlin
18
https://github.com/PhilJay/MPAndroidChart
Primeiramente, um HTTP GET é enviado à URI /places do web service para obter o
nome e o ID de todos os locais cadastrados no banco de dados. A seguir, são realizadas requisições
GET para a URI /collect, informando como parâmetro o ID do local, de forma a obter todas
as coletas referentes a cada local, que consequentemente são associadas a um equipamento
e endpoint. Após obter todos os locais e suas respectivas coletas, é utilizado o componente
RecyclerView 19 para criar dinamicamente uma lista de itens de acordo com o número de locais
obtidos. Tais itens são compostos pelo nome do local, nome do equipamento, uma área para
gráficos e botões para que o usuário possa escolher qual gráfico deseja visualizar no momento. É
possível optar entre o gráfico de dispersão da aceleração pico a pico em função do RMS nos três
eixos, além dos gráficos dos valores pico a pico e temperatura em função do tempo.
A classe responsável pela manipulação destes itens é a PlaceHolderView, onde é feita a

configuração de todos os parâmetros dos gráficos. Como mencionado acima, a biblioteca utilizada
para a criação dos gráficos foi a MPAndroidChart, que permite a utilização de diferentes tipos
de gráficos e uma enorme variedade de customizações. Para o gráfico de dispersão utilizado na
representação dos eixos X, Y e Z da aceleração foram configurados apenas parâmetros simples.
Porém, para a construção do gráfico de linha usado para ilustrar a temperatura foi necessário
adaptar o eixo do tempo para que suportasse o nosso padrão de data e hora, visto que nativamente
a biblioteca suporta somente números e strings simples.
Embora o web service já esteja preparado para receber requisições HTTP para a criação de
novos equipamentos, endpoints e locais, foi implementado no aplicativo apenas as funcionalidades
essenciais para viabilizar a conclusão do projeto, sendo assim, por ele ainda não existe a
possibilidade de criar um novo local, endpoint ou equipamento. A ferramenta Postman foi
utilizada para testar a criação destes componentes e também atender aos requisitos impostos
pelo banco de dados, afinal, é preciso que haja ao menos uma instância de cada um destes
componentes do sistema para que as coletas possam ser armazenadas.
Outro ponto importante a ser destacado é o fato de que o sistema como um todo não foi
projetado para suportar o gerenciamento de dispositivos por usuário. Em outras palavras, não
existem usuários e, consequentemente, também não há a possibilidade de associar os dispositivos
a um usuário, de forma que todo e qualquer local que possua coletas será exibido à qualquer
usuário que abrir o aplicativo. Reforçando o que foi descrito anteriormente, essa decisão foi
tomada visando primeiramente concluir o que era essencial para o projeto.
19
https://developer.android.com/guide/topics/ui/layout/recyclerview
47
4 RESULTADOS
Após ter cada módulo do sistema desenvolvido, a obtenção dos dados para realizar os
testes foi feita através de um motor do fabricante Elco1 . O modelo utilizado é do tipo shaded
pole, que são amplamente utilizados na refrigeração industrial e comercial. Esses motores são
monofásicos e operam numa tensão nominal de 230V (50-60Hz), com potência de saída variante
de 5 a 42 Watts. Mais detalhes sobre suas especificações podem ser encontrados no catálogo
digital do fabricante2 entre as páginas 40 e 56.
O acelerômetro, cuja confecção do seu case foi descrita na subseção 3.1.1, foi posicionado
paralelamente à parte superior do motor e não foi utilizado nenhum tipo de fixação entre eles,
justamente para não prejudicar a captação da vibração por parte do sensor. Entretanto, foi
preciso aplicar fita isolante sobre o case e o motor, para garantir que o sensor não se movimentasse
em decorrência da trepidação motor.
Primeiramente, pensou-se em obter os dados do motor com e sem hélice, a fim de verificar
a diferença entre os valores da aceleração nestes cenários, contudo, notou-se que a temperatura
do motor aumentou de forma considerável quando sem hélice, chegando à aproximadamente
60 ◦C em menos de 30 minutos de operação. Provavelmente, isso se deve ao fato de que, neste
caso, praticamente toda a potência gerada pelo motor estava sendo dissipada nele em forma de
calor. Já com a hélice, a potência é utilizada para fazê-la girar e, com isso, o calor é expelido do
motor. Nessa situação, a máxima temperatura observada foi de 42 ◦C.
Sendo assim, decidiu-se adotar uma abordagem em que o motor faria uso da hélice em
ambos os cenários, mas em um deles seria fixado um objeto à hélice, visando provocar um certo
desbalanceamento na vibração. O objeto utilizado foi um prego de metal, com aproximadamente
um peso de 0,5 gramas e comprimento de 3 centímetros. Para garantir que ele não se soltasse da
hélice, o mesmo foi fixado à ela através de fitas isolante e dupla face.
Como o intuito deste trabalho não é de mensurar e/ou comparar o consumo de energia ou
a máxima distância de comunicação do BLE com outras tecnologias, os demais componentes do
endpoint foram dispostos próximos ao motor, de tal forma que a mesma tomada de alimentação
foi compartilhada entre o Arduino Nano e o motor e que também ficassem próximos ao gateway,
que estava com linha de visada há aproximadamente 2 metros de distância e sendo alimentado
diretamente por outra tomada de energia. Devido à curta distância entre o gateway e o endpoint,
no decorrer dos testes não foi percebida nenhuma perda de informação. Além disso, o gateway
também estava próximo ao roteador com acesso à Internet, há pouco menos de 10 metros e quase
nenhuma obstrução física, o que contribuiu para uma conexão estável.
O cenário em que as coletas foram realizadas pode ser melhor compreendido através da
Figura 12. Nela é possível observar que os dispositivos estavam sobre uma superfície plana de
madeira, com o propósito de não prejudicar a obtenção dos dados.
1
http://www.elco-spa.com
2
http://www.elco-spa.com/Catalogs/refrigeration2018.pdf
48 Capítulo 4. Resultados
Figura 12 – Cenário de coletas
Apesar de os gráficos de dispersão dos três eixos da aceleração e dos valores pico a pico
em função do tempo terem sido implementados no aplicativo mobile, optou-se por utilizar a
linguagem de programação Python para gerar os conjuntos de gráficos analisados neste trabalho.
Para este desenvolvimento, também foram utilizadas as bibliotecas Pandas, Matplotlib e Numpy.
O dataset foi o mesmo analisado pelo algoritmo K-means.
No primeiro cenário, os dados foram obtidos do motor que estava utilizando a hélice sem
nenhum objeto anexado à ela, o que representa o comportamento normal da máquina. Apesar
de terem sido coletadas amostras por alguns dias, foi definido de maneira arbitrária o período
de tempo a ser considerado para o treinamento do modelo de aprendizado de máquina que,
neste caso, foi de 5 horas, ou seja, aproximadamente 300 amostras (1 por minuto). Contudo,
vale ressaltar que na prática este período de tempo deve ser o suficiente para representar o
funcionamento da máquina.
Posteriormente, foi utilizado uma fita para fixar horizontalmente o prego em uma seção
da hélice. Visivelmente foi possível notar uma grande diferença no motor, que trepidava muito
mais do que na situação anterior, além de produzir ruídos com maior amplitude. Assim como
antes, foram adquiridas 300 amostras, o que resultou em um período de aproximadamente 5
horas de coleta.
Ainda durante a coleta, percebeu-se através dos dados que já estavam sendo armazenados
no bando de dados que o alcance de valores da aceleração previamente configurado para ±2g,
conforme descrito na seção 3.1, não estava sendo o suficiente para representar os valores obtidos,
afinal, a vibração estava muito mais intensa do que quando não havia desbalanceamento. Sendo
assim, foi preciso reconfigurar a escala de valores da aceleração do módulo MPU-6050 para ±4g,
o que consequentemente alterou o valor da sensibilidade para 8192. Como os dados analisados
49
neste trabalho foram normalizados pelo fator de sensibilidade, esta troca não ocasionou nenhum
efeito nos dados do funcionamento normal anteriormente obtidos, pois estes foram divididos pelo
fator 16384.
Na Figura 13 são exibidos os gráficos dos valores pico a pico e RMS no eixo X da
aceleração em função do tempo. Vale ressaltar que por terem ocorrido algumas perdas de coletas
e para melhorar a visualização dos gráficos, a escala de tempo foi definida em minutos, mas que
não necessariamente representam um período contínuo. Com relação aos dados, nota-se que em
alguns momentos os valores pico a pico do funcionamento normal, cuja representação é feita
por uma linha azul com pontos nas extremidades, se aproximaram de 1g, enquanto este mesmo
parâmetro teve uma variação muito mais abrupta no funcionamento anormal, representado por
uma linha vermelha, e quase alcançou o limite da nova escala configurada. Tal diferença também
é percebida nos valores RMS, já que visivelmente é possível notar que os valores obtidos foram
em torno de 0,25g para o funcionamento normal e, em determinados pontos, quadruplicaram no
funcionamento anormal.
Figura 13 – Eixo X da aceleração em função do tempo

Analogamente, a Figura 14 mostra que o eixo Y se comportou de maneira similar ao eixo

X, visto que os valores obtidos através do funcionamento anormal também possuem amplitude
significativamente maior. Contudo, observa-se que o espaço entre as duas linhas é menor do que no
eixo anterior, o que sugere que este eixo não foi tão afetado em decorrência do desbalanceamento
no motor.
Figura 14 – Eixo Y da aceleração em função do tempo
O último eixo, que contra ele naturalmente é exercida a aceleração da gravidade, apresen-
tou valores RMS relativamente próximos à 1g independente do funcionamento, que é justamente
o próprio valor da gravidade. Sendo assim, analisando apenas este parâmetro, entende-se que
pouca influência teve a vibração do motor sobre o eixo Z. Devido à isso, boa parte das coletas
foram sobrepostas. Contudo, é notável a diferença entre os funcionamentos no que se refere às
amplitudes pico a pico, em que por diversas vezes os dados obtidos com o motor desbalanceado
foram muito maiores em relação aos do funcionamento normal. Tal comportamento pode ser
constatado na Figura 15.
51
Figura 15 – Eixo Z da aceleração em função do tempo
Apesar de a análise dos valores pico a pico e RMS em função do tempo mostrarem
com grande nitidez a diferença na vibração do motor entre a sua operação normal e quando
desbalanceado, é a Figura 16 que traz mais informação e precisão no que se refere ao estado
do motor. Afinal, como já mencionado no Capítulo 1 deste documento, o RMS representa a
energia da vibração do motor, enquanto o pico a pico mostra o quanto variou a amplitude do
sinal em um determinado período de tempo. Os gráficos de dispersão apresentados ilustram bem
a formação de dois clusters de medidas, um referente ao funcionamento normal do motor e outro
que retrata o efeito do desbalanceamento sobre a vibração. Apesar de algumas amostras terem
sido sobrepostas nos eixos Y e Z, ainda assim é possível perceber uma grande diferença nos
padrões de operação.
Figura 16 – Dispersão entre os valores pico a pico e RMS
Por fim, o último parâmetro a ser comparado entre os dois funcionamentos é a temperatura.
Nota-se na Figura 17 que o desbalanceamento do motor não proporcionou nenhuma alteração
significativa de temperatura. Inclusive, em alguns momentos o motor em seu estado normal
atingiu valores maiores. De certa forma, este comportamento já era esperado, afinal, o prego
fixado à hélice fez com que uma de suas seções tivesse maior peso, o que resulta em vibrações
fora do comum, mas que não têm relação alguma com a temperatura do motor. Contudo, a
análise deste parâmetro é importante, pois pode revelar outros problemas na máquina.
4.1. Testes de clusterização utilizando o algoritmo K-means 53
Figura 17 – Temperatura do motor em função do tempo
4.1 Testes de clusterização utilizando o algoritmo K-means

Na Figura 18 são exibidos os resultados obtidos a partir da execução do K-means em cada
eixo da aceleração, onde a área inferior, demarcada em azul, representa o primeiro cluster e o
segundo cluster é localizado na parte superior, em vermelho. Visivelmente é possível perceber uma
grande semelhança com a Figura 16, que mostra a dispersão entre os valores pico a pico e RMS
dos diferentes funcionamentos, o que nos permite associar o primeiro cluster ao funcionamento
normal da máquina e o segundo cluster à operação desbalanceada. Comparando as duas imagens,
também é possível notar que o K-means classificou algumas medidas de forma incorreta, o que é
totalmente compreensível, tendo em vista que o algoritmo atribui uma amostra a um cluster
baseando-se na menor distância euclidiana entre ela e os centroides, destacados em preto.
Figura 18 – Clusterização dos dados através do algoritmo K-means
A precisão do algoritmo no que se refere à classificação das coletas ao cluster correspon-

dente ao funcionamento do motor foi calculada a partir dos valores da coluna status, manualmente
inseridos no dataset, e da predição feita pelo próprio K-means. Os resultados são observados
na Tabela 1 e foram obtidos através da classe classification_report, também da biblioteca
Scikit-Learn.
Tabela 1 – Precisão da predição do K-means por eixo
Eixo Precisão
X 98%
Y 84%
Z 93%
Nota-se que o K-means obteve melhor precisão no eixo X que, como observado na
Figura 13, foi o mais afetado pelo desbalanceamento imposto ao motor. Em contrapartida,
o algoritmo teve menor sucesso na classificação das amostras referentes ao eixo Y, o que é
4.2. Exibição dos resultados no aplicativo mobile 55
explicado pela grande proximidade entre os pontos, conforme exibido na Figura 14. Levando
em consideração que as amostras do eixo Z também estavam próximas e algumas até mesmo
sobrepostas, o classificador as separou de modo a obter precisão ligeiramente inferior à do eixo X.
4.2 Exibição dos resultados no aplicativo mobile

Como descrito na seção 3.4, o foco do desenvolvimento do aplicativo foi sobre a exibição
dos gráficos das medidas coletadas a partir do acelerômetro. Portanto, o aplicativo não envia
nenhuma informação ao backend, apenas as solicita, como é o caso dos locais e das coletas, além
do recebimento de notificações de push.
Na Figura 19 são exibidas as capturas de tela do aplicativo com os gráficos de dispersão

em cada eixo da aceleração. Vale ressaltar que a base de dados utilizada foi praticamente a
mesma das análises anteriores, exceto pela inclusão de algumas amostras.
Figura 19 – Capturas de tela dos gráficos de dispersão no aplicativo
(a) Eixo X (b) Eixo Y (c) Eixo Z

As demais capturas de tela do aplicativo contendo os gráficos referentes aos valores pico
a pico e temperatura em função do tempo são apresentados na Figura 20.
Figura 20 – Capturas de tela dos gráficos dos valores pico a pico e temperatura em função do
tempo no aplicativo
(a) Eixo X (b) Eixo Y
(c) Eixo Z (d) Temperatura

Tendo em vista que a máxima temperatura que o motor atingiu durante a coleta dos
dados (com a hélice) foi de 42 ◦C, no backend foi definido o valor 1860 como sendo o limiar da
4.2. Exibição dos resultados no aplicativo mobile 57
temperatura obtida pelo sensor para que a notificação de push seja emitida ao dispositivo mobile.
A escolha desse número se deve ao fato de que é preciso multiplicar o dado bruto oriundo do
sensor por 340 e ainda somar 36,53 para convertê-lo para a escala de temperatura Celsius. Neste
caso, o valor resultante é de aproximadamente 42 ◦C. A notificação de push utilizada para alertar
o usuário do aplicativo é exibida na Figura 21.
Figura 21 – Captura de tela da central de notificações exibindo o alerta de temperatura
Por fim, a Figura 22 mostra o alerta gerado pelo backend através da execução do K-means
que, baseando-se nas últimas 5 coletas, indica que três ou mais amostras foram associadas ao
cluster referente ao funcionamento anormal, independente do eixo da aceleração. Vale ressaltar
que o prego estava fixado à hélice no momento em que esta notificação foi gerada.
Figura 22 – Captura de tela da central de notificações exibindo o alerta de detecção de compor-

tamento anômalo

59
5 CONCLUSÕES
Neste trabalho foram apresentados os fundamentos necessários para o desenvolvimento

de um sistema de predição de falhas em motores elétricos utilizados em indústrias e comércios
através da coleta de dados obtidos por um acelerômetro para medição e acompanhamento do
funcionamento do equipamento em questão. Devido ao grande número de áreas e módulos
envolvidos no desenvolvimento deste trabalho, optou-se por utilizar apenas um algoritmo de
aprendizado de máquina para viabilizar a predição de comportamentos anômalos. De acordo
com a revisão bibliográfica feita, percebeu-se que o K-means, uma das técnicas de aprendizado
de máquina não-supervisionado, é amplamente utilizado em cenários de monitoramento das
condições dos equipamentos e foi o escolhido devido à isso.
Nos testes realizados com o dataset construído a partir das coletas feitas, confirmou-se a
eficiência do K-means, que obteve resultados próximos a 100% nos eixos X e Z no que se refere
à classificação das amostras de acordo com o funcionamento do motor. O pior desempenho foi
observado no eixo Y, que na análise em função do tempo apresentou uma certa proximidade
entre as amostras, resultando em classificações incorretas. Uma possível justificativa para que o
eixo Y tenha sido o menos afetado em função do prego anexado à hélice pode estar relacionada à
maneira com que a base do motor foi fixada à superfície de madeira, para garantir que o mesmo
não caísse em decorrência da trepidação.
É importante ressaltar que o único funcionamento anormal simulado foi o desbalance-

amento. Portanto, pode-se concluir que o sistema desenvolvido tem a capacidade de predizer
defeitos decorrentes do desbalanceamento do motor, mas que não foram realizados testes para
mensurar sua eficiência com relação a outras possíveis anomalias.
Outro ponto a ser mencionado é que durante a implementação dos módulos encontrou-se
certa dificuldade em manter o sistema completamente genérico no que diz respeito ao número
de locais e equipamentos gerenciados. Portanto, tendo em vista que foram realizadas algumas
simplificações no aplicativo e backend, limitou-se o escopo do projeto para que apenas um local e
equipamento fosse suportado. Esta decisão não trouxe nenhum impacto ao trabalho, visto que
todos os dados foram coletados de um mesmo motor.
Apesar de terem sido feitos testes para validar as notificações de push referentes à
detecção de comportamentos anômalos no equipamento, não houve tempo hábil para que se
produzisse estatísticas sobre esta funcionalidade, visto que seria necessário monitorar as condições
do equipamento durante um certo período de tempo para obter o índice de acertos e erros da
classificação por parte do algoritmo K-means. Contudo, verificou-se nestes testes que, enquanto
o motor estava operando de forma desbalanceada, a cada aproximadamente 5 minutos uma
notificação era recebida, já que a análise no backend é feita após o recebimento de 5 coletas de
um mesmo endpoint. Em contrapartida, nenhuma notificação deste tipo foi recebida nos testes
em que o motor estava em seu funcionamento normal.
60 Capítulo 5. Conclusões
Por fim, destaca-se que a premissa de utilização de hardwares de baixo custo e softwares
livres foi atendida, o que torna possível a criação de um produto comercialmente competitivo e
altamente customizável.
5.1 Trabalhos futuros

Como sugestão de trabalhos de continuidade desse desenvolvimento, recomenda-se os
tópicos mencionados a seguir:
1. Aplicação de outros algoritmos de aprendizado de máquina, possibilitando uma comparação

de desempenho entre eles;
2. Simulação de outras possíveis anomalias no funcionamento do motor, para verificar se o

sistema é capaz de detectá-las;
3. Análise das condições do equipamento no domínio da frequência, em que se pode realizar a

FFT do sinal, viabilizando não somente a predição, mas também a prescrição e prevenção
dos defeitos.
61
REFERÊNCIAS
AL-FUQAHA, A. et al. Internet of things: A survey on enabling technologies, protocols, and

applications. Communications Surveys & Tutorials, IEEE, IEEE, USA, v. 17, n. 4, p. 2347–2376,
2015. ISSN 1553-877X. Citado na página 29.
ALFIAN, G. et al. A personalized healthcare monitoring system for diabetic patients by utilizing
ble-based sensors and real-time data processing. Sensors, v. 18, n. 7, 2018. ISSN 1424-8220.
Disponível em: <http://www.mdpi.com/1424-8220/18/7/2183>. Citado na página 34.
AMRUTHNATH, N.; GUPTA, T. Fault class prediction in unsupervised learning using

model-based clustering approach. In: 2018 International Conference on Information and
Computer Technologies (ICICT). [S.l.: s.n.], 2018. p. 5–12. Citado 2 vezes nas páginas 34 e 35.
BLUVISION. Site. Florida, 33334, 2018. Disponível em: <http://bluvision.com/>. Acesso em:
18 nov. 2018. Citado na página 23.
CHANG, K.-H. Bluetooth: A viable solution for iot? Wireless Communications, IEEE, USA,
p. 6–7, 2014. Citado 2 vezes nas páginas 30 e 31.
GOMEZ, C.; OLLER, J.; PARADELLS, J. Overview and evaluation of bluetooth low energy:
An emerging low-power wireless technology. Sensors, v. 12, n. 9, p. 11734–11753, 2012. ISSN
1424-8220. Disponível em: <https://www.mdpi.com/1424-8220/12/9/11734>. Citado na
página 30.
HARROU, F. et al. Statistical monitoring of a wastewater treatment plant: A case study. Journal
of Environmental Management, v. 223, p. 807 – 814, 2018. ISSN 0301-4797. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0301479718307394>. Citado na página 34.
HASTIE, T.; TIBSHIRANI, R.; FRIEDMAN, J. The elements of statistical learning:

data mining, inference and prediction. 2nd. ed. Springer, 2009. Disponível em: <http:
//www-stat.stanford.edu/~tibs/ElemStatLearn/>. Citado 2 vezes nas páginas 34 e 36.
LANTZ, B. Machine Learning with R. 2nd. ed. [S.l.]: Packt Publishing, 2015. ISBN 1784393908,
9781784393908. Citado 2 vezes nas páginas 34 e 35.
LIU, J. et al. A discrete hidden markov model fault diagnosis strategy based on k-means
clustering dedicated to pem fuel cell systems of tramways. International Journal of
Hydrogen Energy, v. 43, n. 27, p. 12428 – 12441, 2018. ISSN 0360-3199. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0360319918313521>. Citado na página 34.
PRAJAPATI, A.; BECHTEL, J.; GANESAN, S. Condition based maintenance: a survey.

Journal of Quality in Maintenance Engineering, v. 18, n. 4, p. 384–400, 2012. Citado 2 vezes
nas páginas 27 e 28.
SAMIE, F.; BAUER, L.; HENKEL, J. Iot technologies for embedded computing: A survey.
In: ACM. Proceedings of the Eleventh IEEE/ACM/IFIP International Conference on
Hardware/Software Codesign and System Synthesis. [S.l.], 2016. p. 8. Citado na página 29.
SHIN, J.-H.; JUN, H.-B. On condition based maintenance policy. Journal of Computational
Design and Engineering, v. 2, n. 2, p. 119 – 127, 2015. ISSN 2288-4300. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S2288430014000141>. Citado 3 vezes nas
páginas 23, 27 e 28.
62 Referências
Strangas, E. G.; Aviyente, S.; Zaidi, S. S. H. Time–frequency analysis for efficient fault diagnosis
and failure prognosis for interior permanent-magnet ac motors. IEEE Transactions on Industrial
Electronics, v. 55, n. 12, p. 4191–4199, Dec 2008. ISSN 0278-0046. Citado na página 34.
TOSI, J. et al. Performance evaluation of bluetooth low energy: A systematic review. Sensors,
MDPI, USA, p. 1–34, 2017. Citado 2 vezes nas páginas 31 e 32.
Tse, P.; Wang, D. D. A hybrid neural networks based machine condition forecaster and classifier
by using multiple vibration parameters. In: Proceedings of International Conference on Neural
Networks (ICNN’96). [S.l.: s.n.], 1996. v. 4, p. 2096–2100 vol.4. Citado na página 23.
XIAO, Y. et al. Full-duplex machine-to-machine communication for wireless-powered

internet-of-things. In: . [S.l.]: IEEE, 2016. p. 1–6. ISBN 9781479966646. ISSN 1938-1883. Citado
na página 29.
ČABARKAPA, D.; GRUJIć, I.; PAVLOVIć, P. Comparative analysis of the bluetooth low-energy
indoor positioning systems. Telsiks, IEEE, USA, p. 76–79, 2015. Citado na página 30.

Sistema de manutenção preditiva para equipamentos industriais utilizando redes BLE e Wi-Fi com aprendizado de máquina

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sistema de manutenção preditiva para equipamentos industriais utilizando redes BLE e Wi-Fi com aprendizado de máquina

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO FEDERAL DE SANTA CATARINA

VITOR MANOEL DA SILVEIRA

SISTEMA DE MANUTENÇÃO PREDITIVA

Trabalho de conclusão de curso apresentado à

Orientador: Mario de Noronha Neto

Orientador: Mario de Noronha Neto

Monografia (Graduação) – Instituto Federal de Santa Catarina – IFSC

SISTEMA DE MANUTENÇÃO PREDITIVA UTILIZANDO REDES

São José - SC, 09 de julho de 2019:

Mario de Noronha Neto, Dr.

Valdir Noll, Dr.

Roberto de Matos, Dr.

Roberto Dias, Dr.

Às amizades que construí ao longo do curso.

Aos professores do IFSC-SJ que, desde o curso técnico integrado em telecomunicações,

E a Intelbras, empresa onde trabalho e que me proporcionou todo o suporte e flexibilidade

Palavras-chave: Condition-based maintenance. Aprendizado de máquina. Predição de falhas.

Keywords: Condition-based maintenance. Machine learning. Fault predictiont. Bluetooth low

Figura 1 – Procedimento para a abordagem da CBM . . . . . . . . . . . . . . . . . . . . 28

Tabela 1 – Precisão da predição do K-means por eixo . . . . . . . . . . . . . . . . . . . . 54

AFH Adaptative frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

ATT Attribute Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

AWS Amazon web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

BLE Bluetooth low energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

CBM Condition-based maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

CRC Cyclic redundancy code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

FFT Fast Fourier transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

FHSS Frequency-hopping spread spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

GAP Generic Access Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

GATT Generic Attribute Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

GFSK Gaussian frequency shift keying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

HCI Host Controller Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

IoT Internet of things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

L2CAP Logical Link Control and Adaptation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

LTE Long term evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

NFC Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

PDU Protocol data unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

PHY Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

SIG Special Interest Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

SMP Security Manager Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

UUID Universally Unique Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

I2C Inter-Integrated Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

RMS Root Mean Square . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

JSON JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

MAC Media Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

URL Uniform Resource Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

HTTP HyperText Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

URI Uniform Resource Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

EER Extended Entity-Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

FCM Firebase Cloud Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

REST Representation State Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

IDE Integrated Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

CSV Comma-separated values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Tempos atrás, sem o auxílio da tecnologia, os equipamentos industriais eram substituídos

Neste contexto, a CBM visa possibilitar a identificação e o reparo de problemas em

Contudo, levando em consideração o fato de que os sensores são os responsáveis pela

Atualmente, existem no mercado empresas que se propõem a fornecer um sistema completo

online Bluzone, que armazena, gerencia e analisa os dados.

Dessa forma, buscando simplicidade e possibilidade de utilização de sensores de baixo

• Desenvolvimento do endpoint e gateway;

• Implementação do servidor em nuvem para armazenamento e gerenciamento dos dados